Bug 73782

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.

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

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.

After some more testing, it seems that it's not giving udev a chance to do its thing.

If I add 
sleep(1);
before
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.

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,
 	                                &new_screen_info);
-	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

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

David Herrmann explains:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/021998.html

Can you solve your problem with that information?

I think this can be closed, I have not replicated this in years (although I am not using weston-launch)

Ok, let's assume it's fixed then. Thanks.