[PATCH] compositor-fbdev: Wait and retry before failing on reconnect to the framebuffer

[Pekka Paalanen]

On Fri, 15 May 2015 18:42:32 -0400
nerdopolis <bluescreen_avenger at verizon.net> wrote:

> On Friday, May 15, 2015 12:30:30 PM David Herrmann wrote:
> > Hi
> > 
> > On Fri, May 15, 2015 at 8:39 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > >
> > > On Wed, 13 May 2015 21:43:39 -0400
> > > nerdopolis <bluescreen_avenger at verizon.net> wrote:
> > >
> > > > Resolving https://bugs.freedesktop.org/show_bug.cgi?id=73782
> > > > udev might be configured to set the permissions on framebuffer devices with the UACCESS attribute.
> > > > Weston currently attempts to reconnect to the framebuffer device before udev can set the permissions back.
> > > >
> > > > It waits 3 times in case if the system is heavily paging, or slowed down, and prevents udev from working.
> > > > In my testing the delay is long enough where it works on the first try

> > systemd-logind listens to VT events via poll(2) on
> > /sys/class/tty/tty0/active. On VT switches it changes ACL permissions
> > on dev-nodes underneath /dev, if the 'uaccess' tag is set on a device.
> > But it cannot delay a VT-switch, it just reacts to it.
> > 
> > It is inherent to this approach, that the permissions are set _after_
> > the VT switch. Therefore, there's a race and I guess it's what is hit
> > here. However, systemd-logind sends out dbus signals after it fully
> > changed the permissions. Hence, if you rely on the 'uaccess'
> > functionality by systemd, then you better also use the systemd APIs
> > (either sd_login_monitor_new() or DBus). If you don't want to use the
> > systemd APIs, then you cannot rely on 'uaccess' (i.e., you have to set
> > static group/user permissions on your device nodes; it will not
> > interfere with 'uaccess', logind allows both in parallel).
> > 
> > Long story short: Please run weston directly (_without_ weston-launch,
> > instead directly invoking weston from within a logged-in VT), with
> > systemd support compiled it. It should work fine with 'uaccess'. If
> > you don't have systemd support compiled in, please use static access
> > permissions.
> > 
> > Thanks
> > David
> 
> It seems that I am a bit mistaken. My scripts used to call Weston using weston-launch, and then I configured fbdev for uaccess permissions, and stopped setting static permissions.
> I created the workaround locally... Then later on I updated my login script manager to not use weston-launch anymore, and call systemd enabled login sessions on TTYs with runuser... 
> 
> I didn't bring it upstream until now, because I wasn't sure if it was actually a good way to fix it... 
> 
> I actually haven't tested it with _vanilla_ weston until now. Removing my patch and tty switching with /dev/fb0 set with UACCESS, with --backend=fbdev-backend _without_ weston-launch does *not* cause a crash... I called weston directly, and tty switched fine on fbdev.
> 
> However, It still fails under weston-launch even when compiling against systemd. TTY switching results in the race condition, and Weston crashes. But now most systems, should have systemd >v209, and to use that. 
> There still might be the possibility that users might want the UACCESS attribute on /dev/fb* , on a non systemd system, or are <v209 (I.E: existing Ubuntu LTS versions), on systems that don't support kernel mode setting?
> 

We still haven't merged some refactoring patches from Jasper, I'd like
to deal with those before this.

Personally I'm ok with weston-launch requiring static permissions on
fbdev, until more people come complaining about it. Weston-launch with
fbdev is hopefully rare enough configuration that it doesn't really
matter. Fbdev in itself is already a fallback/compatibility/secondary
platform.


Thanks,
pq