ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
psykose has joined #wayland
psykose has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
neonking has joined #wayland
neonking_ has quit [Ping timeout: 480 seconds]
Serus has quit [Quit: reboot]
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
abeltramo5 has quit [Read error: Connection reset by peer]
abeltramo5 has joined #wayland
tzimmermann has joined #wayland
kts has joined #wayland
sima has joined #wayland
kts has quit [Quit: Konversation terminated!]
novakane_ is now known as novakane
psykose has joined #wayland
jsto_ has joined #wayland
jsto has quit [Remote host closed the connection]
systwi has quit [Read error: Connection reset by peer]
<daniels>
emersion: I’m sad the event is gone, but yeah Ab - let’s see what it’s like in the real world and if we really need it then we can add it in v2
Company has joined #wayland
<any1>
I wonder how long it will take for cursor-shape to be adopted by gtk and qt
<any1>
This is how it should have been done from the start. ;)
<d_ed[m]>
merge requests for Qt will be up soonish
<d_ed[m]>
what clients are written with Smithay?
<zzag>
It was mentioned that it's used by winit, so I believe alacritty and things as such will use it
<emersion>
right now fences are managed by the kernel
<emersion>
e.g. to signal a fence, one needs to context-switch to the kernel
<emersion>
same for waiting
<emersion>
or querying
<emersion>
with UMF you can do these things from user-space
<emersion>
i'd recomment just going forward with drm_syncobj
<emersion>
the UMF stuff has been stuck for a very long time and no indication of it getting unstuck
<emersion>
recommend*
<zzag>
is it attached to the graphics memory somehow? or its the only crucial point is that you can signal/wait for it in the user space without context switching?
<zzag>
I'm confused by "user memory" in the name
<emersion>
"user" as in user-space
<emersion>
i'm not sure how it works exactly
<emersion>
maybe gfxstrand can provide more details
<emersion>
by any chance does anybody know what formats PIXMAN_yuy2 and PIXMAN_yv12 are?
<emersion>
nothing in the git log, the access functions are just an unreadable mess
<pq>
I don't know those two.
<pq>
Try fishing on #xorg-devel or the Cairo channel where ever that is?
<emersion>
good idea
<emersion>
cairo doesn't use these though
<pq>
no, but in the freenode days pixman people were on the cairo channel if anywhere
<emersion>
pq, how do you plan to represent the TFs in Weston, if you don't use an enum?
<emersion>
just raw integers?
tzimmermann has quit [Quit: Leaving]
noord has quit [Quit: bye]
noord has joined #wayland
kts has joined #wayland
pochu has quit [Quit: leaving]
<JoshuaAshton>
daniels: If I have QueuePresent in Wayland with FIFO right now and a present that takes longer than my refresh rate (ie. spans multiple frame callbacks), what prevents it from being overriden by another QueuePresent that took much less time directly after?
<JoshuaAshton>
Seems like this is broken in practice too fwiw
<JoshuaAshton>
As the QueuePresent blocking for frame event bodge in Mesa doesn't actually mean that the compositor is going to present with the buffer we submitted on the CPU side as it may not be done on the GPU side.
<JoshuaAshton>
I was speaking to emersion and maybe we should use presentation-time for FIFO? What is preventing that?
<JoshuaAshton>
The alternative is that on our side we only send the frame callback once we get a new buffer from the client rather than unconditionally on every refresh cycle
<emersion>
we need to send wl_surface.commit immediately when presenting, but this proto would let us lock it, and unlock it later on in a separate thread
<emersion>
jadahl: btw any news on that protocol?
gildekel has joined #wayland
<jadahl>
emersion: it got refresh in my head not long ago, need to addres MrCooper's raised issues which kind of defines a "transaction" that covers both subsurfaces wp_transaction and the buffer-readiness stuff
<jadahl>
what is the presentation thread issue?
<emersion>
jadahl: mesa cannot delay wl_surface.commit in vkQueuePresent when implementing VkPresentModes
<emersion>
vulkan clients expect vkQueuePresent to commit the surface
<emersion>
IOW: changing the surface pending state after vkQueuePresent() should not be included in the commit
<emersion>
jadahl: "covers both subsurfaces wp_transaction and the buffer-readiness stuff" → but we don't need to define this here though?
<emersion>
i mean, transactions is just one thing that can hold back a commit
<JoshuaAshton>
I guess really want we probably want is to be able to define a serial on a buffer so a compositor can go thru them in order. Any other solution such as unlocking from the clientside would introduce bubbles of latency.
<emersion>
there are others, like sub-surfaces and buffer readyness
MajorBiscuit has quit [Quit: WeeChat 3.6]
kts has quit [Quit: Konversation terminated!]
<jadahl>
emersion: don't need to cover readiness perhaps, but needs to define a "transaction" that maybe includes (or invalidates) subsurface synchronization
<emersion>
i don't really agree
<emersion>
i don't see why we would want this
<jadahl>
MrCooper: did we only talk about hte transaction stuff on IRC? because I find nothing on gitlab, but still have memory of you raising concerns about how things were formulated
Narrat has joined #wayland
<emersion>
i mean there's no harm saying that the compositor might hold off commits for longer
<emersion>
or that a synchronized sub-surface might hold off commits for longer
<emersion>
but i'd rather not change any existing behavior
<jadahl>
it's more about how to define a transaction, that can coexist with subsurface synchronization, that still makes buffer readiness implementable
<emersion>
it's an additive thing
<emersion>
each one of these things holds off the commit for a bit longer
<MrCooper>
JoshuaAshton: sounds like gamescope might not implement frame events correctly; a frame event is supposed to mark the point after which attaching a new buffer to the surface can no longer prevent a previously attached buffer from getting presented to the user, which is what's needed for FIFO
<emersion>
that's an incorrect interpretation
<emersion>
wl_surface.frame indicates when it's a good time to start drawing the next frame
<emersion>
it might be immediately, that's up to the compositor
<MrCooper>
I think the spec is pretty explicit about that
<MrCooper>
"frame event communicates a good time to start drawing" is folklore at this point, clients may need to start earlier than that to sustain full frame rate
<MrCooper>
jadahl: possibly, don't really remember details about that :(
<JoshuaAshton>
MrCooper: I took a look at other compositors and they were just sending the frame callback without regard for this on every surface every refresh cycle
<emersion>
in any case, there is no such guarantee
<MrCooper>
"If the client commits an update earlier than that, it is likely that some updates will not make it to the display"
<emersion>
"likely"
<jadahl>
MrCooper: too bad, because you had a bunch of good points that forced me to revaluate all the wording, but didn't write anything down :(
<MrCooper>
emersion: there's a small chance the second update will cross the wire at the same time as the frame event, in which case it may make it to the display
<emersion>
this still doesn't say anything about your assumption
<MrCooper>
pq seemed to agree with my interpretation
<emersion>
frame events are for clients with simple rendering loops
<emersion>
if you want to implement FIFO, it's not the right tool
<swick[m]>
it's almost like the frame event is not suitable for implementing FIFO
<MrCooper>
anyway, you can avoid this ambiguity with presentation-time, but then you'll more likely need to start working on the next frame before the event arrives
<emersion>
sure
<swick[m]>
yeah, presentation-time doesn't make anything better
<emersion>
with transactions, you can
<swick[m]>
probably but that seems like a hack
<MrCooper>
with transactions you can what?
<swick[m]>
if we want fifo behavior we should define a protocol to get fifo behavior
<MrCooper>
yep
<emersion>
we've seen how that went in the past
<emersion>
we've like 5 proposals for this now
<swick[m]>
not really
<swick[m]>
I have not seen a single one
<swick[m]>
present-timing maybe
<emersion>
i was speaking about presentation in general
<MrCooper>
jadahl: mainly I think the interactions between transactions and synchronized sub-surfaces are tricky and need to be well thought through and documented (and ideally tested)
<emersion>
these interactions are not tricky at all in my implementation
<MrCooper>
e.g. if a synchronized sub-surface is part of a transaction but its parent is not, or vice versa
<emersion>
sync sub-surfaces use the same internal mechanism as transactions and buffer readyness
rasterman has quit [Quit: Gettin' stinky!]
<jadahl>
MrCooper: yea
<MrCooper>
emersion: I agree something like that should work, just need to make sure the spec spells it out unambiguously
ahartmetz has quit [Quit: Konversation terminated!]
floof58 is now known as Guest977
floof58 has joined #wayland
Guest977 has quit [Ping timeout: 480 seconds]
the_sea_peoples has quit [Ping timeout: 480 seconds]
Hypfer is now known as Guest978
Hypfer has joined #wayland
Guest978 has quit [Ping timeout: 480 seconds]
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
<ahmadraniri[m]>
Hello, I'm trying some examples of qt wayland compositior (from qtwayland5-examples package). It's launchable both from TTY or nested. I notice that if I launch the compositor from TTY, my keyboard input become double, like if I type "l", the output become "ll". It doesn't happen when I launch it as nested compositor. Any clue ? Thanks... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/VjyIVaYBKyvoehNbtvARLoVh>)