Weston stuff: fractional HiDPI, FreeBSD, Rust

[Pekka Paalanen]

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

That sounds fine to me, just try to keep the ifdefs in code to a
minimum and have them in some headers instead if possible.
Conditionally compiling (Makefile.am) whole files would be good too.

I think there was a patch floating for error().

Btw. what about libwayland?

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

It's a snag all libweston-based compositors will hit, someone needs to
be the first to complain at distros to get libweston packaged
separately from Weston. ;-)

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

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


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/a4a16209/attachment.sig>