Bug 73782 - Weston called from weston-launch loses permission to uaccess fb devices on tty switch back
Summary: Weston called from weston-launch loses permission to uaccess fb devices on tt...
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
Depends on:
Reported: 2014-01-19 03:01 UTC by nerdopolis1
Modified: 2017-08-10 11:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Weston log from running on a uaccess permissions fb device, and to a different tty and back (5.56 KB, text/plain)
2014-01-19 03:01 UTC, nerdopolis1
Full backtrace of switching away from and back to a weston server using fbdev when uaccess is enabled (8.00 KB, text/plain)
2014-11-11 18:12 UTC, nerdopolis1

Note You need to log in before you can comment on or make changes to this bug.
Description nerdopolis1 2014-01-19 03:01:18 UTC
Created attachment 92369 [details]
Weston log from running on a uaccess permissions fb device, and to a different tty and back


I have configured my framebuffer devices with udev to have uaccess, similar to how it sets up /dev/dri/card* devices

I added this line to my udev config:
SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"

I am able to start Weston sessions fine on this configuration. 

but when I switch to a different tty, and then switch back, it seems the permissions to /dev/fb0 are lost and Weston dies.

I am using Ubuntu, which means, I am using the limited logind. And I am calling my user sessions from weston-launch.

If I'm really careful, I can switch tty without crashing with 
'loginctl activate', but once I switch TTYs, All instances of weston lose permission to /dev/fb0 once I switch to them, even if the next way is with loginctl activate.

It seems to work with /dev/dri/card* and /dev/input/event*, so it should work with /dev/fb* I would assume?

I have a log of a Weston crash attached.
Comment 1 Pekka Paalanen 2014-01-20 07:38:58 UTC
The difference here is that weston-launch (a setuid-root helper process) is used to open DRM and input devices, but does not support opening legacy fb devices AFAICT. The fbdev backend opens the fb device itself.

However, I am unsure what would be the right fix for the real issue of opening /dev/fb - let weston-launch open it, or is there some race during VT switching that could be fixed?

The very least weston should deal gracefully with the failure instead of segfaulting.
Comment 2 nerdopolis1 2014-11-11 14:54:19 UTC
It's been while since I was last able to try this, sorry about the long delay, but now it still seems to do the same thing.

The problem isn't that uaccess doesn't work at all, as I am able to start Weston without changing permissions when I set.
SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"

I then am able to start Weston as another user on another TTY too.

The problem is when I switch back to the original TTY of the first Weston server it seems to not handle the fact that it had previously lost permissions, and dies once I switch back to its tty.

This doesn't need weston-launch to do it, as it's logind that is setting the device permissions. And I think it even revokes existing access when switching to another user.

Should it try to reopen the framebuffer device?

Full stack trace to come
Comment 3 nerdopolis1 2014-11-11 18:12:47 UTC
Created attachment 109294 [details]
Full backtrace of switching away from and back to a weston server using fbdev when uaccess is enabled

This is the back trace of when I don't set any manual permissions on /dev/fb0, and instead give it uaccess permissions with udev. Weston seems to not try to reconnect with the framebuffer device, as it works until I switch ttys, and then try to switch back.
Comment 4 nerdopolis1 2014-12-11 02:33:55 UTC
After some more testing, it seems that it's not giving udev a chance to do its thing.

If I add 
fb_fd = fbdev_frame_buffer_open(output, output->device, &new_screen_info);
in fbdev_output_reenable

it seems I can get it to work.

To me this is a hackish kind of fix, and probably not an acceptable fix to be merged, but I hope this finding is helpful.
Comment 5 nerdopolis1 2015-01-18 04:07:26 UTC
This is the best workaround I can come up with.
I have it loop, because if fbdev_output_reenable is being called, and it's failing to open the framebuffer device, it's probably because it's waiting for udev to put permissions on the file again, assuming permissions to the framebuffer device is granted with
SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"
in a udev rules file

It's probably not merge worthy though?

diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 138aaab..7ebbe92 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -726,11 +726,14 @@ fbdev_output_reenable(struct fbdev_compositor *compositor,
 	weston_log("Re-enabling fbdev output.\n");
 	/* Create the frame buffer. */
-	fb_fd = fbdev_frame_buffer_open(output, output->device,
+	fb_fd = -1;
+	while (fb_fd < 0) {
+		usleep(10000);
+		fb_fd = fbdev_frame_buffer_open(output, output->device,
-	if (fb_fd < 0) {
-		weston_log("Creating frame buffer failed.\n");
-		goto err;
+		if (fb_fd < 0) {
+		  weston_log("Creating frame buffer failed.\n");
+		}
 	/* Check whether the frame buffer details have changed since we were
Comment 6 nerdopolis1 2015-03-07 19:51:39 UTC
Could anyone think of a better fix, or should I attempt to send my workaround patch to the mailing list.

keep in mind to reproduce this issue, you need to add a 
SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"
line to a /lib/udev/rules.d/ file

(and not manually grant the user permissions to the framebuffer)
and then switch ttys back and forth
Comment 7 Pekka Paalanen 2015-05-15 14:05:16 UTC
David Herrmann explains:

Can you solve your problem with that information?
Comment 8 n3rdopolis 2017-08-04 01:38:19 UTC
I think this can be closed, I have not replicated this in years (although I am not using weston-launch)
Comment 9 Pekka Paalanen 2017-08-10 11:20:31 UTC
Ok, let's assume it's fixed then. Thanks.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.