ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<i509vcb>
What should happen if a wl_surface.commit is performed with no role or an incomplete role? For no role, there is no documented expected behavior. For incomplete roles (such as xdg_surface without a xdg_toplevel or xdg_popup), the role does not describe the expected behavior either
<i509vcb>
For now I've just decided to ignore the commit if those incomplete or no role cases come up (I think cursor images are an exception here as those do assign a role).
nerdopolis has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
navi has quit [Quit: WeeChat 4.1.2]
nerdopolis has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
silverpower_ has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
kts has joined #wayland
silverpower_ has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit []
mxz has quit [Ping timeout: 480 seconds]
fossdd has quit [Remote host closed the connection]
fossdd has joined #wayland
kts has joined #wayland
Company has joined #wayland
privacy has quit [Quit: Leaving]
glennk has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
kts has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
Guest502 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest630
jkl has quit [Quit: Gone.]
mvlad has joined #wayland
sima has joined #wayland
tzimmermann has joined #wayland
julio7359 has joined #wayland
narodnik has quit [Quit: WeeChat 4.2.1]
Guest572 is now known as rgallaispou
jonesv has quit [Remote host closed the connection]
ogromny has quit [Remote host closed the connection]
dnkl has quit [Remote host closed the connection]
rpigott has quit [Read error: Connection reset by peer]
pitust has quit [Read error: Connection reset by peer]
c7s has quit [Remote host closed the connection]
cpli has quit [Remote host closed the connection]
novakane has quit [Remote host closed the connection]
tommybomb has quit [Remote host closed the connection]
kindablue has quit [Remote host closed the connection]
abcdw has quit [Remote host closed the connection]
raghavgururajan_ has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
kuruczgy has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
guacamolie has quit [Remote host closed the connection]
tsujp has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
leon-p has quit [Remote host closed the connection]
mainiomano has quit [Remote host closed the connection]
dubiousness has quit [Remote host closed the connection]
cat has quit [Remote host closed the connection]
txtsd has quit [Remote host closed the connection]
dorkbutt has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
moses has quit [Remote host closed the connection]
geemili has quit [Remote host closed the connection]
elibrokeit_ has quit [Write error: connection closed]
staceee has quit [Write error: connection closed]
fabiancodes has quit [Remote host closed the connection]
<pq>
i509vcb, my expectation is that the wl_surface.commit does the latching as specified. If the client later gives a proper role to the surface, then the role spec usually says what kind of existing state would be a protocol error.
shankaru has quit [Remote host closed the connection]
rolf has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
rasterman has joined #wayland
kts has joined #wayland
nerdopolis has joined #wayland
vincejv has quit [Quit: Bye bye! Leaving for now...]
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
<emersion>
Wezterm is known to have its maintainer dislike wayland
<emersion>
oh, no, nevermind, i'm mixing it up with another terminal emulator
<emersion>
("wayland sucks, so i'm still going to support it, but will not try to understand it")
<ifreund>
I think my favorite part of the log is the commit with old dimensions, xdg_toplevel.set_window_geometry with new dimensions, commit again without attaching new buffer part
<ifreund>
which are commits 2 and 3 after acking the configure
<YaLTeR[m]>
my favorite part is how it waits for a 0 configure at startup
<ifreund>
hah, I didn't notice that because my compositor still sends 0 configures as the first one (shame on me I know, I need one more wlroots release before I can fix it though because of reasons)
<Company>
finally someone is fuzzing the compositors properly
Leopold has quit [Remote host closed the connection]
<vyivel>
ifreund: if you want to "fix" it right now, wl_event_source_remove(wlr_xdg_surface.configure_idle) on initial_commit=true
<ifreund>
oh true, that would work
Leopold_ has joined #wayland
<Company>
ifreund: usually that happens when people have an old codebase, that doesn't have a "commit" stage
<Company>
the initial port is always one where every action that requires a commit is immediately committed
<Company>
seems to be what's going on here
<Company>
set_title(); commit();
<Company>
especially with X11, because that's how X11 works - everything is instantly "committed"
<pq>
is there a good write-up about "don't immediately commit every single action"?
<ifreund>
Company: yeah, I definitely see how it could happen. The bug is probably acking the configure right away instead of waiting until a buffer of the correct size is ready
<vyivel>
(set_title isn't even double-buffered)
<pq>
flushing seems to be similar, except it's not fundamentally harmful.
<ifreund>
Compositors should be able to deal with this misbehavior just fine of course, I just wish the client authors realized that they are sacrificing frame perfection
<pq>
no, there are some cases that are defined to be protocol errors
<pq>
mismatching maximized size comes to mind
<ifreund>
right, though does anyone enforce that?
<pq>
I would think Weston does.
<vyivel>
weston does indeed
<vyivel>
and nothing else iirc
<pq>
everyone certainly should, because it says so in the spec
<ifreund>
It also says that clients cannot commit a larger buffer than requested while the resizing state is set
<ifreund>
but mpv does so in order to maintain its aspect ration and I think it's right to do so
<ifreund>
ideally there would be some way in the protocol to communicate that aspect ratio stuff in a policy over mechanism way but there isn't
<pq>
why not constrain by the more restrcitive dimension instead of exceeding given size?
<ifreund>
because you couldn't make it bigger then unless you manange to keep your curson on exactly the right line while resizing
<emersion>
pq, enforcing would break a whole bunch of clients
<pq>
sure you could make it bigger, it would just fit inside the rectangle whose one corner is the pointer position
<emersion>
pq, also unclear what a client with maximum size set should do when the compositor configures it maximized with a larger size
<pq>
apps should be broken fast and early, so that all the corner cases can be found and decided what to do about them
<emersion>
yeah it's just a bit late now
<pq>
does it need a protocol spec change, or is it an app bug
<YaLTeR[m]>
pq: You can't with one sided resizing
<pq>
just keep it in mind for every new feature coming from now on, at least
<pq>
YaLTeR[m], that's true.
<ifreund>
pq: Yeah I totally agree with the protocol errors for any misbehavior take, it just needs to be enforced from day 1 to be effective
<pq>
the answer is to rethink the spec, not ignore the spec
<emersion>
easy to say :)
<YaLTeR[m]>
pq: the problem with killing on maximized mismatch is not so much that it wasn't enforced, but more that it's also a very rare edge case, so even if all compositors enforced it, the client devs wouldn't hit it on their setup
<pq>
immediate pain vs. future pain
<Company>
pq: the commit stuff is one of the worst things about Wayland anyway
<pq>
Company, you can stick to X11, it's fine.
<Company>
pq: because app devs should never commit ever, because that's the job of libGL
<pq>
yeah, and apps who don't use libGL...
<Company>
so you don't just need to reorganize your whole backend, you also need to wrap it around your GL usage
<YaLTeR[m]>
So at this point it's better to just work around in the least disruptive way (i.e. clip on size mismatch instead of killing), similar to how in a compositor you want early returns on programming bugs instead of assert
<Company>
YaLTeR[m]: render pink!
<ifreund>
oh no, I want asserts in my compositor
<Company>
people hate that and file bugs, but it doesn't kill any apps
<ifreund>
any high reliablity code should be full of asserts IMO
<pq>
we do fill Weston with asserts
<Company>
YaLTeR[m]: see also: gtk4paintablesink shader nodes ;)
<kchibisov>
set_title doesn't require commit if it matters.
<kchibisov>
And some other stuff also doesn't.
<Company>
it gets people to actively resolve the issue and it's less finger-pointing than crashers
<Company>
it's harder to figure out what's wrong though if its smallish things
<Company>
like a single pink frame when maximizing
<Company>
because there's no trace, unless you also log something about it
<YaLTeR[m]>
if only the half decent solution didn't also involve 3 different ways across 3 different gtk version ranges
<pq>
How about that nag protocol extension I've dreamed about a few times?
<davidre>
The compositor could paint "This client is buggy, go harass its developer" in the corner of the window :P
<pq>
and mentioned here
<Company>
YaLTeR[m]: there's multiple bugs in there, and at least the GTK ones are fixed now - I think GStreamer still doesn't tell that the buffer is opaque and that whole mess is unnecessary :p
<davidre>
pq What's the nag extesion?
<pq>
a tiny protocol extension that compositors could use to send messages into clients' logs, like "you're doing it wrong, but I'm covering for you"
<ifreund>
I would implement a nag protocol for the broken commit handling stuff
<kchibisov>
ifreund: wezterm is generally broken and given that the project is overly complex noone will bother fixing it, given that all the relevant fixes stuff are provided for like 2 year.s
DodoGTA has quit [Remote host closed the connection]
<kchibisov>
We still have to issue patch releases in sctk for old broken versions just to somehow keep wezterm alive.
<ifreund>
kchibisov: yeah, pretty much what I thought
<YaLTeR[m]>
It will only work if the protocol involves the client communicating the app developer's email address to send the nag to
<kchibisov>
it'll stop working once someone add new shm format.
DodoGTA has joined #wayland
<davidre>
pq: Would rely on the client implementing the extension correctly, has to be part of the wire protocol like an error
<pq>
YaLTeR[m], that's miles better than "I sometimes see a pink flash, help"
<davidre>
New message type "nag"
<Company>
the most evil thing to punish an app is to make it lag
<Company>
just don't render a new buffer for half a second
<YaLTeR[m]>
Also I mean, the clients are free to submit whatever size they want to a normal configure. Qt doesn't even bother to communicate min size for example
<kchibisov>
you don't need min size if you can render at any size.
<YaLTeR[m]>
Company: that strategy is currently being tested by Nvidia proprietary drivers
<pq>
yet another tiny protocol extension coming to my mind is, when a compositor smashes a client with an actual protocol error, it could first send a log of the most recent protocol messages leading to the error, likewise for the client to put into its logs
<d_ed[m]>
> Qt doesn't even bother to communicate min size for example
<d_ed[m]>
that's not true
<d_ed[m]>
oh
<YaLTeR[m]>
Dunno, flatpak telegram and obs don't set min size here
<YaLTeR[m]>
they sure have one just don't tell the compositor about it
kts has joined #wayland
<pq>
that way there is no need to repeat the error with `WAYLAND_DEBUG=server`, and people use `WAYLAND_DEBUG=client` instead because its easier but also does not pinpoint the failing reqeust.
<pq>
even just 2 kB of plain text protocol dump might help, I imagine
<vyivel>
this could be implemented as a proxy probably
<emersion>
yeah, akin to Vulkan validation layers
mart has joined #wayland
<pq>
a) get server's view of the protocol messages, b) save that with client's own logs, c) always enabled in production
<pq>
like any flight-recorder type of thing should
<pq>
so there is no need to attempt to reproduce to get this bit
<d_ed[m]>
<YaLTeR[m]> "Dunno, flatpak telegram and..." <- I checked flatpak telegram here, debug log showed it being set fine
<pq>
one could probably shove that in wl_display.error event, too
<emersion>
i'm not convinced, pq
<vyivel>
hm, i can probably do that on compositor side with wl_display_add_protocol_logger
<pq>
vyivel, exactly.
<emersion>
i have a hard time thinking that clients will do anything useful with the info
<pq>
emersion, even getting it out to their stderr would probably help.
<YaLTeR[m]>
d_ed[m]: weird, I'll need to double check
<emersion>
so, what should we do about that set_maximum_size + maximized state issue
<emersion>
forbid compositors from sending a configure size inconsistent with the client constraints?
<emersion>
allow clients to disallow the configure size if it's outside of their constraints?
<emersion>
err
<emersion>
allow clients to disobey the configure size if it's outside of their constraints?
<emersion>
what about race conditions when setting the constraints?
<davidre>
Well
<pq>
what should happen when there is no size at all that would make both compositor and client happy?
<davidre>
currently it says
<davidre>
> The client should not rely on the compositor to obey the maximum size.
<davidre>
But we have cases already where we have app developers not happy that their Qt apps are sized smaller than minimum size on wayland
<ifreund>
would they rather the compositor inform them that the program will be sized smaller or just lie to the client and crop the buffer?
<ifreund>
cause as a compositor author, I will do what the compositor user wants not what the app wants
<d_ed[m]>
the user wants their apps to work!
<d_ed[m]>
they're the same thing
<ifreund>
the user may want the app in question to be in a tiling layout where it is visible but not at a usable size until given focus for example
<kennylevinsen>
in the prefect world, all constraints are compatible
navi has joined #wayland
<ifreund>
or what if for example, the minimum size is larger than the size of the output?
<ifreund>
(in any dimension)
<kennylevinsen>
e.g., the issue with minimum size would often be in tiling, where there isn't more space to give, so rendering larger means spilling over other things which makes no one happy...
<pq>
Scroll bars. No, seriously. If compositor has to make a window smaller than the app can arrange its GUI, then the only way it can work is some kind of scrolling thing. Maybe automatically by pointer position. Or scaled down, if legibility is less important.
<kennylevinsen>
(I often try to stack telegram, signal and IRC vertically on the side of my monitor for example, and telegram annoyingly refuses to render that small when on 1920x1200, spilling over the top of my signal window :( )
<d_ed[m]>
What we should do is document that apps should fit the space asked by the compositor whatever it is. Then write robust compositors that can handle that being not the case, in a non-perfect middle ground. Whether that's unmaximising/ cropping / scaling/letterboxing / rendering warnings.
<kennylevinsen>
(but in that case the issue is of course that telegram has a somewhat arbitrary minimum size, which could easily have been smaller - I wouldn't have tried if the UI wouldn't fit)
kts_ has joined #wayland
<davidre>
We changed Qt so it will now obey and become smaller
kts_ has quit [Remote host closed the connection]
<davidre>
It sometimes not sending min_size is a bug that's fixed in the next patch release
<davidre>
* It sometimes not sending min_size as well is a bug that's fixed in the next patch release
<ifreund>
that's nice to hear :)
<kennylevinsen>
pq: clipping and scrollbars would be a bit wonky with csds, but in the case where UI elements truly cannot be shown that small, having the compositor try to help seems somewhat reasonable. The user both wants a useable app *and* for it to fit in a certain space after all
<kennylevinsen>
davidre: :D
<pq>
too bad I couldn't find a video of Weston's output zoom, now deleted feature I think. That was one possibility for mouse users in how to fit a big thing in a small viewport
kts has quit [Ping timeout: 480 seconds]
<pq>
but all this sounds like clients would not need to honour max size limits if they cannot?
<pq>
limits imposed by a compositor
<pq>
a compositor can always scale or crop+scroll client content that is too big for the space
<pq>
UX without a mouse though...
kts has joined #wayland
kts has quit [Remote host closed the connection]
Brainium has joined #wayland
mohit8158226 has quit [Quit: mohit8158226]
kts has joined #wayland
mohit8158226 has joined #wayland
<YaLTeR[m]>
d_ed: flatpak telegram does indeed send min size now, flatpak obs still not. Guess it's a recent fix
<kennylevinsen>
random friday thought: I feel like there should be a YUV121010 format to get more out of a 32-bit pixel than XRGB2101010
<pq>
good point
<kennylevinsen>
or YUV160808, might fit better as a multi-plane format. Not sure which balance is right.
<pq>
wonder if 1688 would be enough chroma too
<kennylevinsen>
I mean, with my very limited understanding of how borked our vision is, I imagine we'd get more out of "moar luma"
<pq>
certainly
<pq>
one could do a test: render some gradients in BT.2020 YUV160808, convert to RGB32F, clip to BT.709, and see if the surviving parts of gradients exhibit any banding.
silverpower has quit [Ping timeout: 480 seconds]
<kennylevinsen>
I'd have to look up some color math then :)
<kennylevinsen>
hmm, clipping to bt.709 would clip saturation right? so we're reducing the chroma resolution further. What would that test actually tell us? :/
silverpower has joined #wayland
fmuellner has joined #wayland
<kennylevinsen>
other than "chroma is so abundant it doesn't band even after throwing bits away"
<pq>
exactly
<pq>
BT.2020 is probably the widest color gamut for practical uses, so if there is enough chroma precision to cover that all, then it's probably good enough.
<pq>
unfortunately we cannot display full BT.2020, so we have to display a part that is actually doable, like BT.709
<pq>
if that part looks like, then we could guess that maybe the other parts are good enough as well
<pq>
*looks fine
<pq>
or you could some serious scientific modeling, but I thought this would be a more fun experiment :-)
fmuellner has quit [Ping timeout: 480 seconds]
mart has quit [Quit: Konversation terminated!]
<MrCooper>
emersion: how can I tell gamescope which DRM device to use in a VT?
tzimmermann has quit [Quit: Leaving]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
ity has quit [Remote host closed the connection]
ity has joined #wayland
<emersion>
MrCooper: it's synced with the Vulkan device
<emersion>
iirc
<MrCooper>
that doesn't seem to work, the KMS atomic cap test fails (as it would for the other GPU)