Hi all, sorry for the e-mail address hopping. Answers to both addresses are okay.
I have now done a git bisection from 3.0 to 3.1 and have found commit 1e2ef05bb8cf851a694d38e9170c89e7ff052741 PM: Limit race conditions between runtime PM and system sleep (v2) to be the first one to introduce the necessity of a module reload after resume. I hope that this helps in finding a solution. As I (again) don't immediatly know how to go on, I kindly ask you to give me some hints for testing/patching or even a possible solution. :-) In the meat time I would leave out the bisection between kernel versions 3.5 and 3.6, except the case that you think this would be helpful for further diagnoses. Cheers, Jan-Matthias Braun Am Samstag, 24. November 2012, 20:27:38 schrieb Benjamin Tissoires: > Hi Jan-Matthias, > > On Sat, Nov 24, 2012 at 7:01 PM, Jan-Matthias Braun > <[email protected]> wrote: > > 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. > > I suspect the root of it comes either from usb or usbhid (I'm adding > Jiri and Greg in CC so that they can confirm or not). > > The only changes in the suspend/resume code in hid-multitouch are: > - one in kernel 3.3 (I just send a feature at resume). > - one in kernel 3.7, that you tested as not functional (and not in the > range of your targets). > > > > > 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. > > I hope that Greg or Jiri will help on that. I made a short git blame > on drivers/hid/usbhid/hid-core.c, and I did not found anything either. > > Cheers, > Benjamin > > > > > 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
