This adds a function to detect the first framebuffer device in the
current seat. Instead of hardcoding /dev/fb0, use udev to find the
first framebuffer device in the seat.
---
libweston/compositor-fbdev.c | 45 +---
1 file changed, 42 insertions(+), 3 deleti
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/
---
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
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(
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
On Fri, Nov 17, 2017 at 2:22 AM, Pekka Paalanen wrote:
> On Tue, 14 Nov 2017 12:23:55 -0600
> Matt Hoosier wrote:
>
>> From: Matt Hoosier
>>
>> In order to support system compositor instances, it is necessary to
>> allow clients' wl_display_connect() to find the compositor's listening
>> socket
Hi pq,
Thank you for your response.
> However, weston_matrix *is* using float instead of double. Is that the
> problem?
No. according to your analysis, it does not seem to be the cause of the this
problem.
> During animations and any transformations that apply scaling, it is
> expected that the