00:43 DemiMarie: kennylevinsen: Qubes has its own GUI protocol, but I’m not sure how to extend it to support dmabuf for once Qubes gets hardware acceleration.
00:44 DemiMarie: @orowith2os:fedora.im: A full-screen compositor like Cage should do the job.
01:23 wlb: wayland.freedesktop.org Merge request !63 opened by Peter Hutterer (whot) ci: call meson setup for the libinput build https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/63
02:17 orowith2os[m]: Demi: my goal was to have Xwayland manage Wayland windows too, so Cage would be *half* of the job, at most
02:17 orowith2os[m]: but I should definitely look at it for a bare minimum implementation
02:18 orowith2os[m]: and then fork it, or use something like Anvil, from Smithay
03:30 i509vcb: orowith2os: a sort of waylandx so old wms can still be used?
03:51 orowith2os[m]: i509vcb: bingo
03:54 orowith2os[m]: another option is actually implementing a polar opposite of Xwayland, but you still have bare metal Xorg, which I Don't Like™
04:20 i509vcb: I could see it working assuming you can fight the X server and WMs
04:21 i509vcb: Personally I've been going towards making a window management protocol that has similar capabilities to X WMs but less messy
04:21 orowith2os[m]: would definitely be interested in it, and see if it would be enough to get most of an XWM going on top of it (with Xwayland in the middle)
04:23 i509vcb: I'm curious if you could literally just use xwayland but make a compositor client that injects fake Wayland windows
04:23 i509vcb: And then just forward xwayland to the server
04:24 orowith2os[m]: may need a tiny bit more explanation there
04:27 i509vcb: Pretty much tell xwayland about fake X11 windows that are really Wayland ones. And then let the WM controlling xwayland do window management
04:28 i509vcb: Although that leaves the issue of compositing the Wayland surface content xwayland side
04:28 i509vcb: And subsurfaces are a fun mess you'd have to deal with
04:28 orowith2os[m]: wouldn't you also still need to have some sort of absolute positioning protocol for Xwayland, and a way to inject events and read everything about them from Xwayland?
04:29 i509vcb: This is definitely not my expertise, so I can only really guess
04:30 orowith2os[m]: ah
04:30 orowith2os[m]: my first thought would be that, as Wayland doesn't allow absolute positioning, you still can't have Xwayland manage windows - all it knows is that they exist
04:31 i509vcb: Well that's why I proposed having xwayland effectively only see X11 windows. From the Wayland side, pretend the Wayland windows don't logically exist
04:32 orowith2os[m]: you still get into the ickiness, pretty sure
04:32 orowith2os[m]: those fake X11 windows are still native Wayland windows
04:32 i509vcb: You'd just have your compositor render what xwayland does and lie to x11 about a few windows
04:32 i509vcb: Yeah that's the sticky bit
04:33 orowith2os[m]: *at the very least* you need to tell Xwayland that "key, you can access these special protocols" and use them to implement most of the X-isms inside of it
04:33 orowith2os[m]: s/key/hey
04:34 orowith2os[m]: a benefit would also be that you could reuse those protocols to implement that X WM behavior in your use case
04:41 orowith2os[m]: I should take a full and close look at everything necessary, and design (theoretical) protocols around them
06:36 kennylevinsen: DemiMarie: I meant you can have whatever custom Wayland shell protocol to allow whatever you want
10:34 pq: orowith2os[m], cage - Xwayland rootful - { X11 apps, WaylandX - Wayland apps }. You only need to invent WaylandX, and that will be "easy" because Wayland apps cannot position themselves, so the X11 WM running under Xwayland rootful can manage them like any X11 windows.
10:35 pq: no need for any new or privileged Wayland protocol
10:35 kennylevinsen: heh, so: wayland app -> wayland-to-x -> Xwayland + X11 WM -> Wayland server
10:35 pq: yup
10:35 pq: that's what they're asking, right? :-)
10:36 kennylevinsen: It would solve it
10:37 pq: I don't see any benefit combining WaylandX with the on-hardware Wayland compositor, their operation modes and environments would be completely different.
10:38 pq: Also a Wayland compositor's XWM would not be used at all for anything.
10:39 kennylevinsen: I believe the request was to have a "normal" Wayland server, but whose WM decisions only were made by an X11 WM through some unholy magic
10:40 kennylevinsen: but... yeah
10:42 kennylevinsen: it also seems like an extreme niche: you basically want X (with WaylandX compat layer), but Xorg itself can't be used because hw compat :S
10:45 pq: maybe one could replace /usr/bin/Xorg with something that launches cage + Xwayland rootful...
10:47 pq: one would lose direct display control via X11, but that's all coming to my mind. Oh, multiple monitors might break?
10:48 pq: maybe not
10:48 emersion: could be fixed with multi-window Xwayland rootful
10:49 pq: or the Xwayland window just spanning all monitors
10:51 emersion: then there are "holes", fullscreen doesn't work, etc
10:52 pq: but it would match how Xorg works, right?
10:52 pq: RandR monitor / Xinerama would still communicate the monitor areas
10:53 emersion: RandR would just send one big screen
10:53 pq: that needs modifications then
10:54 pq: native Xorg multi-head is a single huge SCREEN, with monitor rectangles on it
11:07 jadahl: I imagine a rootful multi head Xwayland would first need some "multi monitor fullscreen" request, then use the configure event + scaling parameters to define its internal framebuffer size, then use xdg_output regions for randr plumbing
11:07 emersion: a multi monitor fullscreen request is unnecessary if you configure the outer compositor correctly
11:08 emersion: e.g. cage
11:08 emersion: i'd personally prefer something like multiuple xdg_toplevels plus viewporter or something, would fit better the design of Wayland
11:09 kennylevinsen: *cough cough* fullscreen_shell *cough*
11:10 emersion: ahahah
11:13 jadahl: I mean if one should be able to have a fullscreen Xwayland in your regular session just for a moment
11:13 emersion: (sway supports this FWIW)
11:13 emersion: (multi-monitor fullscreen)
11:16 pounce: just curious, what's the state of non-rectangular screen geometry in Wayland currently
11:16 pounce: asking bc MacBook with a notch
11:17 pounce: currently asahi exposes the screen under the notch in the kernel and doesn't bother with it at all, but im wondering what work needs to be done (not including client software like bars) to make it work on the wayland side
11:19 emersion: pounce: there's an issue about this in wayland-protocols
11:23 pq: Unless you want applications to draw around notches and holes, there is no need for Wayland protocol and it's just a matter of the compositor finding out the holes and managing windows around them.
11:24 kennylevinsen: you probably want that for fullscreen
11:24 kennylevinsen: for windowed it's probably more reasonable to just have the compositor avoid the notch
11:25 kennylevinsen: *fast forward to windows dynamically shuffling their content to evade the notch as they are moved*
11:25 pq: it depends, are apps even willing to handle the notch - if not, fullscreen needs to be a little less full
11:26 pounce: emersion: would appreciate a link, but i can find it myself later
11:26 kennylevinsen: makes sense to have it be optional
11:26 emersion: i think some apps will want to handle notches
11:26 emersion: android does this
11:26 pq: I'm sure some apps want to handle notches, and many more that don't.
11:26 emersion: sure, the compositopr can handle this
11:27 emersion: compositor*
11:28 pq: but if the DE puts a DE element around the notch, it know to do that correctly, and window management is all that's needed. Maybe paint the extra area black when an app is "almost" fullscreen.
11:57 pounce: also you want the same bar on both sides of the notch
11:57 pounce: so this is something that should be communicated to the bar (its exclusion zones on the screen)
11:57 pounce: but also most applications in macOS in fullscreen just avoid the notch
13:28 DodoGTA: Is there a way to create a software cursor on X11/Wayland?
13:29 pq: What do you mean?
13:29 pq: one that is guaranteed to not get into a KMS cursor plane?
13:30 DodoGTA: pq: One that doesn't appear in the x_cursor member of xwl_seat
13:35 DodoGTA: Or creating a cursor with SetCursor(NULL) for a Win32 equivalent
13:36 kennylevinsen: that's internal state to Xwayland
13:37 kennylevinsen: but a Wayland client is free to send set_cursor with a NULL surface to hide the cursor
13:41 DodoGTA: kennylevinsen: How could I create a cursor without calling that set_cursor function after doing that?
13:43 kennylevinsen: this feels like an xy-problem scenario
13:45 kennylevinsen: You either have Wayland show a cursor surface (GPU or CPU rendered, composited or HW plane offloaded), or not.
13:46 kennylevinsen: Maybe a game would pick "not" if lets its game engine draw a fancy cursor
13:47 DodoGTA: kennylevinsen: That's what I meant by a software cursor
13:48 kennylevinsen: there's 3 different ways to interpret "software cursor" :)
13:49 kennylevinsen: then just set_cursor with a NULL surface to remove the cursor
13:49 kennylevinsen: remove/hide/whatever
13:50 kennylevinsen: there is no cursor to create after that, your application will have to figure out how to show something at coordinates of pointer events
13:50 DodoGTA: kennylevinsen: I wonder how cursor locking would work in that case (a game drawing its own cursor and set_cursor being NULL)
13:52 kennylevinsen: (note that the game could also attach an arbitrarily fancy cursor surface to the pointer instead of compositing it to its own toplevel)
13:55 kennylevinsen: DodoGTA: pointer constraints (how the pointer is allowed to move) and whether you have a cursor surface (how the pointer looks) are entirely orthogonal
16:04 i509vcb: pounce: the notch thing is definitely uncharted territory on Linux, I'll probably end up trying to work around that at some point assuming I stop procrastinating on my compositor
16:05 i509vcb: Although no promises of a timeframe for protocol so clients can learn about cutouts