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

[David Herrmann]

Hi

On Fri, May 15, 2015 at 4:44 PM, Derek Foreman <derekf at osg.samsung.com> wrote:
> On 15/05/15 05:30 AM, David Herrmann wrote:
>> 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.
>
> Does this mean weston-launch is always the wrong thing to do if systemd
> support is compiled in?

If systemd is running, weston-launch should probably execve() 'weston'
directly without setting up WESTON_LAUNCHER_FD.

> ie) should we refuse to build weston-launch if systemd support is enabled?

This should be a run-time detection, not build-time, imho.

Thanks
David