<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Screen size cannot rely on wl_output scale and geometry" href="https://bugs.freedesktop.org/show_bug.cgi?id=101436#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Screen size cannot rely on wl_output scale and geometry" href="https://bugs.freedesktop.org/show_bug.cgi?id=101436">bug 101436</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=101436#c2">comment #2</a>) > (In reply to Pekka Paalanen from <a href="show_bug.cgi?id=101436#c1">comment #1</a>) > > This report sound like a continuation of the long irc discussion I had with > > Olivier Fourdan, where talked about how one could support HiDPI and > > mixed-dpi systems with Xwayland. Should we include that topic here as well? > > Mixed DPI systems is also covered in > <a class="bz_bug_link bz_status_NEW " title="NEW - Automatically scale windows?" href="show_bug.cgi?id=93315">https://bugs.freedesktop.org/show_bug.cgi?id=93315</a> . But yea, mixed DPI > systems are relevant here. Are the conclusions / raised issues etc from that > discussion summarized anywhere? Not written down, no - we didn't really reach a conclusion. The end result was that we were both confused about Mutter's way of doing things, which seemed to be fundamentally different from Weston's. So different that we would actually need two different operating modes in Xwayland to handle them, and that was before the idea of fractional scaling. It seemed like Mutter's current design could never support mixed-dpi setups with Xwayland. <a href="https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland&date=2017-06-06">https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland&date=2017-06-06</a> >From 13:00 to 14:25. I wonder if it is at all possible to even have X11 windows with drawn scales (app-side scaling). That seems fundamentally incompatible with compositor scaling, given the requirement of a consistent global coordinate system used for both input and output in X11. > > > > You now want to support fractional scaling behind applications' back. Was > > this not foreseen when the wl_output and wl_buffer scale protocol was > > designed? What has changed? Why is it now feasible? > > Currently it is done by telling clients to scale with ceilf(scale) then > downscale. For example if you scale the area of a monitor with scale 1.5, > you'll tell clients to draw at 2, then downscale to 1.5. > > Right now this works by pretending that the mode of wl_output is the logical > monitor size. Xwayland windows will of course still always to be considered > scale 1, and upscaled to 1.5. > > I somewhat touched on it in this E-mail: > <a href="https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html">https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html</a> But why was that implemented? Is fractional scaling not too ugly to be used after all? Why do you want it? What is different from the time the scaling feature was designed? If it's really needed, then I feel we made a mistake with the integer-only scales design in the protocol. Should we have also a divisor for the scale factor? The email does not explain why, but it seems to contradict some claims that arose during my and Olivier's irc discussion. >From the beginning, wl_output's modes are the video modes on the hardware which means that if a client aims for perfect fit with a fullscreen, directly scanned out buffer, it needs to make the buffer size exactly the advertized mode size. I think this is the fundamental feature we need to keep intact. It is a bypass of the shell protocols unfortunately, I'm not sure we can make that go away. If RandR information in Xwayland needs to be different from the hardware video modes, I believe that should be computed in Xwayland, otherwise we screw up all Wayland clients; or, sending different parameters to one client (Xwayland) vs. others in a non-Xwayland-specific interface is far too subtle to rely on IMO. I think it would be ok for shell protocols to offer alternative fullscreen window sizing methods that worked in the logical pixels instead of output hardware pixels - essentially xdg_shell already does that AFAIU. Fitting this together with the wl_output size is awkward, but I think it is doable with wl_viewport: you make the buffer with the wl_output size and use wl_viewport to make the window size match what the shell protocol asks for. That might allow for fractional scaling combined with a direct scanout path for e.g. native Wayland games. But all that seems fundamentally incompatible with Xwayland. I think games there need to just rely on display hardware doing the scaling since drawing a buffer matching the hardware mode does not seem possible for output scales other than one. Is there something in the above that just cannot be made to work with Mutter or denies features you want like the fractional scaling? Should we look forward to deprecating wl_buffer scale from the protocol (as in, recommend it to be always left to one) if we use wl_viewport as a recommended solution?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>