Re: Why isn't Xwayland just a Wayland client?

On Thu, Sep 7, 2017 at 1:17 AM, Carsten Haitzler wrote: > > It is CSD in Wayland for Wayland clients, unless somehow compositor and client > negotiate something else. In the default case, if a client does not decorate > it > will not get any decorations (titlebar and so on) at all. IIRC that's n

Re: Why isn't Xwayland just a Wayland client?

On Wed, 6 Sep 2017 15:49:48 +0200 Joseph Burt said: > Hi Olivier, > > On Wed, Sep 6, 2017 at 1:05 PM, Olivier Fourdan wrote: > > > > One thing to consider as well is that you will need to decorate the X11 > > windows as Wayland is basically client side decorations. > > I was under the impressi

Re: Why isn't Xwayland just a Wayland client?

On Wed, Sep 6, 2017 at 4:45 PM, Pekka Paalanen wrote: > Popups (e.g. menus) in Wayland use protocol that provides the server > with: > - the relationship to the window which the popup is for, and > - the input event identity that triggered the popup. > > These are required on Wayland: the parent w

Re: Why isn't Xwayland just a Wayland client?

On Wed, 6 Sep 2017 15:59:17 +0200 Joseph Burt wrote: > Hi Daniel, > > On Wed, Sep 6, 2017 at 1:09 PM, Daniel Stone wrote: > > > > No-one wanted to write yet another X11 window manager; what's there is > > there by necessity so as not to break existing clients. For instance, > > pop-up menus rel

Re: Why isn't Xwayland just a Wayland client?

Hi Daniel, On Wed, Sep 6, 2017 at 1:09 PM, Daniel Stone wrote: > > No-one wanted to write yet another X11 window manager; what's there is > there by necessity so as not to break existing clients. For instance, > pop-up menus rely heavily on the global co-ordinate system remaining > intact. Are p

Re: Why isn't Xwayland just a Wayland client?

Hi Olivier, On Wed, Sep 6, 2017 at 1:05 PM, Olivier Fourdan wrote: > > One thing to consider as well is that you will need to decorate the X11 > windows as Wayland is basically client side decorations. I was under the impression that Wayland doesn't specify client- or server-side decoration, and

[PATCH] protocol: add support for getting aspect ratio info from modes

From: Ankit Nautiyal The Structure wl_output_mode has flags that describe properties for output mode. This patch adds the support for aspect ratio property. These flags if set, will give information about the aspect ratio supported by an output mode. The wayland based compositors can use this inf

[PATCH] compositor-drm: Add the aspect ratio parsing support

From: Ankit Nautiyal DRM layer populates aspect ratio information for CEA video modes, but we lose it while parsing modeline (Aspect ratio patch series in drm layer: https://patchwork.freedesktop.org/series/10850). The flag bits 19-22 of the connector modes, provide the aspect ratio info. This in

[PATCH] Add aspect-ratio support in wayland layer.

From: Ankit Nautiyal This patch series adds video mode aspect ratio support for wayland protocol and weston drm compositor. This patch series adds two patches: 1- Adds aspect ratio flag bits bits in wl_output_mode flags as per DRM layer implementation. 2- Preserves and uses the aspect ratio flags

[PATCH 6/6] main: don't configure /dev/fb0 by default

--- compositor/main.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/compositor/main.c b/compositor/main.c index f88608cd..cd07a6bb 100644 --- a/compositor/main.c +++ b/compositor/main.c @@ -1450,9 +1450,6 @@ load_fbdev_backend(struct weston_compositor *c, parse_options(fbdev_opti

[PATCH 2/6] libweston: fbdev: support the --seat option, (and XDG_SEAT variable)

--- compositor/main.c| 2 ++ libweston/compositor-fbdev.c | 5 - libweston/compositor-fbdev.h | 1 + 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/compositor/main.c b/compositor/main.c index 61bda282..f88608cd 100644 --- a/compositor/main.c +++ b/compositor/main.c @

[PATCH 4/6] libweston: fbdev: set fb device info upon the first run.

This attempts to wake up secondary framebuffer devices (/dev/fb1 and up) as usually these devices start powered off, and the FBIOPUT_VSCREENINFO ioctl turns it on. This was tested on a qemu system with the options: -vga none -device VGA,id=video0 -device secondary-vga,id=video1 \ -device secondary

[PATCH 5/6] libweston: fbdev: Attempt to detect the first framebuffer device in the seat. instead of defaulting to /dev/fb0

--- libweston/compositor-fbdev.c | 35 +-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/libweston/compositor-fbdev.c b/libweston/compositor-fbdev.c index a9cc08be..99362b8a 100644 --- a/libweston/compositor-fbdev.c +++ b/libweston/compositor-fbdev.

[PATCH 1/6] libweston: set the seat automatically based on the XDG_SEAT environment variable

--- compositor/main.c| 2 +- libweston/compositor-drm.c | 5 + libweston/compositor-fbdev.c | 5 + man/weston-drm.man | 7 +-- 4 files changed, 16 insertions(+), 3 deletions(-) diff --git a/compositor/main.c b/compositor/main.c index 0615d87e..61bda282 100644 -

[PATCH 3/6] launcher-logind: only get a VT on seat0, as only seat0 supports VTs

--- libweston/launcher-logind.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/libweston/launcher-logind.c b/libweston/launcher-logind.c index a069bd4f..11627590 100644 --- a/libweston/launcher-logind.c +++ b/libweston/launcher-logind.c @@ -762,18 +762

[PATCH 0/6] libweston: Support multiple seats better

I am resending as I messed up one of the commit messages, which resulted in a very long subject by mistake. These patches fix issues with Weston where it supports multiple seats better. Firstly supporting automatically detecting the seat to use, by using the XDG_SEAT variable set by logind if the

Re: Why isn't Xwayland just a Wayland client?

Hi Joseph, On 6 September 2017 at 11:56, Joseph Burt wrote: > I'm thinking this might be a job for a bit of translation shim within > Xwayland. Everything an X client needs either has a Wayland equivalent > (through an X server and a little translating XWM shim) or, where > forbidden by Wayland,

Re: Why isn't Xwayland just a Wayland client?

Hi, On 6 September 2017 at 12:56, Joseph Burt wrote: > I'm thinking this might be a job for a bit of translation shim within > Xwayland. Everything an X client needs either has a Wayland equivalent > (through an X server and a little translating XWM shim) or, where > forbidden by Wayland, can be

Re: Why isn't Xwayland just a Wayland client?

Hi, I'm thinking this might be a job for a bit of translation shim within Xwayland. Everything an X client needs either has a Wayland equivalent (through an X server and a little translating XWM shim) or, where forbidden by Wayland, can be stubbed out with a few white lies e.g. "There are no other

Re: Why isn't Xwayland just a Wayland client?

On Wed, 6 Sep 2017 12:11:52 +0200 Olivier Fourdan wrote: > Hi, > > On 6 September 2017 at 11:48, Joseph Burt wrote: > > > To be clear, my first look at how the X11 channel is used in practice > > hasn't yet turned up the justification for its existence. The logic > > usually seems to be "if X

Re: Why isn't Xwayland just a Wayland client?

Hi, On 6 September 2017 at 11:48, Joseph Burt wrote: > To be clear, my first look at how the X11 channel is used in practice > hasn't yet turned up the justification for its existence. The logic > usually seems to be "if X client, send event over X11, else Wayland," > which is redundant. There m

Re: Why isn't Xwayland just a Wayland client?

To be clear, my first look at how the X11 channel is used in practice hasn't yet turned up the justification for its existence. The logic usually seems to be "if X client, send event over X11, else Wayland," which is redundant. There must be something big, since tacking on a X11 channel is a big pr