[PATCH xf86-input-evdev] Print cause of a failed open(..) call

[Peter Hutterer]

On Wed, Jan 31, 2018 at 08:41:33AM +0100, Christian Gmeiner wrote:
> 2018-01-30 4:39 GMT+01:00 Peter Hutterer <peter.hutterer at who-t.net>:
> > On Wed, Jan 24, 2018 at 01:19:10PM +0100, Christian Gmeiner wrote:
> >> This is quite helpful for debugging.
> >>
> >> Signed-off-by: Christian Gmeiner <christian.gmeiner at gmail.com>
> >> ---
> >>  src/evdev.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/evdev.c b/src/evdev.c
> >> index cffed7f..84d50c8 100644
> >> --- a/src/evdev.c
> >> +++ b/src/evdev.c
> >> @@ -2453,7 +2453,7 @@ EvdevOpenMTDev(InputInfoPtr pInfo)
> >>      if (pEvdev->mtdev)
> >>          pEvdev->cur_slot = pEvdev->mtdev->caps.slot.value;
> >>      else {
> >> -        xf86Msg(X_ERROR, "%s: Couldn't open mtdev device\n", pInfo->name);
> >> +        xf86Msg(X_ERROR, "%s: Couldn't open mtdev device (%s)\n", pInfo->name, strerror(errno));
> >
> > this one won't work. I just had a look at the mtdev sources and it doesn't
> > preserve the errno. So the best you can do on a failed mtdev_new_open() is
> > shrug and move on. I've removed this hunk from the patch and pushed the rest
> > as 192fdb0..ab1d9ad  master -> master
> >
> > Thanks
> >
> > Cheers,
> >    Peter
> 
> Thanks for pushing!
> 
> Now I need to find out why the open call failed at random boots.
> 
> [ 34.103] (II) Using input driver 'evdev' for 'ar1021 I2C Touchscreen'
> [ 34.103] (**) ar1021 I2C Touchscreen: always reports core events
> [ 34.103] (**) evdev: ar1021 I2C Touchscreen: Device: "/dev/input/event0"
> [ 34.180] (EE) evdev: ar1021 I2C Touchscreen: Unable to open evdev
> device "/dev/input/event0" (No such device or address).
> [ 34.180] (EE) PreInit returned 2 for "ar1021 I2C Touchscreen"

hmm, I just noticed there's a case where if the server_fd flag is set but
the fd is -1, we'll use a wrong errno. Shouldn't happen in your case
(especially the ENODEV is awfully convenient for a random errno) and I'm not
sure that can actually happen anyway.

But what's going on in your case is hard to guess, I'd have to see the whole
log. Is this coming from udev?

Cheers,
   Peter