This allows the fbdev backend to run on, and use devices from the
specified seat, similar to the drm backend.
---
compositor/main.c| 2 ++
libweston/compositor-fbdev.c | 10 +-
libweston/compositor-fbdev.h | 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/
As only seat0 supports TTYs, this changes the logind launcher where
it detects a TTY, only if the seat is seat0. This has only been
tested for logind
---
libweston/launcher-logind.c | 22 --
libweston/launcher-util.c | 4
2 files changed, 16 insertions(+), 10 deletions(
The framebuffer backend now detects the framebuffer device
dynamically. Don't assume that the framebuffer device is /dev/fb0
---
compositor/main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/compositor/main.c b/compositor/main.c
index ecd034b9..02de108b 100644
--- a/compositor/main.c
+++
This will allow the seat to be set by the environment as pam_systemd typically
sets the XDG_SEAT variable
---
compositor/main.c | 2 +-
libweston/compositor-drm.c | 5 +
man/weston-drm.man | 7 +--
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/compositor/
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
These patches make Weston handle multiple seats. Fixes from the last
attempt include updating fbdev_set_screen_info , updating some fuzz,
and making the selection of the framebuffer device similar to
compositor-drm.c by favoring the boot_vga device, and making
requested changes
nerdopolis (6):
This adds a function to detect the first framebuffer device in the
current seat. Instead of hardcoding /dev/fb0, detect the device
with udev, favoring the boot_vga device, and falling back to the
first framebuffer device in the seat if there is none. This is very
similar to what compositor-drm does
On Tue, 2018-01-23 at 10:15 +, Daniel Stone wrote:
> Ooh. serialNumber == 1 means it's the root pixmap, which will actually
> be uselessly empty. It would be interesting to see how we've ended up
> here: it would have to be a top-level window which a) was manually
> redirected by the WM when i
On Wed, 20 Dec 2017 12:26:36 +
Daniel Stone wrote:
> Pull this into a helper function, so we can use it everywhere.
>
> Signed-off-by: Daniel Stone
> ---
> libweston/compositor-drm.c | 157
> +
> 1 file changed, 88 insertions(+), 69 deletions(-)
On Wed, 20 Dec 2017 12:26:35 +
Daniel Stone wrote:
> Rather than a hardcoded ARGB -> XRGB translation inside a
> GBM-specific helper, just determine whether or not the view is opaque,
> and use the generic helpers to implement the format translation.
>
> Signed-off-by: Daniel Stone
Hi Daniel,
On Tue, Jan 23, 2018 at 11:15 AM, Daniel Stone wrote:
> Ooh. serialNumber == 1 means it's the root pixmap, which will actually
> be uselessly empty. It would be interesting to see how we've ended up
> here: it would have to be a top-level window which a) was manually
> redirected by t
On Wed, 20 Dec 2017 12:26:34 +
Daniel Stone wrote:
> Add support for using the atomic-modesetting API to apply output state.
> Unlike previous series, this commit does not unflip sprites_are_broken,
> until further work has been done with assign_planes to make it reliable.
>
> Signed-off-by:
Hi,
On 23 January 2018 at 09:42, Olivier Fourdan wrote:
> On 22 January 2018 at 19:57, Adam Jackson wrote:
>> That can't really be the problem. X drawables are never 0x0.
>
> Yeap, I don't know how we end with a pximap of size 0×0:
>
> [...]
> (gdb) f 7
> #7 xwl_glamor_pixmap_get_wl_buffer (pix
Hey Adam,
On 22 January 2018 at 19:57, Adam Jackson wrote:
> On Thu, 2018-01-18 at 11:41 +0100, Olivier Fourdan wrote:
> > This is a rare occurrence of a crash in Xwayland for which I don't have
> > the reproducing steps, just a core file.
> >
> > The backtrace looks as follow:
> >
> > [...]
>
14 matches
Mail list logo
