07:43 wlb: weston/main: Philipp Zabel * pixman-renderer: hold a reference for renderbuffers on the output state list https://gitlab.freedesktop.org/wayland/weston/commit/07734a2564c1 libweston/pixman-renderer.c
07:43 wlb: weston Merge request !1133 merged \o/ (pixman-renderer: hold a reference for renderbuffers on the output renderbuffer list https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1133)
08:14 wlb: weston Merge request !870 closed (compositor: Preserve content from early-destroyed SHM buffers)
08:14 wlb: weston/main: Daniel Stone * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/07734a2564c14e3a0b3a5c7a9897679dc09cc31f...3c6cfe6bf4cea2f6c22ce68f743c0bae1321e0e4
08:14 wlb: weston Merge request !736 merged \o/ (Multi-GPU support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/736)
08:25 wlb: weston/main: Derek Foreman * xwm: Init window link after removing it https://gitlab.freedesktop.org/wayland/weston/commit/8e1d7fe4da7d xwayland/window-manager.c
08:25 wlb: weston/main: Derek Foreman * xwm: Add support for xwayland_shell_v1 https://gitlab.freedesktop.org/wayland/weston/commit/87881e2cf621 protocol/meson.build shared/xcb-xwayland.c shared/xcb-xwayland.h xwayland/meson.build xwayland/window-manager.c xwayland/xwayland.h
08:25 wlb: weston Merge request !1037 merged \o/ (Add support for xwayland_shell_v1 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1037)
08:33 wlb: weston/main: Marius Vlad * xcb-client-helper: Add a XCB client helper for tests https://gitlab.freedesktop.org/wayland/weston/commit/640a3c7165dd tests/xcb-client-helper.c tests/xcb-client-helper.h .gitlab-ci.yml .gitlab-ci/debian-install.sh tests/meson.build tests/xwayland-test.c
08:33 wlb: weston Merge request !946 merged \o/ (xcb-client-helper: Add a XCB client helper for tests https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/946)
09:09 wlb: wayland Issue #363 opened by Pekka Paalanen (pq) Dream: Backward compatible clean-up of libwayland-server ABI https://gitlab.freedesktop.org/wayland/wayland/-/issues/363 [IPC library], [Scanner], [wl_shm]
09:18 emersion: thanks for the write-up pq!
09:20 emersion: i largely agree with all of that
09:21 emersion: (well except for the part about rust but that's a given at this point lol)
09:25 emersion: ofourdan: would there be a way to reparent only windows which are using xshape?
09:26 emersion: tbh i don't know much about reparenting, what changes does it make?
09:27 ofourdan: that's a good question - do tell that a client is using xshape, one would have to check if the client has set the shape extends, but a client would probably not do that if the xserver does not support shape...
09:28 ofourdan: s/do/to/
09:28 ofourdan: ah wait
09:28 ofourdan: context switch error on my side
09:29 ofourdan: that would be w/out diableing the shape extension i nthexserver, so yeah, the client could use xshape and the x11 wm can then check whether the client has set any shape extents
09:30 pq: emersion, glad to agree for once. :-)
09:31 ofourdan: wrt to reparenting, it's just reparenting the shaped window into a wm's own (unshaped) x11 window, so that the wayland compositor does not have to translate the shape into opaque regions.
09:31 emersion: ofourdan: can the XWM get an event when xshape is enabled/disabled?
09:31 emersion: hm
09:31 ofourdan: it does nto get an event, it queries the window using e.g. XShapeQueryExtents()
09:31 ofourdan: wait maybe there is an event as well
09:31 emersion: right but what happens if the client changes the shape while mapped?
09:31 emersion: hm i guess there's an event for X11 compositors anyways
09:32 ofourdan: yeah
09:32 ofourdan: I do nto remember which one though
09:32 emersion: the shaped windows can be used by O-R windows, can reparenting still happen there?
09:33 ofourdan: yeah, ShapeNotify
09:33 emersion: cool
09:33 ofourdan: sure, you can reparent O-R as well
09:33 emersion: (because O-R is not supposed to be touched by the XWM in theory AFAIU)
09:33 emersion: ok
09:34 ofourdan: iirc, you would also need to select SubstructureNotifyMask and SubstructureRedirectMask on the wm parent window
09:34 ofourdan: but I do not think that would be a huge chnage
09:35 ofourdan: maybe it;s not worth it - for xeyes, I think it;s a bug in xeyes :)
09:35 pq: If O-R is reparented, does that actually work? Wouldn't the X11 client be wanting to position that O-R window in global coordinates, but now it gets clipped to WM installed parent window?
09:36 pq: Would the WM need to play catch-up the parent window position/size with the O-R window position/size?
09:40 ofourdan: mny x11 wm use reperenating even on O-R windows
09:40 ofourdan: *reparenting
09:41 pq: oh, alright
09:41 MrCooper: ofourdan: what is a bug in xeyes?
09:41 ofourdan: iirc the x11 wm would not get the configureRequest for O-R window, only configureNotify
09:42 ofourdan: MrCooper: it does not clear/repaint the shaped areas when xshape is not available from the xserver
09:43 MrCooper: ah
09:50 MrCooper: maybe somebody should add support for xeyes to use an RGBA visual instead of a shape for output (probably still want to use shape for input though)
09:51 ofourdan: yeah, ala cairo-clock :)
10:22 MrCooper: yeah, that's a classic
11:49 ifreund: I wish there was some meaningful way WAYLAND_DEBUG could show array contents...
11:49 ifreund: (I'm well aware that it can't really, just wanted to complain a bit)
11:49 jadahl: ifreund: you and me both
11:51 ifreund: I suppose we could add an optional element size attrible to the xml for array arguments
11:51 ifreund: and an optional enum attribute
11:52 ifreund: I'd certainly use those in my wayland scanner too if available to generate more type-safe code
11:53 pq: what about int/unsigned/float?
11:55 pq: int/unsigned/float/enum/other + element size (0 for variable element size) could be doable
11:56 pq: assume CPU-endian, and forbid non-power-of-two sizes in bytes for everything except 'other'
11:57 ifreund: pq: I'd stick to the types already used by the protocol I think...
11:57 ifreund: <arg name="states" type="array" element-type="uint" enum="state"/>
11:57 pq: IIRC I do use arrays to carry float, because that's the only way to carry literal floats
11:57 ifreund: yeah, but why weren't they just made a first class type in the protocol?
11:58 pq: and that's the only type you could not have, that is not in the protocol already
11:58 pq: because not all ARM CPUs had FP support back then, or something like that
11:59 ifreund: I see, so when we started writing protocols that used floats we decided to just stuff them in an array rather than adding proper support
11:59 pq: we could add 'float' type to the protocol even today, just not 'double' nor 64-bit
12:00 ifreund: what uses floats currently?
12:00 pq: not even that: just encode as integers
12:00 pq: weston's private touchscreen calibration extension
12:01 ifreund: ah
12:01 ifreund: looks like linux-dmabuf has the most exotic array usage I can find in wayland-protocols
12:01 ifreund: 32 bit int + 4 bytes padding + 64 bit int
12:02 pq: array is essentially just a blob
12:02 pq: it's caller array only because of wl_array
12:02 JEEB: :D
12:02 ifreund: yeah...
12:03 pq: and the difference to string is... umm...
12:03 ifreund: strings are 0 terminated right?
12:03 ifreund: for an unknown reason because they also have a specified length
12:03 pq: yeah
12:04 ifreund: they're also nullable, I think that's probably why they're 0-terminated on the wire
12:05 ifreund: :q
12:05 pq: I'm not sure empty vs. null is meaningful difference, but it's there.
12:05 emersion: there was some discussion in https://patchwork.freedesktop.org/patch/166063/
12:05 emersion: https://gitlab.freedesktop.org/wayland/wayland/-/issues/332 tracks this
12:06 pq: oh, decimal vs. hex
12:07 emersion: ifreund: linux-dmabuf only stores int64_t indexes in wl_array
12:07 emersion: the shm FD contains the structured data
12:07 emersion: err, int16_t
12:07 ifreund: ah, I read too quickly
12:08 pq: how do we get the printing hint from XML into libwayland?
12:09 pq: more magic into message signature strings? I'm not sure if they stretch even further.
12:10 ifreund: I think that's the only real option
12:11 pq: or extend the language binding ABI with a new marshalling function... oh but that works only for sending
12:12 ifreund: I wouldn't need any libwayland changes to make use of new xml attributes for type safety in my scanner
12:12 pq: I know.
12:12 ifreund: the only concern here wrt libwayland changes is pretty-printing as far as I see
12:13 pq: yes
12:13 ifreund: I think something like a[i] or a[u] would be fine for the type, getting the enum hint to the printer that way seems too ugly though
12:13 pq: and verify in the scanner that the annotations are valid
12:13 ifreund: yeah, that too
12:14 ifreund: maybe pretty printing enum names is too ambitious for libwayland, printing the values of the array would already be a huge help
12:14 pq: oh, nothing is generating enum value name tables for now
12:15 pq: yes
12:16 jadahl: maybe we can start putting that in the protocol code file exposing it via a _to_string() API
12:16 jadahl: could be useful in its own
12:17 pq: I've been dreaming of new Wayland bindings for C to ditch libffi, which means a new scanner, so we could even generate enum argument types if that's a good idea.
12:17 pq: jadahl, how do you get libwayland to call that?
12:18 ifreund: I'll put together a patch adding the xml annotations and printing values for int/uint.
12:18 pq: oh well, simply printing just 32-bit words could help a lot.
12:18 ifreund: I think that's pretty tightly scoped but would still be a meaningful improvement
12:19 jadahl: pq: we'd need to reference it from the interface some how
12:19 emersion: pq, do you know why we use libffi?
12:20 pq: jadahl, yeah, how? I don't think the structs are versioned in any way. :-)
12:20 jadahl: pq: I wouldn't be able to answer that without trying. my brain is not up to date about all those details
12:21 pq: emersion, I guess because it was a practical way to have the interface handler functions called with the right arguments and type safety, and not generating dispatcher code with scanner.
12:21 pq: emersion, the API use by all other lang bindings came much much later.
12:24 pq: emersion, many odd details in libwayland are probably because they were "cool tricks", like wl_fixed_to/from_double.
12:24 ifreund: what would the alternative look like in C? In zig I use compile-time metaprogramming to handle the dispatching and make it type safe
12:25 ifreund: would a C version using the non-ffi API generate a separate C dispatcher function for each protocol?
12:25 ifreund: s/protocol/interface/
12:25 pq: ifreund, we'd do the equivalent in C, too. Generate a dispatcher function for each message that unwraps the arguments to call a properly typed function pointer.
12:26 pq: When we have a build-time code generator and the signatures are fixed at build-time, there is no real need for libffi.
12:27 emersion: yeah
12:27 emersion:pretty wary of "cool tricks"
12:27 ifreund: yeah makes sense
12:28 ifreund: If anyone's curious this is my Zig dispatcher https://github.com/ifreund/zig-wayland/blob/e9484c814801b520cbe4ed719cceb4d0a59f1341/src/common_core.zig#L86
12:29 ifreund: I generate a tagged union for the message types and this function reflects on that generated tagged union type to do marshaling
12:30 ifreund: might be able to make it a bit cleaner, been a while since I've looked at it
12:30 emersion: i must say, comptime looked like a good way to do generics but i'm a bit disappointed that it's basically copy-paste
12:30 emersion: ie, i can write non-sensical code with comptime, and the non-sense only gets found out when a particular comptime call triggers it
12:31 emersion: sorry, this is off-topic
12:31 emersion: (so when do we rewrite libwayland in zig :P )
12:32 ifreund: once zig is stable :P
12:33 emersion: "you can't rush art"
12:34 ifreund: emersion: since comptime is also how zig does conditional compilation, the compiler needs to be lazy in at least some cases. That said, there are likely cases where we can make it less lazy than it is now without breaking things
12:35 emersion: hm, what i meant was that it
12:35 emersion: 'd be nicer if the type constraints were clearly defined for a given comptime function
12:36 ifreund: yeah, I totally get that complaint. I think that road leads to haskell/ML style type classes though
12:36 emersion: which is clearly a trade-off, because type constraints make stuff more complicated as well
12:36 ifreund: and I'm not sure if that's the right road for zig to take
12:36 emersion: i was thinking rust but sure :P
12:37 emersion: yeah, it's a choice
12:37 ifreund: just gotta pick the right language for the job, I've found Zig to be fantastic for writing wayland compositor code :)
12:38 emersion: or so i've heard :)
15:49 kchibisov:still hopes for a future without libwayland hard dep for any real wayland client side stuff.
18:33 wlb: weston Merge request !1182 opened by Sergio Gómez (SergioGDR) Disable pointer constraint if last commit unmapped the view https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1182
20:39 yshui`: hi, i am here with a wl_buffer.release question again. i can think of 2 cases when a buffer is "no longer used by the compositor". one is when the client attached a new buffer to the surface, and this new state become the current state through a series of wl_surface.commit; the other is when the compositor has made a copy of the content of the buffer, and thus no longer needs to access the buffer.
20:40 yshui`: I assume the compositor will send wl_buffer.release in both cases?
20:42 yshui`: another question is, is a released buffer is detached from all surfaces, then attached to a surface again, would it receive a release event again in the future?
20:43 bl4ckb0ne: yes
20:45 bl4ckb0ne: when the surface is committed
20:46 bl4ckb0ne: about the first case iirc its a client error to attach two buffers to a surface before committing because only the last one will get a release event but ill have to check
20:47 soreau: you could probably check with WAYLAND_DEBUG to get a picture of what $compositor actually does
20:47 bl4ckb0ne: https://gitlab.freedesktop.org/wayland/wayland/blob/master/protocol/wayland.xml#L1395
20:49 yshui`: > attach two buffers to a surface before committing
20:49 yshui`: I don't think that's what i described?
20:49 yshui`: soreau: i am more concerned with what the spec think should happen.
20:50 bl4ckb0ne: ah yes sorry, missread there
20:51 bl4ckb0ne: https://gitlab.freedesktop.org/wayland/wayland/blob/master/protocol/wayland.xml#L449 also relevant
21:42 yshui`: yeah i think the spec agrees with what i said (so yes to both questions), but i am not very confident with my reading.
21:51 bl4ckb0ne: from your client?
22:20 ifreund: [1516900.551] wl_keyboard@20.enter(220677, wl_surface@3, array[22,29,42])
22:20 ifreund: that's something :)
22:26 wlb: wayland Merge request !300 opened by Isaac Freund (ifreund) scanner: allow element-type and enum on array args https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/300
22:28 wlb: wayland Merge request !301 opened by Isaac Freund (ifreund) Draft: scanner: allow element-type and enum on array args https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/301