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

[Peter Hutterer]

On Thu, Feb 11, 2016 at 04:10:23PM -0200, Laércio de Sousa wrote:
> 2016-02-11 8:23 GMT-02:00 Laércio de Sousa <
> laerciosousa at sme-mogidascruzes.sp.gov.br>:
> 
> > 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'm convincing myself this is more a ploblem with kdrive evdev driver than
> with kdrive itself, so I'm tempted to keep that code in
> DeleteInputDeviceRequest() as is, with a mention that it's a kind of
> "safety measure against buggy drivers". What do you think?

tbh, I think it's easier if we just fix buggy drivers. it's not like we have
that many of them :)

Cheers,
   Peter