[PATCH kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)
Laércio de Sousa
laerciosousa at sme-mogidascruzes.sp.gov.br
Thu Feb 11 18:10:23 UTC 2016
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
>> cannot close the fd.
>> What should happen here though is that the pDev->public.devicePrivate
>> 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)
> KdUnregisterFd(pi, ke->fd, TRUE);
> if (ioctl(ke->fd, EVIOCGRAB, 0) < 0)
> perror("Ungrabbing evdev mouse device failed");
> 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?
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg-devel