[PATCH] libinput-seat: Don't regard no input devices as failure

[Pekka Paalanen]

On Fri, 02 Jan 2015 13:24:36 +0100
Sjoerd Simons <sjoerd.simons at collabora.co.uk> wrote:

> On Fri, 2015-01-02 at 13:34 +0200, Pekka Paalanen wrote:
> > On Tue, 30 Dec 2014 17:19:45 +0000
> > Daniel Stone <daniel at fooishbar.org> wrote:
> > 
> > > Hi,
> > > 
> > > On 29 December 2014 at 00:03, Peter Hutterer <peter.hutterer at who-t.net>
> > > wrote:
> > > 
> > > > On Sun, Dec 28, 2014 at 11:25:16PM +0100, Sjoerd Simons wrote:
> > > > > The reason for not having any input devices could actually be that there
> > > > > are no input devices attached, imagine that. Mention that cause in the
> > > > > warning and no longer return an error.
> > > > >
> > > > > This fixes starting weston on boards with no input devices attached.
> > > > >
> > > > > Signed-off-by: Sjoerd Simons <sjoerd.simons at collabora.co.uk>
> > > >
> > > > Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
> > > >
> > > > though I'd use "available" over "attached" which is less ambiguous in
> > > > a multi-seat scenario.
> > > >
> > > 
> > > It'd be nice to distinguish between 'devices are available but could not be
> > > opened', and no devices whatsoever. In either case, we made Xorg require an
> > > option (AllowEmptyInput) to start with no devices, and I guess it could be
> > > nice to do the same for weston-launch.
> > 
> > Yes, definitely.
> > 
> > I believe it is a relatively common user error in installation or
> > configuration to not be able to open any input devices when they do
> > exist. 
> 
> Note that the patch is for weston to make the drm backend not simply
> abort.. Not for weston-launch to abort on odd/incorrect configurations.
> So what is suggested here would be for another patch, not a change to
> this one.

I think the note about weston-launch is unintended. Weston-launch is
only a fancy open() function wrt. anything for input.

It would be in weston indeed, and the DRM backend especially - well,
all backends that use the low-level input (libinput).

I think the point of the existing code is very much to exit/abort so
that the user is not left with a seemingly frozen computer.

> > When that happens, the user is left with a completely
> > unresponsive computer, except maybe the ACPI power button for a
> > controlled shutdown. Yes, remote access too, but only if you happen to
> > have it.
> 
> > Some way to avoid that accident by default would be nice. It is in the
> > same fashion as we have some other checks to avoid e.g. "black screen"
> > symptoms and prefer exiting with a message.
> 
> Under the assumption that weston-launch is a tool for developers to
> start weston, then sure fine. If weston-launch gets used to autostart
> weston on bootup (as i'm doing in some cases), that behaviour is
> horrible.

You might want to look into the reasons Weston might exit during or soon
after startup. I would hope they all set the process exit code to some
error, so your init system can eventually give up and fall back.

Also, even weston-launch should be reflecting Weston's process exit
code in its own exit code... hmm, at least it would be nice if it did,
I forget if it actually does.

> Apart from blatent configuration issues there can be a lot of reasons
> why there are no input devices available at the time weston start,
> which can range from devices not being plugged in to devices not being
> enumerated yet (which can potentially happen with USB input devices,
> but are a lot more likely with bluetooth devices).. In those cases
> it's a lot more user-friendly to display an onscreen message indicating
> there are no input devices instead of simply aborting.

Displaying a message would be the minimum for user friendlyness,
agreed. (We do that, except printing to the console doesn't work while
in KD_GRAPHICS, so you need to redirect stderr to see it...) A secondary
but still important target is to restore user's control to the computer,
and for that we need an option whether to quit or not. Then we can argue
whether it should be on or off by default. :-)

Maybe we could have Weston quit, if there are input devices but for
whatever reason none of them can be opened. But, if the user is trying
to configure seats, it is likely to hit a case where there are no input
devices *in the seat*, so that's still a problem.

I suppose we will have the same discussion about outputs, when/if
Weston gains support to run without any connected monitors.


Thanks,
pq