Hi Benjamin, I have tested some more kernel versions. The first version, I could use the hid-multitouch module after adding my device to the blacklist of usb-core.c, was 2.6.38. Using the new_id mechanism I have then triggered hid-multitouch to use my device. I tested every version from 2.6.38 over 2.6.39 to 3.6.
commit 5519cab477b61326963c8d523520db0342862b63: Driver crashes at the moment I use the new_id mechanism. 2.6.38-3.0: The device is responsive after reboot, without any additional action on my side. 3.1-3.5: After unloading/reloading the module, the device is working again. 3.6: Even unloading/reloading doesn't help, the device is lost up to the next reboot. Now I am going to do a bit of bisection testing on both regressions. If you have some hints, on how I could speed testing up, I would welcome them. Cheers, Jan Am Donnerstag, 22. November 2012, 20:00:25 schrieb Jan-Matthias Braun: > Hi Benjamin, > > Am Mittwoch, 21. November 2012, 14:36:33 schrieb Benjamin Tissoires: > > On 11/21/2012 10:33 AM, Jan-Matthias Braun wrote: > > > Am Dienstag, 20. November 2012, 13:47:23 schrieben Sie: > > >> On Mon, Nov 19, 2012 at 12:58 PM, Jan-Matthias Braun <[email protected]> > > >> wrote: > > >>> using the current (Linux v2.6.7) hid-multitouch driver I have the > > >>> problem, that the touchscreen works fine after a fresh boot, but after > > >>> a suspend the touchscreen does not come back to live and I am asking > > >>> for assistance to get this working. As I can reproduce this problem on > > >>> a standard tty device without X (see below) I am suspecting a driver > > >>> problem, but I might as well be wrong. > > >> > > >> I assume you are talking about v3.6.7... > > > > > > You are right, of course. Sorry for the distraction. > > > > > >>> The device in question is the Touchscreen of a Dell Inspron Duo > > >>> convertable, a USB device with id 0eef:725e (D-WAV Scientific Co., > > >>> Ltd), found and registered as an input device by the kernel as > > >>> [ 6.931638] usb 4-1: Manufacturer: eGalax Inc. > > >>> [ 16.186272] input: eGalax Inc. USB TouchController as > > >>> /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/input/input10 > > >>> [ 16.187162] hid-multitouch 0003:0EEF:725E.0001: > > >>> input,hiddev0,hidraw0: USB HID v2.10 Pointer > > >>> [eGalax Inc. USB TouchController] on > > >>> usb-0000:00:1d.2-1/input0 > > >>> > > >>> I have tested the behaviour with and without X11. Without X11 I was > > >>> using a standard tty and using cat on the input device. > > >>> After boot the input device gives lot of output while touching the > > >>> screen, after resume the device stays silent. > > >> > > >> strange. I have tested the procedure with the eGalax 0x72FA I got, and > > >> I'm not seeing this problem on a 3.6 kernel. > > >> > > >> Is the config symbol CONFIG_PM set to "y" in your .config file? > > > > > > Yes. > > > > > >> Also, can you try to rmmod / modprobe hid-multitouch when the device > > >> is not responding and see if this solves things. > > > > > > This is not working for me. On modprobe the Kernel log says > > > > > > [12537.335946] input: eGalax Inc. USB TouchController as > > > /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/input > > > /input13 > > > [12537.336875] hid-multitouch 0003:0EEF:725E.0001: input,hiddev0,hidraw0: > > > USB HID v2.10 Pointer [eGalax Inc. USB TouchController] on > > > usb-0000:00:1d.2-1/input0 > > > > > > but /dev/input/event13 is not created. To be honest, I don't even know, > > > if it should be created. > > > > no, the input13 here has nothing to do with the device node > > /dev/input/eventX > > > > > What happens is, that /dev/input/event10 vanishes on removal of the > > > hid-multitouch module and then reappears after modprobe. But a cat on it > > > wont show a reaction while touching the screen's surface. > > > > the event10 vanishing is normal, you removed the driver, so the device is > > not here outside of the kernel. > > When you modprobe, it's back! > > However events should come from this node. > > > > > > > >>> I have this problem since moving to hid-multitouch for handling this > > >>> device. > > >> > > >> What kind of driver did you use before? > > > > > > I think, there was a separate usb touchscreen driver for egalax devices > > > before something like kernel version 3.2. This one I used. Long story > > > short: I have never used the vendor supplied drivers, but those coming > > > with the kernel. > > > > Ok, so either you must have patched hid-egalax to handle your device, > > either you used an other usb driver (it would be great if you can find out > > which). > > The weird thing is that hid-egalax does not do anything at resume, so I > > doubt we should look there. > > Okay, I think it has been the driver for generic usb hid devices, I have been > using. > I have been testing some more kernel versions and found out, that a module > reload after resume will solve the problem at least for kernel versions 3.4, > 3.5.0, and 3.5.4. For the current stable series this doesn't hold true and > the problem arises as described. > Nevertheless, even the 3.4 and 3.5 series need a module reload, for the > device to work after a resume. > > I could do a bisection search to find the commit that caused the secondary > problem of module reload being uneffictive after resume, although this could > take quite some time to complete, atm. I am trying to test commit > 5519cab477b61326963c8d523520db0342862b63 now, to find out, how the first > version behaves with my device. > > > Anyway, can you try the following patch which is already include in the > > next 3.7 release? > > This patch doesn't change the behaviour I am experiencing after resume. > > Cheers, > > Jan-Matthias Braun -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
