12:50 <alwayscurious[m]> I have a client that needs to know the absolute position of its own windows. What is the best way to implement this?

13:02 <emersion> the best way is not to

13:02 <emersion> why do you need to know the absolute position?

13:04 <dottedmag> And what is absolute position anyway?

13:47 <alwayscurious[m]> <emersion> "why do you need to know the..." <- Because the clients are virtual machines, and each VM needs to be able to share its own screen. And to do that it needs to know where its own windows are.

13:47 <alwayscurious[m]> <dottedmag> "And what is absolute position..." <- Position relative to the physical screen.

13:47 <emersion> i don't understand your use-case

13:47 <alwayscurious[m]> Qubes OS

13:48 <emersion> … yes?

13:53 <alwayscurious[m]> Simplified version: in Qubes OS, there is a GUI agent that runs in each guest virtual machine and connects to the GUI daemon running in the host. The GUI agent is currently an X window manager, and the GUI daemon is currently an X client. I am currently making a Wayland compositor version of the GUI agent, and would like the GUI daemon to be a Wayland client in the future.

13:53 <alwayscurious[m]> Qubes OS will be gaining support for cross-VM screensharing in the not too distant future. For that to work, each qube (VM) needs to know (or be able to find out) what would be displayed on the physical display if no other qubes were running. That means it needs to know the position of its own windows.

13:54 <alwayscurious[m]> Additionally, the GUI agent needs to be able to be an X window manager even if the GUI daemon is a Wayland client, and the GUI agent needs to know where the windows it has created are for that to work.

13:56 <alwayscurious[m]> The GUI daemon does not need to be able to set the absolute position of its windows, merely read it.

13:58 <alwayscurious[m]> I am willing to submit MRs to wayland-protocols and to at least try to contribute patches to the major compositors if so required.

13:58 <alwayscurious[m]> But I will need design help.

14:21 <alwayscurious[m]> <robertmader[m]> "alwayscurious: I don't think suc" <- The GUI daemon and GUI agent are under the control of Qubes OS, but the desktop environment is minimally modified.

14:22 <alwayscurious[m]> Exposing more info is an anti-goal of Qubes, and an alternative that did not require this would be preferable. I haven’t been able to find one, though. That does not mean none exists.

14:26 <alwayscurious[m]> I have no interest in the position of other clients’ windows. Just to be able to query of the position of windows created by the same client making the query.

14:26 <emersion> alwayscurious[m]: i still don't understand why the absolute position is important

14:26 <emersion> are you trying to do xwayland over wayland?

14:26 <emersion> x11 over wayland?

14:27 <alwayscurious[m]> That needs to be supported, yes.

14:27 <alwayscurious[m]> Essentially

14:27 <alwayscurious[m]> The real situation is obviously much more complicated

14:29 <emersion> this doesn't seem like something that should be widely supported

14:29 <emersion> it should only be supported by your custom compositor

14:31 <alwayscurious[m]> The two major problems I have run into so far are:

14:31 <alwayscurious[m]> 2. When a VM shares its own screen (*not* the host’s screen) with another VM, it needs to know where to put its windows in the video stream it generates.

14:31 <alwayscurious[m]> 1. X11 programs in VMs still need to be supported, even after the host’s GUI agent switches to Wayland.

14:33 <vyivel> so, you have a daemon and a bunch of agents/VMs? are there any GUI clients that can connect to daemon directly, without an agent?

14:34 <alwayscurious[m]> vyivel: There is one daemon per VM. From the host compositor’s perspective, the daemon is just another Wayland client.

14:35 <vyivel> ah, nvm

14:38 <alwayscurious[m]> Modifying the desktop environment would of course work, but is a significant maintenance challenge, and that challenge will grow in the future. Qubes OS currently supports Awesome, i3, XFCE (the default), and KDE, and support for GNOME is planned. Furthermore, R4.1 includes support for running the GUI outside of dom0, and a future release will require this, which means that shipping a patched desktop environment would be even more

14:38 <alwayscurious[m]> difficult.

14:38 <alwayscurious[m]> Obviously, i3 and Awesome are X11 window managers, but there are Wayland clones of both.

15:12 <dottedmag> This looks like a new protocol extension will be required. Imagine a compositor displaying a window slanted or spinning. Nowadays clients are oblivious to this.

15:12 <dottedmag> Also GUI agent looks like a Wayland proto proxy, with additional feature "compose all windows from this VM into a single framebuffer" for sharing?

15:21 <alwayscurious[m]> <dottedmag> "Also GUI agent looks like a..." <- That is *exactly* what it is, although it uses a custom (much simpler) protocol to communicate with the daemon.

15:22 <alwayscurious[m]> <dottedmag> "This looks like a new protocol..." <- It will be. I plan on resolving the security concerns by making it opt-in and subject to compositor-side access controls, with the default being to deny the operation.

15:54 <emersion> alwayscurious[m]: why not make it mandatory for the outer session to use wayland if the inner session is also using it?

16:10 <dangole> as a fun project for the weekend i choose to compile the wayland/weston stack on OpenWrt, to run on my MediaTek MT7623N-based BananaPi BPi-R2 board. I got as far as getting output on fbdev fully working, i can use weston-terminal and things are working as expected. in drm mode, however, the tty basically just freezes and nothing happens. logs here: https://termbin.com/4zcq

16:11 <dangole> so this is on musl of course, we don't have libpam, so I'm starting weston directly (as I got neither systemd nor weston-launch, which would require pam) and LD_PRELOAD=/usr/lib/libEGL.so.1

16:56 <emersion> starting weston directly won't work

16:56 <emersion> i'm a bit surprised weston-launch depends on PAM

16:57 <emersion> weston master should have support for seatd

17:08 <dangole> emersion: on OpenWrt we don't have systemd with seatd either...

17:09 <dangole> emersion: and musl seems to require LD_PRELOAD'ing libEGL.so.1 for things to work at least a bit

17:10 <emersion> dangole: seatd != systemd

17:11 <emersion> https://git.sr.ht/~kennylevinsen/seatd/

17:19 <dangole> emersion: interesting. thank you! i'll give that a shot.

17:44 <wlb> wayland Issue #229 opened by Simon Ser (emersion) wl_surface.frame interactions with sub-surfaces https://gitlab.freedesktop.org/wayland/wayland/-/issues/229 [Protocol]

18:57 <dangole> emersion: so now that i got seatd and libseat, how do i use that? as in: how to use that to start weston in a away that works? by now i've also verified that kmscube works, and yes, it does.

18:57 <emersion> start seatd, then start weston

18:58 <dangole> emersion: and i need weston master branch, 9.0.0 release is not good with that, right?

18:58 <emersion> yeah, need weston master

18:58 <emersion> weston needs to link with libseat

18:58 <emersion> s/master/main/

19:24 <dangole> emersion: ok, now i see a line saying "libseat: session control granted" in the stderr of weston, but screen content still freezes. fbdev_backend works fine, kmscube works fine. just drm_backend doesn't. did you see the logs i posted before? https://termbin.com/4zcq

19:30 <dangole> looks like it just stops redrawing the previous fbconsole content, ie. content stays but cursor stops blinking until i kill weston.

21:45 <carbonfiber> Using xorg i can just launch xterm without using any window manager. What is the simplest way to just run a centered xterm (inside xwayland) using wayland? I don't care about window decorations, and i don't care about mouse support. I just want a terminal with the least amount of code dependencies.

22:13 <LaserEyess> carbonfiber: cage is probably the closest thing to that

22:13 <LaserEyess> but it's still a window manager starting a terminal

22:21 <carbonfiber> LaserEyess: allright. thanks. I will give it a look.

22:25 <LaserEyess> https://github.com/Hjdskes/cage

23:15 <katp32> heyo, I'm having some issues with libinput; my huion drawing tablet is recognized by the kernel, and everything looks fine when I check the kernel events with evtest, but libinput complains "event14 - HUION Huion Tablet: libinput bug: missing tablet capabilities: resolution. Ignoring this device."

23:15 <katp32> this device used to work fine with libinput from what I can remember, I have literally no clue what's wrong or how I'm supposed to fix it

23:55 <katp32> I'd really appreciate any help...