Weston stuff: fractional HiDPI, FreeBSD, Rust

[Greg V]

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:
> > - FreeBSD support
> 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.
Hmm, actually, I think keeping very-FBSD-specific changes (namely, TTY
handling) in FreeBSD Ports might work better, but Weston should take
some general non-GNU/Linux support changes, such as

- ifdef linux the _RAW/_COARSE clocks
- ifdef linux the abstract socket in xwayland/launcher
- ifdef linux the sync_file stuff
- ifndef ETIME define ETIME ETIMEDOUT
- perror/fprintf/exit instead of the GNU error function (or define the
error function if it doesn't exist??)
- clearenv() fallback
- program_invocation_short_name fallback

I can split my big patch into these changes and send them here. What do
you think about that?

> > - static linking of backends and gl-renderer
> 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.
Yeah, didn't touch the xwayland plugin yet, going to add it eventually.

> 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?

Statically linked libweston, dynamically linked everything else.

It's possible to depend on the system-installed libweston, and I'll
eventually add an option to do just that.

My idea was that libweston is an implementation detail, the user of a
weston-rs-based compositor shouldn't be required to install libweston.
(Which practically means installing Weston — even Arch Linux and NixOS
don't ship libweston in a separate package right now.)

> > - the Rust libweston bindings themselves
> Is this something that would need to live with libweston or can it be
> a separate project?
Of course it is, and should be, a separate project :)

> > - 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)?

> > 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 655 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171214/a623c5f0/attachment.sig>