[PATCH kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

Peter Hutterer peter.hutterer at who-t.net
Thu Feb 11 21:35:39 UTC 2016


On Thu, Feb 11, 2016 at 08:23:55AM -0200, LaƩrcio de Sousa wrote:
> 2016-02-11 0:56 GMT-02:00 Peter Hutterer <peter.hutterer at who-t.net>:
> 
> > we don't have a 1:1 mapping between devices and fd (e.g. wacom devices all
> > hang off a single fd). Even the fd itself is a DDX concept, so RemoveDevice
> > cannot close the fd.
> >
> > What should happen here though is that the pDev->public.devicePrivate
> > points
> > to something kdrive understands and that includes the fd.
> >
> Reading kdrive evdev sources, I've found that
> EvdevPtrDisable/EvdevKbdDisable functions
> do have a KdUnregisterFd() call. Example:
> 
> static void
> EvdevPtrDisable(KdPointerInfo * pi)
> {
>     Kevdev *ke;
> 
>     ke = pi->driverPrivate;
> 
>     if (!pi || !pi->driverPrivate)
>         return;
> 
>     KdUnregisterFd(pi, ke->fd, TRUE);
> 
>     if (ioctl(ke->fd, EVIOCGRAB, 0) < 0)
>         perror("Ungrabbing evdev mouse device failed");
> 
>     free(ke);
>     pi->driverPrivate = 0;
> }
> 
> However, it seems to fail in my system, because I always get
> that "Ungrabbing evdev mouse device failed" error message.

I just checked the kernel sources and there is no specific error case that
this code can trigger, it's something to do with the fd itself (EBADF,
EPERM, etc.). I guess fd is already closed/reset by the time you get here.
What errno do you get?

Cheers,
   Peter


More information about the xorg-devel mailing list