12:04 DemiMarie: Is libweston suitable for rootless compositors
12:04 DemiMarie: Conan Kudo suggested this, but I want to know if anyone has tried this before.
12:04 DemiMarie: Conan Kudo: I’m not opposed to using libweston, but I would first need to know that it could do everything I needed and that I would not get blocked.
12:05 DemiMarie: With wlroots, if there is a feature missing I can just implement it myself.
12:05 DemiMarie: because wlroots isn’t going to get in the way
12:05 linkmauve: DemiMarie, Weston is the compositor used by Windows, so obviously.
12:05 linkmauve: DemiMarie, why couldn’t you implement it in Weston as well?
12:06 DemiMarie: linkmauve: wlroots is much less opinionated than libweston, and I wanted to know if that mattered in my (rather unconventional) use-case.
12:06 DemiMarie: Other compositor authors (such as the author of Wayfire) have found that libweston is too opinionated for what they are doing and caused problems
12:07 emersion: linkmauve: it's a fork
12:07 DemiMarie: emersion: upstreamable?
12:07 emersion: no
12:07 DemiMarie: why?
12:07 DemiMarie: would the upstream libweston be suitable for my needs?
12:08 emersion: i don't think so
12:08 emersion: weston has not been designed for these use-cases
12:08 DemiMarie: what changes did Microsoft have to make?
12:10 DemiMarie: Would Microsoft’s fork be suitable, or would it cause too many problems when I needed to implement a protocol and libweston didn’t support it?
12:10 Eighth_Doctor: Microsoft's weston fork mostly adds a new shell module
12:10 Eighth_Doctor: https://github.com/microsoft/weston-mirror/tree/working/rdprail-shell
12:11 Eighth_Doctor: but it is also very old
12:13 Eighth_Doctor: rdprail is a module in weston to do rootless window rendering through the rdp backend
12:13 Eighth_Doctor: this is why I know what you want is possible, because Microsoft did it
12:16 Eighth_Doctor: this was the piece to Weston core that was to be added for RAIL: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/824
12:17 Eighth_Doctor: based on the feedback in that MR, daniels doesn't seem to be opposed to it, but the strategy of how it was plumbed through for Microsoft isn't the one he wanted
12:18 Eighth_Doctor: but a lot has changed in two years since that MR
12:21 Eighth_Doctor: some of that MR might still be needed, but the stuff it touches has changed a fair bit
12:38 Eighth_Doctor: there's also a simple Wayland based desktop built on Weston too, called Wayward: https://github.com/varmd/wayward
12:46 DemiMarie: daniels: which do you think I should use?
13:43 Company: YaLTeR[m]: why did you not run into https://gitlab.gnome.org/GNOME/gtk/-/issues/7025 earlier?
13:44 Company: like, this should have triggered since GTK switched to Vulkan in May
13:44 Company: or did niri recently change in some way that triggers it?
13:52 YaLTeR[m]: Two reasons: doesn't repro on my desktop for some reason + I'm running F40 so my frequent nautilus dnd is still ngl
13:53 YaLTeR[m]: Though, it's still kinda weird that I only ran into it now
14:29 colinmarc: is there anything wrong with just discarding any committed content for a toplevel surface while I'm waiting on an ack_configure?
14:30 colinmarc: I saw a situation where a client was acking a previous configure (I sent two in quick succession) but then hanging without acking the second configure. calling the frame callback on the surface fixed it
14:33 kennylevinsen: colinmarc: it feels wrong to stall frame callbacks, but you’re free to ignore the content until ack
14:33 colinmarc: if that's standard behavior, maybe it should be documented? something like "If a surface is committed for which there is a pending, un-acked configure, the compositor should immediately discard the content update and trigger any pending frame callbacks"
14:34 kennylevinsen: it shouldn’t discard content updates, it *may* discard content updates
14:34 kennylevinsen: and frame callbacks may always be throttled, but if not throttled they should be delivered
14:35 colinmarc: throttled implies not stalled forever, I guess? the surface was configured as suspended at that point
14:35 kennylevinsen: Question is: is it a bug to wait for a frame callbacks to ack? The client should respond quickly, but one frame is also quick. It can make sense to throttle to frame callbacks, but configures might be seen as semi-urgent
14:36 colinmarc: just to be clear, the sequence was... (full message at <https://matrix.org/oftc/media/v1/media/download/ATOxHQR_OGNcoJlQmd-DMAQjngNx89DkvZ_8_qQKU_VAXf6dBlS3ejw-lKjPcAm_JHnoftARHy9Orr_nZ6agkFtCeSFrqDNwAG1hdHJpeC5vcmcvV25aaWVCbmJrWlhIR3RmUkFRemZXdER1>)
14:36 kennylevinsen: Yeah, if it’s suspended and hidden it’s okay to wait with frame callback, but then acking isn’t really urgent either. If an ack is urgent, it’s presumably because you want to present the surface, in which case it’s no longer suspended
14:36 colinmarc: the configure 2 removed the suspended state
14:37 colinmarc: and I did want to present at that point
14:38 kennylevinsen: Then you should be sending frame events after the second configure (what better time to start rendering than just before the window becomes visible?), but it does just sound like a client bug not expecting this ordering… what client?
14:38 colinmarc: I think it's SCTK-via-winit
14:39 colinmarc: https://github.com/Arvamer/gilrs/blob/master/gilrs/examples/gui.rs to be exact
14:41 colinmarc: > Then you should be sending frame events after the second configure (what better time to start rendering than just before the window becomes visible?)
14:41 colinmarc: That makes sense. I usually only send frame callbacks if I actually presented (or if I explicitly discard a content update).
14:41 colinmarc: * > Then you should be sending frame events after the second configure (what better time to start rendering than just before the window becomes visible?)
14:41 colinmarc: That makes sense. I usually only send frame callbacks if I actually presented (or if I explicitly discard a content update).
14:44 colinmarc: thanks :)
14:57 ifreund:
17:51 DemiMarie: Conan Kudo: Looks like `assign_planes` (as preferred by daniels) requires doing one's own rendering, which Microsoft presumably didn't want to do.
17:51 DemiMarie: emersion: why do you say that Weston is not suitable for this use-case?
19:34 throwthecheese: I'm trying to rotate my touchscreen canvas using libinput but it won't rotate for some reason despite libinput_device_config_calibration_get_matrix returning 1, implying the matrix was modified.
19:34 throwthecheese: Anybody knows whyM
19:38 kennylevinsen: throwthecheese: where are you trying to modify it from? Libinput state is local to the application using it, you cannot use libinput in a random application to affect the Wayland server’s matrix for example
19:38 kennylevinsen: if you want to affect the server’s matrix, configure the server according to its manual, or set the default matrix using the libinput udev rule
19:42 throwthecheese: I'm trying to implement automatic screen rotation and I'd rather not use xinput
19:44 throwthecheese: It's rather inconsistent at recognizing my stylus (sometimes it recognizes it as a single device and as two devices at other times)
19:54 kennylevinsen: I'm not sure why xinput would be the alternative
19:56 throwthecheese: I could call xinput set-prop to rotate the canvas whenever the screen gets rotated
19:57 kennylevinsen: that wouldn't work in general
19:57 throwthecheese: But it's unreliable
19:58 throwthecheese: That's why I'm trying to bypass xinput or rather, the command line
19:58 kennylevinsen: it wouldn't do anything in most cases, so yeah
20:00 throwthecheese: I should mention that I'm trying to achieve automatic screen rotation under X
20:00 kennylevinsen: that *would* be good to mention in #wayland :)
20:04 kennylevinsen: I can't really help much with X11 - in wayland servers such as sway, no matrix shenanigans are required for touch to be correctly aligned after random output rotations, it just works
20:05 kennylevinsen: but libinput isn't the right path - it's a library to help an application interpret input device events, not a way to set global system state
20:09 throwthecheese: I'm considering moving back to X as there is an unresolved issue in kwin that causes stylus input to streak in applications running on XWayland
20:09 throwthecheese: GNOME is out of question for me as it doesn't have a global menu addon that doesn't hang LibreOffice up
20:10 kennylevinsen: that's unfortunate - is it filed and triaged?
20:11 throwthecheese: It's filed but it has been collecting dust for nine months
20:12 kennylevinsen: I don't work on kwin or Xwayland, so I can't really comment on it - but it would be good to know if it's a kwin bug or an xwayland bug
20:13 FreeFull: And Krita still forces itself to run under X11 only
20:14 throwthecheese: mutter doesn't appear to screw up my strokes on XWayland,,, problem is that you can't really swap out the compositor in KDE
20:14 FreeFull: So I imagine it's easy to run into that bug
20:16 throwthecheese: It's with note-taking software, especially AppImages that you can really notice the stylus input being screwy
20:17 kennylevinsen: hmm, none of it having native wayland support? :/
20:18 throwthecheese: The MrWriter AppImage enforces XWayland... not sure about Xournal++ but it won't play nice with my global menu on Wayland
20:19 throwthecheese: That's typical of GTK3+ software, though
20:20 kennylevinsen: being qt5, maybe it could just be built with wayland support
20:21 throwthecheese: Wayland support is not implemented in Krita as far as I know
20:21 throwthecheese: Was told recently that there is no support for it currently
20:21 kennylevinsen: talking about mrwriter
20:23 FreeFull: Blender supports tablet input and is wayland-native.. But it's not really a note-taking app
20:25 throwthecheese: I had to compile it from source to get it natively running but it then crashed frequently due to my hand being on the screen while writing... guess who has a second, patched qt5wayland library
20:30 throwthecheese: Well, I gotta go
20:30 throwthecheese: Bye