On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> 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,
Let's add Rafael to CC then.
Rafael, could you please take a look? If you find the below unreadable,
the whole thread can be seen in linux-input archive at
http://www.spinics.net/lists/linux-input/msg23675.html
Thanks.
>
> 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
>
--
Jiri Kosina
SUSE Labs
--
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
