On Thu, Dec 14, 2017 at 04:07:42PM +0200, Pekka Paalanen wrote: > On Thu, 14 Dec 2017 14:20:30 +0300 > Greg V <greg@unrelenting.technology> wrote: > > On Thu, 2017-12-14 at 10:21 +0200, Pekka Paalanen wrote: > > > On Thu, 14 Dec 2017 03:05:59 +0300 > > > Greg V <greg@unrelenting.technology> wrote:
... snip ... > > > > > - fractional DPI scaling! > > > I would guess users would welcome this feature, so sure, details to > > > be discussed. > > Yeah, I guess my main question is, is a separate option fine (scale=2 > > extra-scale=0.7) or should I make the scale option do everything > > (scale=1.4)? > > Umm... well, extra-scale would certainly be inconvenient. Maybe go with > scale=1.5? > > One caveat with fractional scaling is that it makes the resolution > information in wl_output interface useless, but I'm kind of thinking it > shouldn't have been there to begin with. FWIW, the way mutter/gnome-shell implements this is to configure a output/monitor using a fractional scale. We calculate the scale so that will align outputs in a logical discrete logical pixel grid. Surfaces are then placed in the logical pixel grid just as they already are in weston. We then advertise ceil(max(overlapped_output_scales)) to Wayland clients. We don't ever *configure* the ceiled scale anywhere, it is simply what is sent to the clients. Regarding the wl_output modes, Xwayland currently has a bug which mutter (in 3.26) abuses to make X11 clients not regress. In short, Xwayland will take the current wl_output mode, ignore any scale, and use the mode to configure the Xrandr monitors and the X11 screen. Since we want to make it possible to fix Xwayland to actually take the scale into account, while properly implement wl_output modes, as well as not cause any regressions, we introduced xdg_output (see wayland-protocols) which will actually make it possible to do things correctly by letting clients (read Xwayland) know about the *logical* size of a wl_output. See https://bugzilla.gnome.org/show_bug.cgi?id=787363 for more details. > > > > > However… Xwayland. > > > I suppose the hack is wrong. ;-) > > > > > > It would be best for Xwayland server to set the buffer_scale > > > appropriately. It also changes the window coordinate systems which I > > > guess is why everything breaks. A buffer of 600x400 with > > > buffer_scale=2 > > > produces a wl_surface of 300x200. Input and damage communication > > > happens in the wl_surface coordinate space, so those need to be > > > adjusted as well. But that is only the Wayland side of it. > > > > > > The X11 side has its own global coordinate system that X11 clients > > > expect to be consistent. When wl_surface size no longer matches the > > > X11 > > > Window size, something has to convert between the two, and at least > > > XWM > > > in Weston and Xwayland would be involved. But it affects also things > > > like RandR advertised output sizes and the X11 SCREEN size. I don't > > > actually know if or how all that can be made to work. The X11 > > > coordinate system needs to be consistent not only inside a top-level > > > window, but for the whole desktop, because X11 apps will position > > > arbitrary windows in absolute coordinates, without telling the server > > > what the geometric relationship is intended to be. > > > > Is it possible to somehow "passthrough" the X11 clients without > > scaling? Bypass the compositor-side global coordinates, mapping the > > X11-side one directly to device coordinates? I guess GNOME might be > > doing something like that? > > Yeah, I think mutter does that. Or did. > > Might be hard to do in Weston though, we would not want xwayland > details leaking into libweston core. I have hard time imagining how it > would work. Sure, it's pretty easy if you only have one output, but > libweston supports extended desktop over multiple outputs with > differing scales. If you need to scale a surface differently for > different outputs, I think that would break the global coordinate > system used inside weston for window positioning and input. The way > Weston is architected is that surfaces/windows are in a global space, > and then outputs are areas of the global space we render for a screen. Mutter in 3.26 by default will abuse the bug in Xwayland mentioned above to trick Xwayland to set up the monitors and screen in a way that is compatible with how X11 traditionally works, i.e. physical pixel = logical pixel. This is currently the only way to not cause regressions when combining X11 clients and multi DPI systems; however this is also not how weston works, and this is not how mutter+fractional scaling works. With Xwayland fixed (by using xdg_output), things are still very complicated regarding output scales, HiDPI etc. I recommend you read this page about this[0] wiki page, and this[1] bug report for further details about ideas how to potentially deal with Xwayland and different scaling. Jonas [0] https://wiki.gnome.org/Initiatives/Wayland/XWayland [1] https://bugs.freedesktop.org/show_bug.cgi?id=93315 > > > Thanks, > pq > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
