ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Brainium has quit [Quit: Konversation terminated!]
mxz_ has joined #wayland
mxz__ has joined #wayland
mxz___ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz__ is now known as mxz
Company has quit [Quit: Leaving]
riteo has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
DodoGTA has quit [Read error: Connection reset by peer]
tzimmermann has joined #wayland
DodoGTA has joined #wayland
DodoGTA has quit [Read error: No route to host]
DodoGTA has joined #wayland
DodoGTA has quit [Read error: Connection reset by peer]
tzimmermann has quit [Ping timeout: 480 seconds]
DodoGTA has joined #wayland
coldfeet has joined #wayland
leon-anavi has joined #wayland
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
DodoGTA has quit []
DodoGTA has joined #wayland
tzimmermann has joined #wayland
rasterman has joined #wayland
gryffus_ has joined #wayland
gryffus has quit [Ping timeout: 480 seconds]
gryffus_ has quit [Read error: Connection reset by peer]
gryffus_ has joined #wayland
DodoGTA has quit []
DodoGTA has joined #wayland
mvlad has joined #wayland
Dami_Lu has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
oeuaoeuoeu has joined #wayland
<oeuaoeuoeu>
Is is explicitly documented anywhere that, if applicable, only egl and vulkan are allowed to call wl_surface.attach?
<zamundaaa[m]>
oeuaoeuoeu: no, because it's not true
<oeuaoeuoeu>
The client cannot know if the driver is using explicit sync with the surface. Therefore it cannot attach without first detaching the surface from the driver. (maybe with the exception of a null surface.)
<oeuaoeuoeu>
*null buffer
<kennylevinsen>
the client is able to attach any importable dmabuf at any time it wants from any source
<kennylevinsen>
Not fighting with Vulkan and EGL WSI's is up to the client - if it uses the WSI, it means that it wants mesa to take care of attaching buffers and then the client should not do that
<kennylevinsen>
On the other hand, it's free to not use the WSI aspect and just render buffers that it then attaches on its own
<kennylevinsen>
(likewise, it might attach buffers from any other location - e.g., buffers from va-api, dmabufs received from other processes, whatever it feels like)
<oeuaoeuoeu>
To be clear: by "if applicable" I mean that the client is concurrently using egl or vulkan to attach and commit buffers.
<kennylevinsen>
I don't follow what the use-case would be
<kennylevinsen>
either way, Wayland doesn't care how or when a process attaches buffers. EGL/Vulkan WSI are just abstractions internal to the process itself, and it's up to the process to make sense of how it wants to manage its surfaces
<oeuaoeuoeu>
It does absolutely care if there is a syncobj_surface created by the WSI that the client knows nothing about. There is no way for the client to attach and commit a non-null buffer manually in that situation.
<kennylevinsen>
No, it does not care
<kennylevinsen>
Being consistent in its communication is up to the client process
<MrCooper>
oeuaoeuoeu: as kennylevinsen said, if you use EGL/Vulkan WSI, you can't attach buffers behind its back
<kennylevinsen>
its use of mesa is just an implementation detail, and any inconsistencies are just bugs
<MrCooper>
oeuaoeuoeu: or even call wl_surface_commit while e.g. eglSwapBuffers may run on another thread
<oeuaoeuoeu>
MrCooper: actually that's what I said in my first message until we derailed a bit. My question was if this is explicitly spelled out anywhere so that I can point people to it. Vulkan speaks about this only very abstractly
<kennylevinsen>
Well you are in #wayland, so I mainly answered from a wayland perspective :)
<oeuaoeuoeu>
Vulkan says: The native window referred to by pCreateInfo->surface must not become associated with a non-Vulkan graphics API surface before all associated Vulkan swapchains have been destroyed.
<MrCooper>
I don't know if it's spelled out anywhere, it's an unavoidable consequence of how Wayland requests are submitted though
<kennylevinsen>
I suppose that could be written slightly clearer
oeuaoeuoeu has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit []
mvlad has quit [Remote host closed the connection]
mvlad has joined #wayland
fmuellner has joined #wayland
manuels2 has quit [Quit: Ping timeout (120 seconds)]
manuels2 has joined #wayland
riteo has joined #wayland
gryffus has joined #wayland
gryffus_ has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #wayland
Dami_Lu has quit [Read error: Connection timed out]
Dami_Lu has joined #wayland
vova has quit [Remote host closed the connection]
Company has joined #wayland
Moprius has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
kts has joined #wayland
garnacho has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
coldfeet has quit [Ping timeout: 480 seconds]
crazybyte has joined #wayland
riteo has joined #wayland
rv1sr has joined #wayland
gryffus has quit []
gryffus has joined #wayland
kts has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
DPA has quit [Ping timeout: 480 seconds]
coldfeet has quit []
coldfeet has joined #wayland
gryffus has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
gryffus has joined #wayland
coldfeet has quit [Remote host closed the connection]
coldfeet has joined #wayland
kts has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
DPA has joined #wayland
kts has quit [Quit: Konversation terminated!]
DPA has quit [Ping timeout: 480 seconds]
hergertme has joined #wayland
DPA has joined #wayland
DPA has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
DPA has joined #wayland
DPA2 has joined #wayland
DPA has quit [Ping timeout: 480 seconds]
rebtoor has quit [Remote host closed the connection]
rebtoor has joined #wayland
rasterman has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
DodoGTA has quit []
DodoGTA has joined #wayland
hergertme has quit [Quit: Leaving]
hergertme has joined #wayland
Brainium has joined #wayland
mvlad has quit [Remote host closed the connection]
leon-anavi has quit [Remote host closed the connection]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium has quit []
Moprius has quit [Read error: Connection reset by peer]
Moprius has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<Company>
zamundaaa[m], emersion: I looked a bit more into how GTK deals with kde_decor and what I said about caring about a system-wide setting was wrong. That setting is no longer exposed as public API in GTK4.
<Company>
however, that setting is assumed to be immutable and available at wl_surface sizing time, so there'd be a bunch of work to do to integrate xdg_decor properly
Brainium has joined #wayland
<Company>
I do think GTK needs some rework to gdk_wayland_surface_create_wl_surface() anyway so it blocks there until the relevant initial data has arrived (scale factor, preferred image description, etc) so it's all not like that needs massive special work
<Company>
but it does need work
nerdopolis has joined #wayland
glennk has joined #wayland
<DemiMarie>
Company: so one idea I had is a way for clients to indicate that they are drawing their own close buttons, so that the server doesn't need to.
<DemiMarie>
The invariant in Qubes OS is that the border must exist, but I don't think it needs to contain any controls.
<Company>
I think the buttons are the smaller problem
<DemiMarie>
Fair
minus has joined #wayland
<DemiMarie>
How hard would it be to get shadows sorted out? I'm fine with providing both server-decoration and xdg-decoration.
<Company>
I do think though that the binary differentiation between csd/ssd doesn't quite work
<DemiMarie>
Not surprised.
<DemiMarie>
What would you prefer?
<Company>
dunno
<Company>
you can make it arbitrarily complex and find ever more corner cases
<DemiMarie>
Off-topic: you will be happy to hear that people are working on GPU virtualization, myself included.
<Company>
I will be happy once it works ;)
<DemiMarie>
MSM renderer is shipping in Chromebooks and used by default. AMDGPU renderer has been merged and i915 renderer is a WIP.
<Company>
I like it mostly because I can annoy people with it and ask questions like how explicit sync should work if a VM maximizes one of its apps and the VM host is already maximized so the app in the VM could get direct scanout
<Company>
but the buffer must travel from app to vm compositor to vm kernel to vm to gnome-boxes to gtk to host compositor to host kernel
<DemiMarie>
Native contexts just expose the host kernel drivers to the guest, so from a compositor or toolkit perspective the app might as well be running on the host.
<DemiMarie>
GNOME Boxes actually has a harder time, because it's an extra layer.
<DemiMarie>
I’m not sure about VirGL or Venus, but they don't meet my security requirements and have worse performance.
<DemiMarie>
I agree that extra complexity is a bad thing.
<Company>
I just think it's fun to think about the problem
<Company>
and annoy developers with questions about corner cases
<Company>
I definitely don't wanna work on it ;)
<Company>
otoh, I use it as a litmus test for the APIs people come up with
<Company>
if they can deal with recursion, they're pretty good
coldfeet has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
rv1sr has quit []
mclasen has quit [Ping timeout: 480 seconds]
Moprius_ has joined #wayland
Moprius has quit [Read error: Connection reset by peer]