Weston stuff: fractional HiDPI, FreeBSD, Rust

[Pekka Paalanen]

On Thu, 14 Dec 2017 03:05:59 +0300
Greg V <greg at unrelenting.technology> wrote:

> Hi everyone!
> 
> I've been hacking around, trying to make Weston more usable for myself…

Hi,

nice work!

Here are my initial thoughts of the ideas, but mind that I didn't look
at the code at all, so some questions might sound lazy.

> So far I've done:
> 
> - FreeBSD support: https://github.com/myfreeweb/weston/commit/5827840c8
> 2b9d0a302d5c54c514ca6f4238e12de

In theory I'd support this, but I'm sure we'll have some bikeshedding
on how to actually deal with the alternative code. I would also be
worried about testing, because most developers don't run any BSD and
changes would not be tested without a CI running something on a BSD.
And if testing would catch breakage on BSD, at least I wouldn't know
how to fix it.

> - memfd/anonymous shm in os_create_anonymous_file: https://github.com/m
> yfreeweb/weston/commit/24bbf0d9265478c406a23d8f1642a37daf43425f

Sounds nice.

> - static linking of backends and gl-renderer: https://github.com/myfree
> web/weston/commit/c9ed3f9683bd7fb99aa0e811348fbcec37674140 for language
> bindings (e.g. there's no good way to ship additional shared libraries
> when you're a Rust library, I don't think cargo supports that)

How does that generalize to plugins? Aside from the backends and the
renderer, there is the xwayland plugin. I think the rest are still
pratically Weston plugins rather than libweston plugins. Even that
creates quite a lot of combinations.

Do you mean that the Rust crate is shipping a statically linked
libweston, instead of linking to the system-installed libweston? Why?
What about everything libweston depends on, do you statically link all
that as well? And Mesa?

> - the Rust libweston bindings themselves https://github.com/myfreeweb/w
> eston-rs — incomplete/WIP, but a simple example compositor works! (see
> weston-rs/examples folder)

Is this something that would need to live with libweston or can it be a
separate project?

> - fractional DPI scaling! https://github.com/myfreeweb/weston/commit/d2
> 16493ae33659a98b9a9cbe77d4068b9462eea8 (additional downscaling after
> integer scaling)

I would guess users would welcome this feature, so sure, details to be
discussed.

> Please tell me if there's any interest in merging some of these changes
> into upstream weston!

Just a reminder that we are thin on review bandwidth as always. :-)

> //
> 
> The fractional scaling was surprisingly easy to implement, works
> perfectly with native Wayland apps and looks excellent on my 28" 4K
> monitor (140% scale).
> 
> However… Xwayland.
> 
> I saw a lot of discussion of multiple monitors with different DPIs and
> stuff. I only have one single monitor and I just want Firefox and
> Thunderbird to not be blurry.
> 
> So, Weston assumes that X11 clients are not DPI aware. (Personally, I
> haven't seen any clients that don't respect Xft.dpi in Xresources…)
> 
> I tried to change that, to make Weston assume they are DPI aware:
> 
> libweston-desktop/xwayland.c
> @@ -256,6 +257,10 @@ create_surface(struct weston_desktop_xwayland 
> +       wsurface->pending.buffer_viewport.buffer.scale = 2;
> +       wsurface->pending.buffer_viewport.changed = 1;
> 
> well… the resolution is correct, but everything becomes unusable :(
> Only rendering is properly scaled, mouse input is not! Mouse position
> appears to X11 clients as if they were not downscaled. So clicks go to
> wrong places and wrong areas get re-rendered in the compositor. And
> yeah, no more shadows in gtk3 apps, instead there's a black rectangle
> behind the window.
> 
> https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/xwayland-d
> ebug.png — the gl renderer's debug view shows the damage area on the
> button is not where it should be.
> 
> Apparently GNOME handles this correctly. I've tried looking at mutter
> source, haven't found anything useful.
> 
> How do I fix this?? Please help…

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171214/fddbf606/attachment-0001.sig>