00:19 emersion: Consolatis: i haven't heard anything against it
00:20 emersion: compared to object IDs, global names are type-unsafe
00:20 emersion: but that's about it, apart from that, both are uint32_ts
00:52 Consolatis: the only potential issue I can come up with is that it might make it harder for e.g. GTK applications to use the GDK abstraction of the outputs, I don't know if they expose the global so that the application could match it in a output_enter/leave handler
00:53 Consolatis: on the other side I also don't know if they expose the object id for that matching
01:53 Consolatis: hm.. there seems to be gdk_wayland_monitor_get_wl_output(). Now the question becomes if there is anything in libwayland that returns a global 'name' based on a wl_proxy, similar to what wl_proxy_get_id() is doing for the object id. I couldn't find anything but I am also not that familiar with libwayland
02:01 Consolatis: it seems like the only place the global could be stored is in wl_registry_bind() though. And that one just serializes and writes it out to the compositor
02:03 soreau: Consolatis: I'm not sure if it's any consolation, but you can struct wl_display *display = gdk_wayland_display_get_wl_display(gdk_display_get_default()); and from there wl_display_get_registry(display); to do your own roundtrip for global stuff
02:05 Consolatis: right, but you couldn't match a global you get via output_enter/leave argument with an existing gdk_monitor (and I assume its the same for other GUI frameworks)
02:07 Consolatis: obviously creating your own objects is fine and allows the app developer to attach the global via wl_proxy_set_user_data() or whatever floats their boat
02:08 soreau: Consolatis: https://github.com/WayfireWM/wf-shell/blob/master/src/util/wf-shell-app.cpp#L249
02:13 Consolatis: this is about getting e.g. '15' on a output_enter event and then finding a gdk_monitor based on that global name 15. I don't think this is currently possible. You could bind your own wl_output of global id 15 but that looks like its all that can be done currently.
02:15 soreau: ah, hm.. yea that's kinda going backward ;)
02:17 Consolatis: so this might speak against using global ids as arguments.. at least as long as libwayland doesn't provide something to fetch the global from a wl_proxy (if created by a wl_registry_bind call)
02:22 Consolatis: although from the compositor side using globals for output enter/leave events is theoretically very much superior compared to the current object based argument. If it doesn't work in practice that might be worse. Guess that leaves using the output name as argument
02:22 soreau: Consolatis: what about https://docs.gtk.org/gdk4/signal.Surface.enter-monitor.html ? Can't you hook up this event instead of trying to match a name id global?
02:23 soreau: not sure about other tk's but I guess you're talking about what you describe being possible for any client
02:25 Consolatis: wl_surface also uses the object ids from what I remember (same as wlr-foreign-toplevel). They all have the same issue on the compositor side: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40#note_2521472
02:28 soreau: seems like the problem there is 'the compositor can either lie and send a done event even though it didn't actually send the corresponding output resource' because if the compositor is lying, you have bigger issues :P
02:30 soreau: I view the compositors as trusted robust processes, and the clients can be silly all they want. Kinda like the kernel handles its 'children' processes
02:31 Consolatis: agree, but that is just impossible in this case as the compositor can only send wl_output object ids that the client has already bound
02:32 Consolatis: that gets amplified with multiple independent parts (e.g. GTK + app logic) sharing a single wayland connection
03:31 karl1fox: hey guys, is someone familiar with the rdp backend code around that I could ask a question of?
03:43 soreau: karl1fox: you might as well just ask your question and link any issues you might have filed
03:56 karl1fox: I was thinking Soreau, I think these changes are actually only in the MS mirror of Weston, but I'll ask all the same. In the Weston log I see my 3 monitors detected by the RDP plugin, but it seems like the compositor is only presented with one and I'm trying to grasp how that piece works :)
04:13 soreau: karl1fox: I have no idea about the MS world of weston but have you tried running it with something like `-B drm,rdp`?
04:14 soreau: hm, looks like only vnc and pipewire backends can be used as secodnary
04:15 soreau: karl1fox: what version of weston?
04:15 karl1fox: let me verify one sec Soreau
04:16 karl1fox: Build: 9.0.0-210-gf227edd6+
04:17 soreau: that seems pretty old compared to i.e. https://www.collabora.com/news-and-blog/news-and-events/weston-13-release-backends-consolidation.html
04:17 soreau: karl1fox: what does `weston --version` say?
04:20 karl1fox: weston 9.0.0
04:21 soreau: yea, that's pretty old
04:22 karl1fox: yeah the problem is that to get the graphics acceleration that wslg offers, you have to use the rdprail-shell
04:23 karl1fox: I think if I was a bit smarter and more experienced I could switch to the upstream Weston mirror and figure it out, but alas I must eat the MS table crumbs :)
04:24 karl1fox: Soreau, is a wayland display the sum of all display outputs?
04:25 soreau: karl1fox: the wayland display I know is an object that represents the underlying socket connection
04:26 soreau: IIRC in X, I think all outputs collectively were called a 'screen'
04:27 karl1fox: What would happen if I forced Xwayland to run in rootful mode here? /usr/bin/Xwayland :0 -rootless -core -listen 37 -wm 38 -terminate -nolisten local -ac
04:29 soreau: which weston shell are you using btw?
04:30 karl1fox: the rdprail-shell
04:31 karl1fox: This is what their wslgd plugin runs, /usr/bin/weston --backend=rdp-backend.so --modules=wslgd-notify.so --xwayland --socket=wayland-0 --shell=rdprail-shell
04:32 soreau: and is your rdp client configured to support multiple outputs?
04:32 soreau: if so, it might be time to consider upgrading weston (to 13.0 or better)
04:32 soreau: if that's even an option
04:33 karl1fox: I'm certainly willing to try :)
04:33 karl1fox: Does the newer version have multimon support for RDP?
04:37 soreau: It seems like you want multi-backend support but details are foggy on the web
04:37 soreau: though I do see this: https://github.com/microsoft/wslg/wiki/WSLg-Configuration-Options-for-Debugging
04:38 soreau: (WSL2_WESTON_SHELL_OVERRIDE seems like it might be interesting?)
04:39 soreau: according to google's AI results: "Multi-monitor support: Weston 13.0 and later versions include support for multiple backends, including the RDP backend. This allows you to create multiple outputs corresponding to the monitors connected to your Windows machine."
04:40 karl1fox: so id basically do drm, rdp to setup the 3 monitors and then rdp to allow remote to it? Is that the gist of it?
04:41 soreau: karl1fox: what if you try `/usr/bin/weston --backend=rdp-backend.so --modules=wslgd-notify.so --xwayland --socket=wayland-0 --shell=desktop-shell`
04:41 soreau: because apparently, "The RAIL-shell is a Weston shell specifically designed for remoting individual windows from Linux to Windows using the Remote Desktop Protocol (RDP)."
04:41 karl1fox: You get a wayland desktop shell but it disables multimonitor support
04:42 soreau: but if I were you, I'd try upgrading first and if you can get weston 13.0, maybe there's a chance there's a path to make it work
04:43 karl1fox: cool, ill work on that, and circle back with you
04:43 karl1fox: I need to figure out a way to upgrade the Meson version in the wsl system distro
04:44 karl1fox: its not in their official repo which is making it tough to do in the Dockerfile they give you
04:45 soreau: if you have python3 pip, it should be as easy as 'pip3 install .` from the meson source directory
04:46 soreau: (but I'm guessing with windows, it's not that straightforward)
04:49 karl1fox: oh I have a full arch install... the problem is that the system distro where weston lives, is read only after you build it in docker and you cant run it in docker because it has no kernel of its own
04:50 karl1fox: I think that's what I'll work on, finding a way to make the distro rw
04:50 karl1fox: because then customization and testing is much easier
06:39 soreau: DemiMarie: I was thinking, if you want a secure system and to guard against potentially malicious clients, you could do what some platforms do and ship the display server with clients that have been vetted and ignoring any non-trusted client
06:40 soreau: i.e. package the compositor and select clients that you know are trusted because you ship them
06:43 soreau: also you could ignore clients that aren't launched by the compositor (or some shell) itself
06:50 emersion: Consolatis: this is a GTK issue not a libwayland one
06:50 emersion: libwayland cannot provide functions to return an output based on global name, because it doesn't track that
06:51 emersion: Consolatis: anyways, protocol design should not be guided by some missing/non-existing API in a single toolkit (it's not a show-stopper here)
06:52 Consolatis: right, but libwayland could return the global for a wl_proxy if it was created by wl_registry_bind() but as you said it currently doesn't seem to track that
06:53 Consolatis: in theory I agree to the protocol design part but in practice it will make the protocol less usable with the current environment that app devs need to support
06:54 Consolatis: and such it is an argument against using the global in output_enter/leave for me
06:57 Consolatis: which IMHO leaves two options for the ext-workspace MR (and ext-foreign-toplevel-info), using the output name and relying on its unique among globals property or keep using object ids with their known flaws
07:28 emersion: Consolatis: libwayland cannot, it's generated code (and out of scope)
07:28 emersion: Consolatis: i disagree
07:28 emersion: it's not hard to keep track of outputs yourself if you are using GTK
07:29 emersion: also another protocol is already using the global name
07:45 dviola: soreau: just bisected linux.git (stable)
07:45 dviola: This means the bug has been fixed between ffc253263a1375a65fa6c9f62a893e9767fbebfa and [9b5aad3a7498c261116a0251fe57f14ba9c4c6cf].
07:46 soreau: dviola: the kernel?
07:46 dviola: yes
07:46 dviola: https://0x0.st/Xkqn.txt
07:46 soreau: so it's already fixed in newer kernels or it broke somewhere along the way?
07:47 dviola: I'm a bit confused about it to be honest
07:47 dviola: latest master is bad, 6.6.60 is good, 6.6 is bad
07:48 soreau: did they make it all the way to .60? :P
07:49 dviola: that bisect log makes no sense, sigh
07:50 soreau: https://lwn.net/Articles/997527/ -> "I'm announcing the release of the 6.6.60 kernel. All users of the 6.6 kernel series must upgrade." <- sounds almost scary
07:51 dviola: ha :P
07:55 dviola: trying 6.7
07:57 soreau: dviola: if latest master and 6.6 is bad, I would think 6.7 would be bad too..
07:57 soreau: are you able to bisect between 6.6 and 6.6.60?
07:57 dviola: yes
07:58 dviola: let me try that
08:05 dviola: "Some good revs are not ancestors of the bad rev. git bisect cannot work properly in this case. Maybe you mistook good and bad revs?"
08:06 llyyr: reverse the good and bad revs
08:06 dviola: ok, let me check how to do that
08:07 llyyr: if 6.6.0s is bad and 6.6.60 is good then mark 6.6.60 bad and 6.6.0 good
08:07 llyyr: if you find the bug then do git bisect good, since you're looking for a commit that fixes something, not a commit that introduces a bug
08:08 llyyr: I don't know why it works this way
08:08 dviola: makes sense, thanks
08:08 soreau: what I usually do instead of git bisect start foo bar, is git bisect start, then git bisect good some-hash and git bisect bad some-hash
08:12 dviola: here we go... ~12 steps to bisect
08:32 MrCooper: dviola: sounds like it's probably not a kernel regression / not 100% reproducible
08:33 MrCooper: if it's the latter, you may need to wait longer before declaring a kernel commit good
08:38 soreau: MrCooper: I thought the problem was pretty cut and dry - hw cursor plane upside down
08:39 MrCooper: the inconsistent bisect results disagree
08:39 dviola: MrCooper: yeah, it was working fine with recent kernels, e.g. 6.11.x
08:39 dviola: then it broke
08:39 dviola: I'll finish the bisect anyway
08:47 dviola: this happens inside the QEMU VM only btw
08:49 pq: kennylevinsen, while ExecStartPost=+chvt 7 seems a little hacky to me, in lack of a login manager I think it's still slightly better than auto-activating all new sessions. My 2c FWIW.
08:58 pq: emersion, Consolatis, re: wl_output global names; did we have something to forbid name re-use after remove_global?
08:59 emersion: i don't think it matters? client gets global_remove events
08:59 emersion: so clients always have synced up-to-date state about wl_output
09:00 emersion: if anything wl_output.name is more racy
09:00 pq: assuming clients process global_remove and events referring to global names in order. That's not guaranteed, the client can funnel those via different queues.
09:01 pq: hmm, this is essentially the same problem as the plain global_remove race against bind.
09:01 emersion: you can always assign a wl_registry to the queue you're interested in
09:01 emersion: but yeah, it's not a new problem and we've put a solution in place already
09:01 pq: indeed
10:01 kennylevinsen: pq: yeah, what I had in mind was a `libseat_get_session` so that one could explicitly do a session switch to self if they so desired
10:01 pq: cool
10:02 pq: Does logind d-bus API generally allow any session owner to activate their session at will?
10:04 kennylevinsen: for logind, you need to pass a polkit `org.freedesktop.login1.chvt` permission check, but that appears to be it
10:07 pq: alright
10:07 kennylevinsen: The pre-installed rule for that allows both active and inactive (but logged in) users
10:13 dviola: MrCooper: I *think* the commit will make more sense this time
10:13 dviola: s/commit/bisect/
10:16 dviola: roughtly 1 step
10:18 dviola: got a build error just in the last step: http://0x0.st/Xkbd.txt
10:18 dviola: let me skip this one
10:24 dviola: MrCooper, soreau, llyyr: 87b3b45ce7b4dd745506f9437b968c5e35b87dda is the first bad commit https://0x0.st/Xkb5.txt
10:25 llyyr: bad as in that's the commit that fixes your issue right?
10:25 dviola: full bisect log: https://0x0.st/Xkb7.txt
10:25 dviola: llyyr: yes, but I still need to test that
10:26 llyyr: well seems like cursor plane probably got re-enabled at some point later in the tree then, that's why you got the regression back
10:26 llyyr: but it doesn't seem like a fix, you can force weston or sway to use software cursor on your end too
10:27 dviola: right, I've been using WLR_NO_HARDWARE_CURSORS=1 before to "fix" that issue in the VMs
10:28 llyyr: >gnome-shell or kwin, which put virtualized drivers on a deny-list when running in atomic context to make them fallback to legacy kms and avoid this issue
10:28 llyyr: huh didn't know
10:35 llyyr: That check is still there on master, so I don't understand why it's broken on master for you
10:41 dviola: yes, good question
10:45 dviola: could that commit that got skipped have something to do with it?
10:48 dviola: that's still there on master as well
10:49 llyyr: possibly, you can try removing that yourself on master
10:49 dviola: I'll try that
10:51 llyyr: the commit you skipped shouldn't cause a build failure though I think
10:55 dviola: building master without 1055077473e3448a13cc002fcad2adb08865e084
10:57 dviola: llyyr: yeah, I don't know why I got that build error
10:57 llyyr: oh I know why
10:58 llyyr: the patchset got applied in reverse order in the linux tree (??)
10:58 llyyr: the commit that uses supports_virtualized_cursor_plane member is applied before the commit that adds supports_virtualized_cursor_plane
10:58 llyyr: how does that happen?
11:00 dviola: good question
11:09 dviola: getting more build errors without that commit: https://0x0.st/Xkcm.txt
11:13 llyyr: that shouldn't happen
11:14 wlb: wayland-protocols Merge request !364 opened by () linux-dmabuf: link to kernel docs https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/364 [linux-dmabuf]
11:14 llyyr: the build error is in another function that shouldn't even be touched by reverting that
11:14 dviola: I've just removed the if check alone
11:14 dviola: and it's compiling now
11:19 dviola: so yeah, master with that if check removed also has the issue
11:21 dviola: I'm out of ideas :/
11:24 dviola: llyyr: oh, I didn't do a `git revert`, I've removed the code manually, let me try with an actual revert of the commit
11:37 dviola: clean build this time
11:40 dviola: same issue, mouse cursor has the issue
12:41 dviola: llyyr: found another workaround
12:42 dviola: getting rid of the ! fixes the issue: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_plane.c#L811
12:45 zamundaaa[m]: dviola: fwiw in KWin we had this issue at some point too
12:45 zamundaaa[m]: https://bugs.kde.org/show_bug.cgi?id=485827
12:47 dviola: zamundaaa[m]: I see
12:48 llyyr: dviola: removing the not just makes it so that the condition never evaluates to true
12:48 llyyr: effectively the same as removing the line altogether
12:48 llyyr: since I don't believe any of the vm drivers implement that feature
12:50 dviola: makes sense
12:55 dviola: so that's essentially the same as running in software cursor mode?
12:58 zamundaaa[m]: <llyyr> "since I don't believe any of the..." <- That line checks the compositor's caps, not anything from the driver
12:58 llyyr: ah
12:59 zamundaaa[m]: dviola: Yes, it removes the cursor planw
12:59 dviola: makes sense, I guess I'll just live with WLR_NO_HARDWARE_CURSORS=1 then
13:00 llyyr: or legacy drm driver
13:01 zamundaaa[m]: dviola: in case there's no such bug report already, it would be good to make one for the virtio driver
13:02 llyyr: wlroots at least seems to claim to support DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT
13:02 llyyr: wonder if the issue is with wlroots then?
13:03 dviola: zamundaaa[m]: I've been thinking about where to report this but I've had a difficult time just figuring out where the prolem is, qemu, wlroots, sway, mesa, the kernel, etc
13:03 zamundaaa[m]: If both kwin and sway are affected, it's unlikely that it's anything except a driver bug
13:04 llyyr: I don't believe they're tried kwin, and kwin seems to have a deny list for virtual drivers where it'll automatically fall back to legacy DRM anyway
13:04 zamundaaa[m]: No, it doesn't
13:04 zamundaaa[m]: That's from before the cursoe hotspot cap existed
13:04 llyyr: ah
13:04 zamundaaa[m]: Also see the bug report I linked
13:05 dviola: I'm still puzzled about why it works with 6.6.60 and not previous or newer versions
13:06 dviola: but yeah I agree that it would be nice to see this fixed
13:06 llyyr: it just uses software cursor
13:07 dviola: llyyr: ah, makes sense
13:07 dviola: I'm fine with that actually
13:21 dviola: zamundaaa: there's already a bug report for sway it seems: https://github.com/swaywm/sway/issues/3814
13:38 dviola: looks like MrCooper was right ("not a kernel regression / not 100% reproducible")
13:41 ofourdan: MrCooper is usually right :þ
13:42 MrCooper: except when I'm not :)
13:42 ofourdan: of course, there are to be exceptions to all rules!
13:42 dviola: yeah, not that I doubt his judgement, I just want to understand why the behavior is inconsistent, what makes it not reproducible
13:43 ofourdan: I was just teasing, nevermind my comment :)
13:47 dviola: I think it's probably sway not going into soft cursors every time
13:49 dviola: I have another wayland issue that I'd like to investigate also, when closing a native game (e.g. Factorio) the steam window will close (swaymsg -t get_tree doesn't show up the window anymore) but the process is still there
14:00 kennylevinsen: that's not by itself an isssue - maybe there's something configurable about staying alive/going to tray? idk
14:02 dviola: good point, seems to not be a problem with Steam's big picture mode
14:10 dviola: I wonder if sway will accept a patch similar to the kwin's one, that detects it's running in a VM and enable software cursors
14:12 dviola: not that I'll do it, I don't know how, but I could look into it at least
14:15 kennylevinsen: that sounds like a kernel bug workaround rather than a fix...
14:15 kennylevinsen: there's a bug in either the kernel or wlroots, and going to software cursor just pretends it isn't there
14:16 dviola: right
14:21 dviola: it will probably distract from getting the real issue fixed and you'll have to do it for every single compositor, not good
14:50 dviola: looks like somebody already reported the issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8730
15:11 soreau: dviola: and it looks like the fix is at the bottom there..
15:14 soreau: so it's curious you say it's broken on latest kernels, because I assume this is upstream
15:14 llyyr: the linked fix is the same as the series that "breaks" it for them
15:15 soreau: llyyr: that's because you told them to bisect upside down and backward ;)
15:15 llyyr: well they were trying to find out what breaks it
15:16 llyyr: I'm still not sure what's going on here, just open a fresh issue on the sway tracker with relevant logs so people can proceed from there
15:18 soreau: could ping Ermine, since they reported and 'found' the fix
15:19 Ermine: hi
15:22 Ermine: Idr if that fixes the bug actually...
17:28 DemiMarieObenour[m]: soreau: That is basically what Qubes OS does, but one of those clients (the GUI daemon) must cause the compositor to draw something that is similar to what the (untrusted) applications in the VM would have caused the compositor to draw, as long as those applications are _not_ being malicious. It’s fine to break malicious or badly-behaved applications, but users expect well-behaved applications to work.
18:09 dviola: soreau: yeah, I can't tell if it was upstreamed though
18:14 soreau: dviola: you can use `git log` on linux git and then `/commit\ message` to see if anything turns up
18:17 soreau: seems like it was https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e3b70da64a53784683cfcbac2deda5d6e540407
18:19 dviola: yeah, the commits in that patchset are all upstreamed
18:19 soreau: so I'd probably check linux git log and /4e3b70da64a53784683cfcbac2deda5d6e540407 to make sure you have it, and if that doesn't work, file an issue
18:20 soreau: (I mean if you have the commit and build it and it doesn't work)
18:21 dviola: is the mesa bugtracker fine to file the issue?
18:21 dviola: I can probably reference the old bug report also
18:22 soreau: since it's apparently a kernel issue, you'd have to file an issue against the kernel, unless you can otherwise prove that mesa is also somehow involved
18:24 dviola: yeah, I'm not sure where to report the kernel bug though, looks like I'll need to email the people involved?
18:25 dviola: there's https://bugzilla.kernel.org/ but I often hear that not all developers use it
18:26 soreau: dviola: I'd ask in #dri-devel on this network
18:36 dviola: done
19:09 wlb: weston Merge request !1644 opened by () color: optimize the 3D LUT fallback path https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1644 [color-lcms plugin], [Colour management]
19:10 leandrohrb56: emersion, jadahl, pq: ^ the code to decompose 3D LUT into shaper + 3D LUT
19:13 llyyr: is there any weston branch adding parametric support yet?
19:17 leandrohrb56: there's https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1502 which adds integration with the Wayland protocol, but only creates a boilerplate color profile with the data
19:17 leandrohrb56: properly creating the parametric color profile and the color transformations is still a TODO
19:43 llyyr: i see, thanks for all the work!
19:49 leandrohrb56: np! :)
20:44 dviola: there's another issue with mouse cursor on sway (happens everywhere, host and VM) -- this one started to appear with the latest update and probably have nothing to do with the other bug, when you open up a terminal the cursor changes from an arrow to an "i-beam", after closing the terminal the cursor never updates anymore (to an arrow)
20:44 dviola: it updates after I move it again
20:49 dviola: I'd bisect but newer sway requires newer wlroots, makes things difficult :(
20:53 soreau: dviola: maybe try another compositor to see if it happens there. if it does, probably points to wlroots
20:53 soreau: if it doesn't, might be a sway thing
20:53 dviola: or rather, bisecting is not easy because different versions require different wlroots versions
20:54 dviola: soreau: I'll try that later today, thanks
20:57 dviola: actually, let me try weston real quick
20:58 dviola: nope, weston is fine
21:06 dviola: hyprland is also fine
21:06 dviola: hyprland no longer uses wlroots so it's probably wlroots issue
21:11 dviola: I think I'll just wait since some of those issues are a PITA to debug, what else can I do anyway
21:14 soreau: dviola: try two different wlroots compositors
21:15 soreau: if they both have the same issue, more likely a wlroots bug, but if only sway has it and another does not with same wlroots version..
21:20 dviola: soreau: sure, I'll try that
22:03 emersion: leandrohrb56: thanks!
22:43 dviola: soreau: just tried river which is also wlroots-based, and the issue is not present
23:12 dviola: if you have any other suggestions about things to try to help with my bugs please let me know!
23:34 soreau: dviola: it sounds like an issue with sway, you can file an issue or ask in #sway on libera
23:54 dviola: I will file an issue
23:58 dviola: Ermine: would you be ok to reopen https://gitlab.freedesktop.org/mesa/mesa/-/issues/8730 since it sounds like the issue is not fixed yet?