ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
peeterm has quit [Read error: Connection reset by peer]
peeterm has joined #wayland
ofourdan has quit [Remote host closed the connection]
pavlushka has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mdb977 has joined #wayland
<mdb977>
Hi There, I'm on an embedded device using Weston and currently fiddling with SELinux. If I connect a physical keyboard, Weston crashes with 'file descriptor expected, object (21), message keymap(uhu)' and 'Fatal error: invalid argument'. Everything is fine without SELinux enforcing. Unfortunately, the audit log shows no clue. Does anybody have a tip on which direction to look at?
<vyivel>
mdb977: wl_keyboard.keymap carries a keymap fd, perhaps selinux prevents it from being passed over the unix socket connection for some reason?
<pq>
mdb977, are you sure it's Weston crashing? To me that looks like a client error message. Anyway, vyivel has a good quess.
<pq>
zamundaaa[m], yeah, sounds good enough to me. Maybe check with swick, too.
riteo has joined #wayland
leon-anavi has quit [Read error: No route to host]
leon-anavi has joined #wayland
<riteo>
hi people, I'm a bit on a shaky connection so sorry if I quit-join
<riteo>
so libdecor still has this whole visibility-change-does-not-work thing with SSDs and I looked around to see what other clients do
<riteo>
it looks like people just assume that xdg-decoration-manager == SSDs? Is that even in spec?
<riteo>
Like, the protocol description goes "This interface allows a compositor to announce support for server-side decorations.", not "This interface announces support for server-side decorations."
<riteo>
could somebody please help me how I should go forward?
<davidre>
the compositor will tell you the mode you should use
<riteo>
ye but you have to configure a whole toplevel first
<zamundaaa[m]>
riteo: imo that's an oversight in the spec text
<riteo>
zamundaaa[m]: what do you mean?
<riteo>
(btw, if some of you have dejavu I already talked about this a year or so ago)
<zamundaaa[m]>
The assumption is that if the global is supported, the compositor also does support SSD
<riteo>
and is that assumption correct?
<zamundaaa[m]>
Of course, with window rules or whatnot, it might still tell you to do CSD instead
<davidre>
libdecor also follows the mode
<davidre>
if the compositor says CSD it will do CSD
<riteo>
yea but libdecor does not allow hiding SSD decorations
<riteo>
like, if I want a borderless window on KDE I just... can't
<davidre>
You can't
<riteo>
it depends on a protocol update that never got merged
<riteo>
or implemented
<davidre>
There's a trick
<zamundaaa[m]>
riteo: It does not
<davidre>
you destroy the xdg_toplevel_decoration
<davidre>
so the compositor doesnt know that you can handle SSD
<zamundaaa[m]>
libdecor could very much request CSD, and that would work just fine
<davidre>
But of course the compositor can always double decorate CSD clients
<davidre>
But the compositor can do what it wants in general
<riteo>
zamundaaa[m]: that's what the current code does, I'm not sure why it does like that but right now it explicitly checks for this non-implemented version
<riteo>
zamundaaa[m]: so all versions of libdecor are currently broken on SSDs
<bitblt>
I have some questions about the api usage though that neither the above, nor the official api documentation (https://wayland.app/protocols/) where explicit about
<bitblt>
question no1: when binding the global objects with wl_registry_bind, should I use hardcoded interface versions? why shouldn't i use the version param of the wl_registry_listener.global callback?
<zamundaaa[m]>
bitblt: you should use `min(highest_version_you_support, version_from_callback)`
<zamundaaa[m]>
If you just use the version from the callback, you might be opting into behavior that changed with newer versions vs. from what you implemented
<bitblt>
ah I see
<bitblt>
I suppose this behavior might change, but the callbacks / types / function will remain the same?
vincejv has quit [Ping timeout: 480 seconds]
<bitblt>
I thought that versioning was actually implemented with different protocol (definitions) xmls
<ifreund>
adding events and requests to a protocol is a backwards compatible change
<bitblt>
Is there any example of why I should use `min(highest_version_you_support, version_from_callback)` for the version?
<ifreund>
if you tell the server to send events for a version that your client doesn't actually support, your client will get killed by libwayland as it does not recognize the newer events
soreau has joined #wayland
<bitblt>
ok I suppose that means I should be specific in the version of libwayland-client I'm linking into, and check what versions are the globals in this libwayland-client and use these in the registry_global_handler
<ifreund>
bitblt: this has nothing do with the version of libwayland client you are linking, it has to do with what version of the protocol interfaces your client implements
<ifreund>
(aside: libwayland makes this much more of a footgun than it needs to be, zig-wayland makes it impossible to write this bug)
<ifreund>
I require the user to specify the maximum version of each global interface they implement at build time and only generate requests/events/interfaces up to that version, and then generate the min(supported, advertised) automatically on bind
<bitblt>
ok, I need to wrap my head around this a bit more, but I think I have the info I need for this
<bitblt>
onto the next question
<bitblt>
question no2: when should I do a `wl_display_roundtrip(wl_display)` instead of a `while (wl_display_dispatch(display) != -1){}`?
<bitblt>
as far as I understand both kinda force requests/events up to this point to be handled (either by the server/client or both)
<ifreund>
in practice, wl_display_roundtrip() should only be used once on startup and maybe once on shutdown if you need to ensure the server gets a request before exiting
<ifreund>
in case you're not clear on the difference: wl_display_roundtrip() is an abstraction over the wl_display.sync request
<ifreund>
and has different semantics from a "normal" fully async dispatch
<ifreund>
see the libwayland doc comments or implementation for details
<ifreund>
and perhaps the docs for the wl_display.sync request
<bitblt>
how is wl_display.sync different from looping over a wl_display_dispatch until the event queue is exausted? I suppose the main difference is that the second one will block and await for events when empty?
<ifreund>
bitblt: wl_display_roundtrip waits for the server's reply to the wl_display.sync request
<ifreund>
since events/requests are processed in order, the client knows that once the server has replied to the sync request, the server has also recieved all requests sent prior to the wl_display.sync request
<ifreund>
since it does not make a wl_display.sync request, wl_display_dispatch() gives no such guarantees
<bitblt>
ah I see
<bitblt>
ok last question for today:
<bitblt>
I'm pretty confused about how xdg_surface_listener.configure and xdg_surface_ack_configure work, along with rendering and wl_surface_commit
<bitblt>
As far as I understand various events before xdg_surface_listener.configure will arive, in which wayland server tells the wayland client what surface size, decorations etc he should ideally have
vincejv has joined #wayland
<bitblt>
when the xdg_surface_listener.configure arrives it is like a 'commit' request from the server for these preferences
<bitblt>
I don't see a reason that xdg_surface_ack_configure should exist, I mean the wayland client could just take his time, render the new surface and commit it after that .configure event?
<ifreund>
bitblt: since the protocol is asynchronous, the server needs a way to know if the client received a given configure event before it made the wl_surface.commit request
<ifreund>
ack_configure is this mechanism
<bitblt>
aha yeah that makes sense
<bitblt>
so because the order of the requests from the client is guranteed, this means that the server can know that the configure was handled before the commit, because the ack will arrive before the commit in this case
<ifreund>
indeed
<bitblt>
is there any specific example that this is useful for the wayland server?
<ifreund>
it's necessary for frame perfection in many cases
<ifreund>
for example during interactive resize with server-side decorations
<ifreund>
or when resizing multiple clients at once in a tiled layout
<soreau>
if the client has a min/max size, it might not attach a new buffer