Weston stuff: fractional HiDPI, FreeBSD, Rust

Tue Jan 9 08:39:02 UTC 2018

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 at 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 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel