<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#c2">Comment # 2</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:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Pekka Paalanen from <a href="show_bug.cgi?id=101436#c1">comment #1</a>) > Could you also clarify what "screen size" and "monitor size" mean and what > they are used for via Xwayland? I kind of know what they are in X11, but I > have no idea how X11 applications use them. They may for example position a popup menu in relation to the edges. For example if you open context menu far to the right in Firefox, it'll expand to the left instead of right if it wouldn't fit to the right. They also tend to use it to be "smart" about an initial size, e.g. to cover N % of the screen space or something. > > E.g. for fullscreening, I would hope apps used WM protocols to ask what > their fullscreen size should be, but I understand that's wishful thinking. > So how exactly are these details used? > How maximize and fullscreen works I'm not very familiar with. > 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? > > 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></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>