<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hej Keith, I've been working on this, too, for the XWayland case. It's only a proof of concept, but I tested it successfully with a couple of fullscreen apps (read: games). When asking people in the IRC channel, the general consensus seemed to be to go for option one, by making use of viewporter wayland protocol, which is why implemented it for gnomes mutter (see 1, won't make it before gnome 3.32). There are also patches to expose all modes send by the compositor in XWayland ( see 2) and to make XWayland use randr 1.2 hooks, which makes things quite a bit easier (see 3). I can post my WIP work (will have to clean it up and rebase to current master). That said, I'm very interested to see this go forward and am very willing to help :) Best regards, Robert 1) <a class="moz-txt-link-freetext" href="https://gitlab.gnome.org/GNOME/mutter/merge_requests/121">https://gitlab.gnome.org/GNOME/mutter/merge_requests/121</a> 2) <a class="moz-txt-link-freetext" href="https://patchwork.freedesktop.org/patch/191035/">https://patchwork.freedesktop.org/patch/191035/</a> 3) <a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/show_bug.cgi?id=104644">https://bugs.freedesktop.org/show_bug.cgi?id=104644</a> <div class="moz-cite-prefix">On 27.08.2018 08:24, Keith Packard wrote: </div> <blockquote type="cite" cite="mid:87o9dominq.fsf@keithp.com"> <pre wrap=""> I'm doing a bit of work to help support applications that want to run at a small fixed size. The 'usual' way to make them visible on our modern desktops is to flip video modes, but that means everything runs at low resolution, plus you get the adventure of switching modes, which can take a long time in complex monitor environments. <a class="moz-txt-link-freetext" href="https://keithp.com/blogs/window-scaling/">https://keithp.com/blogs/window-scaling/</a> The basic plan is to make the size-as-seen-by-the-owner different from the size seen by the rest of the system, and then to either have the server scale the output or get the compositing manager to do it. This solves one of the main use cases for 'composite redirection' that I talked about a long time ago and could never get to work. Restricting the problem space to simple application scaling, instead of arbitrary transformation, meant that I could place the input event scaling right inside the X server, allowing it to be synchronous, instead of attempting to have some external agent perform the transformation. When there's no compositing manager running, the window is placed into automatic compositing mode and the X server performs the necessary output scaling. When there is a compositing manager running, I've thought of three possible ways to make it work: 1. The compositing manager can be extended to handle the scaling operation. This seems like the best plan; just a single copy from the native application size to the scanout buffer. 2. Alternatively, another window might be interposed between the scaled client and the compositor to provide a place for the X server to do the scaling; although that would naturally introduce a bunch more expense and delay in the process. 3. It would also be possible to have the X server provide a scaled version of the window pixmap to the compositing manager until it advertised support for built-in scaling. Same rendering delay as with an interposed window, but no changes required in the environment, although a bit of work to be done in the X server. That might be a good transition plan so that things didn't break when you started a compositing manager without the required support. I'm wondering if there are others who would find this useful, and if some of them might help get this into reasonable shape. Suggestions are welcome! </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ <a class="moz-txt-link-abbreviated" href="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</a>: X.Org development Archives: <a class="moz-txt-link-freetext" href="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</a> Info: <a class="moz-txt-link-freetext" href="https://lists.x.org/mailman/listinfo/xorg-devel">https://lists.x.org/mailman/listinfo/xorg-devel</a></pre> </blockquote> </body> </html>