On Fri, Oct 28, 2011 at 3:57 AM, Cedric Sodhi <man...@gmx.net> wrote: > On Thu, Oct 27, 2011 at 11:36:43AM -0500, Chris Bagwell wrote: >> Linux tends to require white lists for supported touchscreens. So it >> doesn't matter what drivers you compile it... its OK to compile them >> ALL in and let whichever says it owns that product ID to claim it. >> >> > [ 3.226217] usb 2-1.4: new full speed USB device number 5 using ehci_hcd >> > [>>>>>>>>>>>>] input: eGalax_eMPIA Technology Inc. PCAP MultiTouch >> > Controller as >> > /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/input/input8 >> > [ 3.323466] generic-usb 0003:0EEF:A001.0001: input,hiddev0,hidraw0: USB >> > HID v2.10 Pointer [eGalax_eMPIA Technology Inc. PCAP MultiTouch >> > Controller] on usb-0000:00:1d.0-1.4/input0 >> >> OK, this tells me a little more. Your using the generic HID driver >> which means your settings to disable hid-multitouch, usbtouchscreen, >> etc are not really doing anything. >> >> The reason its using this driver is because, like I mentioned earlier, >> your device has to be white listed to be used by a non-generic driver. >> >> To start with, someone will need to add your new product ID of 0xa001 >> to this file: >> >> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=blob;f=drivers/hid/hid-ids.h;h=1680e99b4816a8558291293d38dcc43625640e9c;hb=HEAD >> >> It needs to be added around line 234. Then it needs to be add to >> white list in the hid-multitouch.c file: >> >> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=blob;f=drivers/hid/hid-multitouch.c;h=fa5d7a1ffa9e97e81a8785a5d96c4f1af59cd47d;hb=HEAD >> >> Look around line 682 for example of registering a resistive eGalax >> touch screen and around line 690 for registering a capacitive. >> >> This all assumes that eGalax has chosen to be a HID Multitouch >> compliant device for this model... probably they did. > > I patched the two files as you suggested and rebuilded, but the lines in > dmesg stay the same, hid-multitouch.ko is not autoloaded and the > behaviour is unchanged.
Darn. I guess that would have been to easy. I've note added an ID yet to hid-multitouch so I may have got it wrong. I'll see if I can find more info. I have an alternate suggestion below. > > evtest (after the changes) shows some things, first it displays > information and then responds to input on the touchscreen. Here is what > is returned when I move the finger on the screen: > > http://paste.pocoo.org/show/499435/ > > === Excerpt: > > Input driver version is 1.0.1 > Input device ID: bus 0x3 vendor 0xeef product 0xa001 version 0x210 > Input device name: "eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller" > Supported events: > Event type 0 (Sync) > Event type 1 (Key) > Event code 256 (Btn0) > Event code 272 (LeftBtn) > Event code 273 (RightBtn) Yes, this is were things go wrong. It should not be declaring LeftBtn or RightBtn. This shows its kernel bug. User land is working correctly based on the information supplied to it. > Event code 325 (ToolFinger) > Event code 330 (Touch) > Event type 3 (Absolute) > Event code 0 (X) > Value 16944 > Min 0 > Max 32767 > Event code 1 (Y) > Value 7536 > Min 0 > Max 32767 > Event code 2 (Z) > Value 0 > Min 0 > Max 4095 > Event code 3 (Rx) > Value 0 > Min 0 > Max 4095 > Event code 40 (Misc) > Value 0 > Min 0 > Max 16 > Event type 4 (Misc) > Event code 4 (ScanCode) > > Testing ... (interrupt to exit) > Event: time 1319790961.425975, type 4 (Misc), code 4 (ScanCode), value d0042 > Event: time 1319790961.425977, type 1 (Key), code 330 (Touch), value 1 > Event: time 1319790961.425979, type 1 (Key), code 325 (ToolFinger), value 1 > Event: time 1319790961.425989, type 3 (Absolute), code 0 (X), value 18048 > Event: time 1319790961.425993, type 3 (Absolute), code 1 (Y), value 3744 > Event: time 1319790961.425994, -------------- Report Sync ------------ > Event: time 1319790961.431023, type 3 (Absolute), code 1 (Y), value 3728 > > === > >> >> > >> > Kernel is 3.1.0 mainline. >> >> OK. The kernel is new enough. Just needs some modifications to >> understand your ID. > > The ones which I just tried? > Yes. >> >> Used to, this driver contained binary blobs and also required an >> >> xf86-input-egalax to work with it. I've not used it in maybe 3 years >> >> though with a now dead egalax touchscreen. >> >> >> >> Most egalax hardware is supported by standard linux kernel + standard >> >> xf86-input-evdev. Not sure of this exact hardware issue. >> >> >> >> I quickly found this bug report that says it is reporting itself as a >> >> touchpad which would explain why its not working correctly with >> >> xf86-input-evdev. It doesn't go into very much detail on the why its >> >> reporting that way or what kernel driver its using. > > Indeed. When I last mentioned it I said that it *certainly* is absolute. > Which still holds: It is absolute AND configured as a touchpad - I can't > even tell whether that combination makes any sense. It can be seen in > the Xorg.0.log, which I provided with the last email: > > (--) ... MultiTouch Controller: Found abolute axes > ... > (II) ... MultiTouch Controller: Configuring as touchpad > Yes. That is definition of a touchpad. A touchpad is a device that report absolute coordinates but that you want to be treated like a mouse and give relative movement. > Just as the thread on Ubuntu Forums describes it. So I applied their > "patch" to evdev, and it works, at least the basics (clicking and > dragging)! That's pretty good already. > >> OK, it helps a little. It would be better if I saw output of "evtest" >> when you point at this device so I can see what all it declares it >> supports. >> >> But from past experience I think I know the issue. eGalax in the past >> has declared 2 interfaces on the one USB device. One is mouse-like >> and one is touchscreen-like. >> >> When you use the generic HID driver, it merges the two interfaces into >> a single interface which then confuses xf86-input-evdev into thinking >> you have a a hybrid touchpad. >> >> One option is to still use the generic HID driver but tell it about >> this quirk. You still need to define the product ID as above and then >> modify this file: >> >> http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=blob;f=drivers/hid/usbhid/hid-quirks.c;h=4ea464151c3be0d53de577b0aec833136a5d85b5;hb=HEAD >> >> Look around line #36. Its example of quirk on my old single touch >> eGalax touchscreen that had this same issue. Once adding in this line >> and recompiling kernel, I could use my touchscreen with >> xf86-input-evdev just fine. Since the hid-multitouch didnt work, can you please try above instead? This is patching the generic-usb driver. It should allow working with evdev without modifications with same behavior... you'll get an extra unused /dev/input device out of it that contains those unwanted LeftBtn/RightBtn's. >> >> The reason eGalax out-of-tree driver works is because they do that >> similar quirk in their driver. Of course, going the hid-multitouch >> route is going to be much more enjoyable in the end... and it has some >> similar logic to understand multiple interfaces but without defining >> it as a quirk. > > According to my experiments I did not get hid-multitouch to work, as you > described it. We may need to move over the linux-input list to get hid-multitouch working but it would be best if you can first verify generic-usb will start working with above 1 line modification. It will speed things along with that info. Also, you may wish to start exploring the /sys/kernel/debug/hid directory to see what your USB HID is reporting. You may need to do a "mount -t debugfs none /sys/kernel/debug" if your distro doesn't automatically do that. > > I received a reply from Timmy Cheng at EETI. I'm not sure whether he > would appreciate my forwarding the whole tarball to you, but I will at > least forward you the eGalax eGTouch Programming Guide for Linux PDF, in > a separate e-mail. Yeah, I've seen a version of that document before. Its badly named. Its not a Programming Guide. Its a guide on how to set up your kernel so that the open source drivers will not load so that you can then use their binary blobs. Not much help here. Chris > > Thank you guys, you are truly awesome! Couldn't have hoped for better > help! > > -- > regards, ManDay > ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
