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

[Laércio de Sousa]

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?


-- 
*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...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160211/713b6541/attachment.html>