On Friday 23 February 2007 09:26, Pablo Giménez wrote: [...] > > I am looking into support for true hotplug of wacom tablets for the next > > release from Xorg (7.3), and there are a few things that needs to be > > changed in our driver if that should work as we want. *Maybe* those > > changes can help in this case. When I look at the code I doubt it, but > > there's always a possibility.. > > Maybe is a problem in the X side. > I can guess that the problem is related to open/close the wacom device. > Maybe when you first enter your session the new Xsession opens the > wacom device, take the ownership of it. When you change the new > session do the same, here is my doubh, why? it can happen. If the > second user can access to a previously opened wacom device and take th > eownership, the it will be logicla that when you return to your > previous session you can again open the wacom device. > I am not a kernel or device driver expert so maybe I am complitely in > a mistake.
Mmmm... You're basically correct. When the wacom X-driver opens the wacom device (/dev/input/eventX) is has to GRAB the device to prevent the underlying hardware from sending the movment information to /dev/input/mice [1] (that's why you can use the tablet even if you haven't defined an InputDevice specifically in X for it). If the driver doesn't do this, movement information will come from two different channels and X will be confused. Mostly this will manifest itself in very strange behaviour in programs that uses the extended information the devices defined for the tablet can provide (gimp and other paint programs mostly). So, the first X-server open and grab the device. When the second server starts it switches to a different VT and this causes the X-server to close the wacom device so the second X-server can open and grab it. So far no problem. But when you switch back to the first X-server this doesn't happend in a proper way for some reason and this causes the lack of movment of the cursor in that X-server when you use it. This is about as far as I got last time I looked on it. Hope it helps the understanding what might go on beneath the hood. If anybody has more information that could help us fix this in the ordinary driver I'd be very happy. The /dev/input/eventX devices only allows one process to GRAB the device at any given time. My device will allow multiple processes to GRAB the device at the same time. The only thing the GRAB will do is to prevent the underlying hardware to send the movement information to the /dev/input/mice device as well. This is the only difference in the behaviour of the two device drivers.. Maybe it is possible to skip the GRAB part for the X-driver once the hotplug has made it's way into the X-server (and we have fixed the support for it) as it doesn't need to listen to /dev/input/mice anymore (it can use one of the specific mouse-devices instead). I've seen arguments for keeping it though so we'll have to wait and see what will happend. Cheers Magnus V [1] /dev/input/mice is a hack in the kernel to make it possible for the X-server to support hutplug of USB, PS/2, ... mice, tablets, etc in the current releases of X. It aggregates all mouse devices into one device which is always present and can always be opened. Adding a mouse will therefore only add a driver that will send information through this device as well as it's own mouseX-device. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss
