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 < > [email protected]>: > > > 2016-02-11 0:56 GMT-02:00 Peter Hutterer <[email protected]>: > > > >> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
