hid: egalax 0x0eef:0x0001 no longer detected by hid-multitouch

hid: egalax 0x0eef:0x0001 no longer detected by hid-multitouch

[Sebastian Dalfuß]

Dear Maintainers,

In 3.6.x the egalax touch panel (Vendor: 0eef, Dev: 0001) worked 
perfectly well with hid-multitouch, right out of the box. In 3.9 and 
3.10 it doesn't; the panel doesn't show up in /proc/bus/input/devices .
If the module usbtouchscreen is present, 3.9/3.10 wrongly try to use 
that one (flipped y-axis, wrong scale, get's stuck) instead of 
hid-multitouch(worked previously perfectly well, no need for 
calibration, quirks, configuration). If usbtouchscreen isn't present, 
the panel isn't detected, even if hid-multitouch gets poked with appropriate
parameters in /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id .
In an desperate attempt, I manually added the device/vendor id to
hid-multitouch.c, which didn't yield any improvement. It seems that the hid
subsystem doesn't even recognize that this device is indeed a hid 
touchpanel.

Is there a way to force hid to take care of that vendor/device-id, as a
temporary workaround?

This issue is also filed in Bugzilla: 
https://bugzilla.kernel.org/show_bug.cgi?id=60816

lsusb-snippet:
https://bugzilla.kernel.org/attachment.cgi?id=107362

Greetings,
Sebastian Dalfuß
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: hid: egalax 0x0eef:0x0001 no longer detected by hid-multitouch

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]

Hi Sebastian,

On Fri, Aug 30, 2013 at 07:59:46PM +0200, Sebastian Dalfuß wrote:
> In 3.6.x the egalax touch panel (Vendor: 0eef, Dev: 0001) worked 
> perfectly well with hid-multitouch, right out of the box. In 3.9 and 
> 3.10 it doesn't; the panel doesn't show up in /proc/bus/input/devices .
> If the module usbtouchscreen is present, 3.9/3.10 wrongly try to use 
> that one (flipped y-axis, wrong scale, get's stuck) instead of 
> hid-multitouch(worked previously perfectly well, no need for 
> calibration, quirks, configuration). If usbtouchscreen isn't present, 
> the panel isn't detected, even if hid-multitouch gets poked with appropriate
> parameters in /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id .
> In an desperate attempt, I manually added the device/vendor id to
> hid-multitouch.c, which didn't yield any improvement. It seems that the hid
> subsystem doesn't even recognize that this device is indeed a hid 
> touchpanel.

That's probably this:

commit 729b814acec20db66fc891b5392cb653ad6598ef
Author: Forest Bond <forest.bond@rapidrollout.com>
Date:   Tue Nov 6 13:41:22 2012 -0500

    HID: Ignore D-WAV/eGalax devices handled by usbtouchscreen
    
    Previously, both usbhid and usbtouchscreen would bind to D-WAV devices
    with class HID and protocol None, so they would be claimed by whichever
    driver was loaded first.  Some of these devices do in fact work with
    usbhid, but not all of them do.  OTOH they all work with usbtouchscreen
    as of commit 037a833ed05a86d01ea27a2c32043b86c549be1b ("Input:
    usbtouchscreen - initialize eGalax devices").  So we ignore them in
    usbhid to prevent getting in the way of usbtouchscreen and claiming an
    interface that we may not be able to do anything useful with.
    
    Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

The primary issue is that 0eef:0001 has been repeatedly re-used for a wide
variety of devices and as such cannot be meaningfully used on its own to select
a driver.  Some of these devices have class HID and worked fine with
usbtouchscreen.  When usbhid was introduced they stopped working because they
don't actually work with the HID driver.

Historically this is dealt with by submitting a patch that regresses everyone
else's screens but makes yours work better. ;)

So we need to figure out how to handle these devices.  I need to dig out the
screen I have that did not work with the HID driver and test it again.  Might
take some time for me to get to this.

> Is there a way to force hid to take care of that vendor/device-id, as a
> temporary workaround?

For now look at hid_ignore in hid-core.c.  You can probably set
HID_QUIRK_NO_IGNORE to work around the problem.  You'll probably also want to
blacklist usbtouchscreen.

Hope this helps.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: hid: egalax 0x0eef:0x0001 no longer detected by hid-multitouch

[Sebastian Dalfuß]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

Hi Forest,

On Fri, Aug 30, 2013 at 02:45:02PM -0400, Forest Bond wrote:
> For now look at hid_ignore in hid-core.c.  You can probably set
> HID_QUIRK_NO_IGNORE to work around the problem.  You'll probably also want to
> blacklist usbtouchscreen.

That helped indeed.

Changing

        case USB_VENDOR_ID_DWAV:
                /* These are handled by usbtouchscreen. hdev->type is probably
                 * HID_TYPE_USBNONE, but we say !HID_TYPE_USBMOUSE to match
                 * usbtouchscreen. */
                if ((hdev->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER ||
                     hdev->product == USB_DEVICE_ID_DWAV_TOUCHCONTROLLER) &&
                    hdev->type != HID_TYPE_USBMOUSE)
                        return true;
                break;

to

        case USB_VENDOR_ID_DWAV:
                /* These are handled by usbtouchscreen. hdev->type is probably
                 * HID_TYPE_USBNONE, but we say !HID_TYPE_USBMOUSE to match
                 * usbtouchscreen. */
                if (hdev->product == USB_DEVICE_ID_DWAV_TOUCHCONTROLLER &&
                    hdev->type != HID_TYPE_USBMOUSE)
                        return true;
                break;

did the trick.
I also commented the dev id in usbtouchscreen.c out.

//      {USB_DEVICE(0x0eef, 0x0001), .driver_info = DEVTYPE_EGALAX},

Thanks,
Sebastian Dalfuß

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]