On Fri, Dec 30, 2011 at 2:45 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > On Fri, Dec 30, 2011 at 2:21 PM, Mike Rolland <none...@gmail.com> wrote: >> Le vendredi 30 décembre 2011 à 11:37 -0600, Chris Bagwell a écrit : >> >>> * Run "dmesg | grep ASUSTek" and look for line telling if kernel >>> driver has been installed for this device. >> >> [root@hpm mike]# dmesg | grep ASUSTek >> usb 2-1.2: Manufacturer: ASUSTek Computer, Inc. >> input: ASUSTek Computer, Inc. Eee Note Digitizer as >> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input14 >> generic-usb 0003:0B05:179F.0002: input,hiddev0,hidraw1: USB HID v1.10 Mouse >> [ASUSTek Computer, Inc. Eee Note Digitizer] on usb-0000:00:1d.0-1.2/input0 > > OK, this is the part I want to concentrate on. That USB HID v1.10 > Mouse part means its probably being reported to userland as a strange > mouse+pen combo device. Its related to the HID report for digitizer > declaring a mouse (required by Microsoft for tabletPC's I think even > if its not really used). > > To better see what kernel is doing, you'll need to install the > "evtest" app from your distro's repo. Run it as root and from a > console (not from X) or it will hide some stuff from you. > > evtest /dev/input/eventtX <--- The value for X is usually found from > trail and error. > > Please send what this displays. You can pipe to a file as well > (evtest /dev/input/eventX > log). > >> >>> I googled for this USB ID and got one result where it said its being >>> detected as a generic HID Mouse. This would not be a good thing and >>> all your work in xf86-input-wacom or xf86-input-evdev will be in vain >>> until kernel side issue is resolved. >> >> Not really sure about that. >> Often the problem comes only from XF86 driver, but like I told to Favux, I >> will have a look to wacom dev kernel libs. The first time I made my homebrew >> with my WALTOP tablet, I remember I change something in kernel driver. So... > > In last year, I think problem areas have moved. xf86-input-wacom and > xf86-input-evdev have become quite stable for new > digitizers/tabletPC's and touchscreens without modifications. The > issues are almost always in kernel now for new hardware. > > I see people go to great lengths though to hack up xf86-input-* > instead of fixing the real kernel side issue and try to ignore that > invalid mouse information. > > When we see the mouse+touchscreen issue in recent times, the cure is > to get the hid-multitouch driver to control the touchscreen. > > In your case, its a mouse+pen so I'm not sure what driver its supposed > to be routed to. If the Asus web page that Favux is to be trusted, > its a Wacom digitizer and so maybe it should be handled by wacom > driver. I have seen Wacom commonly use 0x81 as Endpoint address for > PEN's so thats a good sign. > > I'd try the hint given by Favux and update the file wacom_wac.c from > input-wacom package to understand Eee product ID's.
If the vendor ID is not Wacom or Lenovo, you most likely need to update hid-core.c to add the new vendorID to the black/ignore list. Otherwise, the HID/mouse driver will always pick up the device before we (wacom.ko) even get to it. Ping ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
