[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