[PATCH] logind: delay wakeup until DRM-device is resumed

[David Herrmann]

Hi

On Tue, Dec 3, 2013 at 10:42 PM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Sat, Nov 30, 2013 at 2:25 AM, David Herrmann <dh.herrmann at gmail.com> wrote:
>> The logind API was designed to allow any kind of devices and any number of
>> devices. It has no idea of "main DRM device" or similar. However, the
>> weston DRM backend was designed with a single DRM device as master.
>> Therefore, we wake it up unconditionally on session-wakeup. But this may
>> fail with logind as a session may be awake, but not all devices have been
>> resumed, yet.
>>
>> Therefore, we change the weston-logind backend to deal with this case
>> correctly. Instead of waking up the compositor on session-wakeup, we wait
>> for the main DRM device to wake up. Once we get the event, we notify the
>> compositor.
>>
>> For sleep, we reverse this logic. On *any* of the following events we
>> tell the compositor to go to sleep:
>>  - Session gets inactive
>>  - DRM device gets inactive
>>  - DRM device is removed
>> This guarantees, that weston is only active if *both*, the session and the
>> main DRM device are awake/active.
>>
>> Note that we could actually rely solely on the DRM-device Pause/Resume
>> events from logind and drop all the Active-Prop-Changed handling. logind
>> guarantees proper ordering of both. However, in case we ever change weston
>> to support multiple GPUs, we need the per-device notification. Thus, keep
>> the code. This also makes weston more fail-safe in case logind fails to
>> send the PauseDevice event (for whatever reason..).
>
> This explains the intermittent pageflip failures I was seeing.  The
> patch makes sense and makes VT switching work almost reliably.  The
> one missing thing is that occasionally my pointer doesn't work.  It
> looks like it remains locked by the X driver, and since it's only my
> touchpad (keyboard always works) I'm guessing it's a
> xf86-input-synaptics problem.  It happens with weston-launch too, but
> it doesn't look like a race. I can reproduce with just VT switching
> from X to a VT and running evtest.  That is, the device remains locked
> long enough for me to type evtest, select the device and then see the
> "Device is grabbed..." message.  It doesn't get ungrabbed until I VT
> switch back to X and then back to the VT.
>
> At this point I'm calling it a synaptics bug and merging your patch.

You can set: Option "GrabEventDevice" "no"
in the synaptics xorg config, btw. I tried reading through the
synaptics code but couldn't find anything related to that bug. Hmm..
but I'm not really familiar with the xinput drivers code base..

Thanks for merging! Now everything should be in-place of the logind
work. A bunch of changes for CONFIG_VT=n will be needed, but I'm
working on that.
David