2016-02-11 8:23 GMT-02:00 Laércio de Sousa <
laercioso...@sme-mogidascruzes.sp.gov.br>:
> 2016-02-11 0:56 GMT-02:00 Peter Hutterer <peter.hutte...@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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
