02:57 DemiMarie: orowith2os[m]: why not Rust?
02:57 DemiMarie: Serious question
02:57 DemiMarie: orowith2os[m]: this is for the compositor work, obviously
02:58 DemiMarie: changing the signature of a function is technically an API-breaking (but not ABI-breaking I believe) change because of function pointers, but I would be fine making users add explicit casts if they need them.
02:59 danieldg: correct, so long as it's not C++ (the consts end up in the symbols due to mangling there)
03:01 orowith2os[m]: DemiMarie: I don't want to deal with SDL3 and Rust for Wayland right now.
03:01 DemiMarie: orowith2os[m]: had not considered the SDL3 requirement
03:02 DemiMarie: there are mature Rust crates for Wayland, though
03:02 orowith2os[m]: I could very well also use GTK4, I just need a cross-platform GUI toolkit that lets me access enough of the system to expose an equivalent Wayland API.
03:02 orowith2os[m]: Not even GUI, actually? Windowing library is just fine.
03:04 orowith2os[m]: I won't be relying on smithay or wlroots or libweston because I want to do the work myself, as a learning experience, and because I probably wouldn't even need all that with a simple windowing library.
03:05 orowith2os[m]: I'm actually having troubles with SDL3 right now because it doesn't give me absolute display information; the DisplayBounds I get from it are in logical form, and it's a pain to convert them to absolute. So wl_output positioning is broken, and clients will have to rely on xdg-output if they're running under my compositor.
04:36 DemiMarie: orowith2os[m]: What about winit in Rust? That’s assuming you prefer Rust to C++, which is my understanding from other discussions.
04:41 orowith2os[m]: DemiMarie: I still need to write the actual wayland compositor, and wayland-rs isn't the *best*? Maybe once I have a working demo with C++, I'll move over to Rust.
04:41 DemiMarie: orowith2os[m]: Is this a rootful or rootless compositor?
04:41 orowith2os[m]: rootless.
04:42 orowith2os[m]: it'll be running on X11 and, if possible, non-Linux platforms as well.
05:10 whot: orowith2os[m]: I ... don't know? I generally really don't want to touch the API unless absolutely necessary. in the past having const has bitten me too but that depends on the exact use-case
05:11 whot: set_points looks like it can be constified with no impact though
05:48 zzxyb[m]: Are there any breaking commits from wayland 0.17.0 to 0.21.0?
07:02 DemiMarie: orowith2os[m]: you will absolutely need to have _NET_WM_SYNC_REQUEST in the X11 window manager
07:02 DemiMarie: I tried working without that and failed after maybe a year of work.
07:03 DemiMarie: Even with that you might run into problems because Wayland and X11 disagree on whose state for window szes is authoritative.
08:24 pq: orowith2os[m], signal handling? Async-signal safe context required?
08:32 pq: orowith2os[m], 'man 7 signal-safety' is a good reading if you weren't aware yet, and noting that e.g. free() is not safe.
12:33 orowith2os[m]: pq: haven't gotten that far yet
12:34 orowith2os[m]: I very well could rewrite it in Rust if all that is a problem though.
12:39 pq: orowith2os[m], it depends on how you handle signals. signalfd is fine, but in a traditional signal handler you'd best just set a global flag variable and do nothing else.
12:40 orowith2os[m]: fwiw my current state of it is up at https://gitlab.com/orowith2os/rxwl
12:40 orowith2os[m]: feel free to rip it apart however you like
12:40 mclasen: This may be of interest here: https://gitlab.gnome.org/GNOME/gtk/-/commit/250771886c90478731dde3f95091ae919e9a81a7
12:41 mclasen: gtk now has an easy way to opt out of certain protocols
12:41 mclasen: useful for debugging, if nothing else
12:42 orowith2os[m]: could libwayland hide certain protocols too?
12:43 pq: libwayland-server already can, libwayland-client not without ugly hacky things
13:28 paulk: hi, back to drm backend multi-device support, one thing seems to be that the renderer and weston_compositor are created per-backend
13:28 paulk: when the renderer needs a gbm handle created from the drm device
13:28 paulk: so in turn dependent on the drm_device, not the backend
13:32 paulk: does the current weston design support having a different renderer for each backend running in parallel?
13:32 paulk: or is the renderer expected to be the same for all backends/outputs?
13:41 pq: paulk, I believe the renderer must be the same for all backends. Renderer features determine features exposed to clients, and they cannot sometimes fail.
13:42 pq: the weston_compositor instance is shared across all backends
13:43 orowith2os[m]: You could expose the minimum supported features across all backends, would just need rework within Weston, no?
13:43 paulk: mhh
13:43 pq: orowith2os[m], yeah, "just".
13:44 paulk: so the problem here is that e.g. gbm requires a drm device fd
13:44 pq: I don't see what benefit there would be.
13:44 swick[m]: emersion: would appreciate a review on https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/465
13:45 paulk: so if there's two outputs with two different drm devices we really need a different gbm instance for each
13:45 paulk: and in turn a dedicated renderer
13:46 paulk: or maybe gbm can be decorelated from renderer
13:46 emersion: drm devices can be hot-plugged, and you can know in advance what features they will support
13:46 orowith2os[m]: otherwise you'll be rendering on one device, and copying (or using a dmabuf) everything over to the other output, right?
13:46 pq: paulk, or, use the other DRM device GBM instance only for allocation and import the buffer into the renderer's instance, or do a copy.
13:46 emersion: you can't know*
13:46 emersion: swick[m]: yup, on my todo list
13:46 swick[m]: great, thanks!
13:47 paulk: pq: yeah I guess gbm is only really ever useful for allocating scanout buffers
13:47 orowith2os[m]: emersion: while you're here, did you have any thoughts on landing https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/389 ?
13:47 emersion: i'm still unsure about this
13:47 pq: paulk, the problem with having two renderers on different devices is that yoou'd have to duplicate textures between them, and they might support different formats and features.
13:48 paulk: yes I think duplicating renderer would be a pretty bad path to follow
13:49 paulk: and in practice the renderer per-se is typically a gpu that's not tied to a particular display engine
13:49 paulk: so it makes sense to assume a single renderer for all backends/outputs
13:49 pq: paulk, I thought Weston already supports additional KMS devices, does it not?
13:49 orowith2os[m]: emersion: I'd like to use it in my own code to build some warnings in that the available libwayland provides us newer interfaces than what we provide, instead of having to manually go and check for protocol updates otherwise. I know the wl_interface struct has a version field, but that's only for runtime.
13:49 paulk: pq: yes it does but there is still a "main drm device"
13:50 pq: paulk, right, the rendered has to have a device.
13:50 pq: *renderer
13:51 paulk: pq: I don't think the drm device is really used in the gl render but it of course needs the gbm pointer derived from it
13:52 paulk: it's not very clear to me yet how additional drm devices manage allocation
13:53 paulk: I guess they would allocate on that main drm device and then import buffers
13:53 paulk: but I haven't found the code that does that yet
13:53 pq: Migration to a different rendering device is not very feasible, all clients need to migrate as well or re-establish the Wayland connection to discover the feature set.
13:53 paulk: right
13:54 paulk: pq: btw my final use case here is to support a client wanting output clone on 2 different drm devices, using the weston-imx code that has vivante g2d supporty
13:54 pq: Scanout memory is tricky enough that it should be allocated on the KMS device where it will be used. That is much more likely to work than the opposite.
13:55 paulk: yeah especially due to lack of iommu (contig alloc) + sometimes memory area constraints
13:56 daniels: paulk: there's actually an MR upstream for g2d-renderer support, which is probably a more fruitful path than relying on weston-imx
13:56 paulk: daniels: oh nice, I didn't see it, thanks! It's still using the proprietary verisilicon g2d library?
13:56 daniels: yeah
13:57 wlb: weston Issue #925 closed \o/ (Forever painted client buffer on a transparent background https://gitlab.freedesktop.org/wayland/weston/-/issues/925)
13:58 paulk: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1622
13:58 paulk: that one?
13:59 paulk: seems to be etnaviv actually :)
13:59 wlb: weston Merge request !1711 opened by Loïc Molinari (molinari) gl-renderer: Init output borders with transparent pixels https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1711 [GL renderer]
14:02 paulk: glad to see there's still interest in mainline 2d acceleration though, maybe eventually we'll talk about having a unified library (mesa-ish) and API and that could be used by weston
14:02 paulk: and have support for all those 2d accelerators there, with drm render drivers
14:03 paulk: (something I would be really glad to work on if given the opportunity :)
14:32 wlb: weston Issue #528 closed \o/ (Support seperated video overlays with weston https://gitlab.freedesktop.org/wayland/weston/-/issues/528)
14:37 wlb: weston Issue #9 closed \o/ (Support punch-through underlays in DRM backend https://gitlab.freedesktop.org/wayland/weston/-/issues/9)