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: > > - 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?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
