From: Peter H. <pet...@wh...> - 2012-01-03 00:08:50
|
On Wed, Dec 28, 2011 at 06:15:11PM -0600, Favux ... wrote: > On Wed, Dec 28, 2011 at 5:41 PM, Peter Hutterer > <pet...@wh...> wrote: > > On 29/12/11 06:03 , Favux ... wrote: > >> > >> Fedora 16 and Ubuntu Oneiric no longer support the WizardPen driver so > >> these tablets are on the evdev driver. The Aiptek driver is still > >> available though. The problem we are running into is that pressure > >> doesn't seem to work on the evdev driver. > >> > >> 1) How do we enable pressure for "simple" tablets on the evdev driver? > >> > >> They have either 512 or 1024 pressure levels. The WizardPen driver > >> supported linear pressure for them. From remarks Peter has made I > >> gather the simple tablets are suppose to be on the evdev (2.6) driver > >> for current releases. While the evdev manual tells us how to supply X > >> and Y coordinates, which some of the tablets need, it is silent on the > >> Z-axis. In other words are there Z axis coordinate options we should > >> be using and what are they? > > > > > > evdev doesn't really treat any axes as a special one, it just forwards them. > > pressure is supposed to come from ABS_PRESSURE from the kernel and should > > just be forwarded as-is. Might be worth just running evtest against it to > > get the details. ABS_Z is for d devices that have a true z-axis. > > > > there are no options specific to other axes than x and y though. > > That answers that question then. It is a kernel problem. And evtest > shows nothing for Z other than saying it is there: > Event code 24 (Pressure) > Value 0 > Min 0 > Max 1023 > > >> 2) Does the evdev driver support a tablet mouse in addition to the > >> stylus for these "simple" tablets? > >> > >> The WizardPen driver never supported the tablet mouse some of these > >> tablets have. In fact it made the stylus non-functional so a snippet > >> was needed to block the mouse from the driver: > >> Section "InputClass" > >> Identifier "WizardPen ignore mouse dev class" > >> MatchIsTablet "on" > >> MatchVendor "UC-LOGIC|KYE Systems|Ace Cad" > >> MatchDevicePath "/dev/input/mouse*" > >> Option "Ignore" "yes" > >> EndSection > >> As an aside to Peter: the original version of this snippet was the > >> origin of the famous Driver "" alternate to Option "Ignore". > > > > > > just as a comment there: I don't really understand why the ignore is needed > > here unless you have something generically matching on the device's > > /dev/input/mouse device - that part should be fixed to provide closer > > matching (not that it seems to matter now, just for the future - option > > ignore is a last resort if a default configuration cannot work for one > > specific device) > > OK, for future reference. But I don't see how to do a more specific > match if it is multiplexed. I guess I need to go back and review > Xorg.0.logs where the mouse is blocked. none of the default config files we ship with the drivers should assign a driver to any /dev/input/mouse device (on Linux, anyway), so any such device should claim "No input driver/identifier specified". If it is claimed by a driver, that means that either we ship the wrong files your distribution added some that may be broken or you have some local configuration that's too excessive. > >> Thinking the evdev driver might support the mouse we've tried: > >> Section "InputClass" > >> Identifier "WizardPen-on-evdev mouse class" > >> MatchIsTablet "on" > >> MatchVendor "UC-LOGIC|KYE Systems|Ace Cad" > >> MatchDevicePath "/dev/input/mouse*" > >> Driver "evdev" > >> EndSection > >> But we see "could not open the device /dev/input/mouse1 invalid > >> ioctl". Making me wonder if the problem is due to the kernel driver > >> for these tablets? > > > > > > the /dev/input/mouse devices are a bit different to the /dev/input/event > > devices. they speak ps2 protocol, not the event protocol and the evdev > > driver doesn't understand them at all. if the wizardpen has a mouse device > > like the wacom tablets have, that is either a separate kernel device (thus > > another eventX device) or multiplexed on the same device (through > > BTN_TOOL_*). How are the mouse devices supported? > > While some tablets do have two events listed in 'xinput list', one of > which we were thinking might be the mouse, generally there is only one > event. So multiplexed? That's a question I'm hoping Nick can answer. If you look at the evtest output, the BTN_TOOL_PEN, BTN_TOOL_MOUSE, etc. are the delimiters for multiplexing. The order for stylus down, up and then mouse down/up would be roughly: BTN_TOOL_PEN 1 BTN_TOUCH 1 ABS_X 123 ABS_Y 456 EV_SYN BTN_TOOL_PEN 0 BTN_TOUCH 0 EV_SYN BTN_TOOL_MOUSE 1 BTN_TOUCH 1 ABS_X 472 ABS_Y 282 EV_SYN BTN_TOOL_MOUSE 0 BTN_TOUCH 0 EV_SYN If you can see a sequence like this, then the kernel properly multiplexes it. Cheers, Peter |