09:33 <ishitatsuyuki> While thinking about fractional scaling, I've found Wayland's design to notify application of *all* outputs it's being shown on to be strange

09:33 <ishitatsuyuki> The Windows approach has another small benefit which is that per-monitor DPI aware applications also supports changing DPI on-the-fly (on a single monitor) without modification

09:33 <ishitatsuyuki> Thoughts?

09:33 <ishitatsuyuki> Even if a surface can span multiple displays, it only gets a single buffer and it feels more reasonable that the compositor decides on a "primary" display and expose it to application (Windows does this), rather than having the application to choose one based on limited information

09:54 <wlb> weston Merge request !678 opened by Marius Vlad (mvlad) Convert remaining clients to xdg-shell https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/678

16:39 <Lantizia> Evening :)

16:40 <Lantizia> Running native (and also Wine) games full screen on X11 sometimes sucked for particular reason... if the uncleanly exited... you'd be left with the games resolution for your desktop. The same problem existed if you ALT+TAB'd between the game and the desktop.

16:41 <Lantizia> Now presumably if (correct me if I've got this wrong) on a Wayland desktop... each app/game/whatever that expects X11... gets it's own X11 server? then when the app closes (cleanly or not) then so does the X11 server and we should go back to whatever the normal resolution was?

16:41 <Lantizia> If anyone has any thoughts on that?

17:00 <LaserEyess> no, that's not how it works, there's a single Xwayland server that gets started, all X11 clients on wayland use that Xwayland server

17:01 <LaserEyess> if you're looking for a way to essentially sandbox games so they can't mess with your desktop, look into https://github.com/Plagman/gamescope

17:35 <emersion> games cannot change the resolution on Wayland

17:36 <emersion> instead, Xwayland will emulate the resoltuion change and scale the game's window if possible

17:49 <Lantizia> emersion, ah well that mitigates the issue entirely then

17:51 <Lantizia> emersion, what about games that use wayland directly? if they temporarily change the res? e.g. if it's some future of wine that runs on wayland... and the game changes res using CDS_FULLSCREEN - which is meant to be treated as a temporary change... and on windows a normal alt+tab would be fine - as it would be if the game crashed... windows/explorer would restore the original res as it *KNEW* it was only a temporary res

17:53 <swick> Lantizia: wayland clients simply cannot change the resolution of outputs

17:56 <swick> ishitatsuyuki: fwiw for color management we also communicate all outputs a surface is shown on and which one is preferred. if the user has one color correct/profiled output the user might want surfaces to be shown without the compositor mangling the colors on that output at any time.

17:57 <swick> more specifically with scaling, you might be able to find a surface scale factor which works well for multiple outputs

22:55 <dottedmag> Is there a race between wl_registry::global_remove event and wl_registry::bind message? It looks like a client can request a registry, then try to bind the global right at the time one of the global objects is gone. Is it compositor's responsibility compensate for it by retaining global objects to be available for binding for some time after the global_remove event is sent, or should clients be prepared to handle the error?