Hi Donald, On Thu, Jun 28, 2012 at 10:34 PM, Donald Kayser <linux@xxxxxxxxxx> wrote: > Hi Benjamin, > > >> So: >> 1) between 2.6.34 and 2.6.39, Mosart devices are handled in >> hid-mosart, and since 3.0 through hid-multitouch. Using these drivers >> will allow you to have a better support of your devices. >> However I'm not 100% sure it won't create more than one input device >> if your hardware declares more than one interface. >> >> 2) Using the quirk HID_QUIRK_MULTI_INPUT is the exact opposite of what >> you want to do -> it creates several inputs when it sees several >> touches -> you then have a lot of inputs with unusable stuff. >> > I have returned to this problem today. I've turned off the QUIRK and added > the hid_mosart driver. These devices are new so I added their ID's so the > mosart driver would recognize them. I end up with the same results I had You also have to add your device in the blacklist in hid-core.c. Earlier kernels (< 3.2) do not detect multitouch devices and handle it through the hid-generic layer no matter you assign them to another driver. This blacklist is called hid_have_special_driver in earlier kernels (> 2.6.38) and hid_blacklist in earlier kernels (<= 2.6.37). > before ever trying the QUIRK: the event codes from the device are not ABS_X > and ABS_Y, but ABS_HAT2X and ABS_HAT2Y. These ABS_HAT2? events make it > through the system device files and I can read them using the linux input > API. The problem is that the xorg evdev driver does not process the > ABS_HAT2? events. The QUIRK made the events change to ABS_X and ABS_Y. The > usbhid driver and hid_mosart driver end up giving the same results with > respect to the data being reported via linux input API. Yep, that's because you are not using the hid-mosart driver. When using it, you should see in evtest the events ABS_MT_POSITION_X (and Y) and MT_SYNC IIRC. The good point for you is that the mouse emulation should work, and you can ignore those mt-events. Cheers, Benjamin > >> >> - patch your kernel (> 2.6.35) using the patches here: >> >> http://www.lii-enac.fr/en/architecture/linux-input/multitouch-howto.html#get >> (but I did not tested old kernel releases) -> you will get the same >> input layer for multitouch than a 3.4 kernel (the older the kernel is, >> the more intrusive it is). > > > I am reluctant to patch the kernel we end up qualifying for our systems. It > is an unknown for me trying to deliver a product soon. > > >> - work on an udev rule that detect the physical path, and creates a >> symlink /dev/input/mosart-X > > > This is helpful and made it where I could get the QUIRK solution working > okay. Without the QUIRK there isn't an entry problem in the > /dev/input/by-path directory. > > >> - rely on xorg input rules system to detect your devices (though I >> don't know when they added the physical path in the configuration >> options). > > > > > I have been attempting to get the driver layer to send up ABS_X and ABS_Y so > that evdev would work. I mod'd evdev to process the new events but it got > screwy. I prefer to get the system to send up events that evdev will handle > and I won't have to modify it further. I don't need any kind of multi-touch > capability until the next major revision of our application software, so I > am taking the shortest path to get there. > > Thanks, > Donald > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
