hid-multitouch: eGalax Touchscreen not resuming after suspend

hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

Dear List,

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.

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.

I have this problem since moving to hid-multitouch for handling this device.

I will be happy to test and supply more information. Thanks a lot for looking into this,

Jan-Matthias Braun

PS: As I am not subscribed to the mailing list, please CC me.

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Benjamin Tissoires]

Hi Jan-Matthias,

On Mon, Nov 19, 2012 at 12:58 PM, Jan-Matthias Braun <jan_braun@gmx.net> wrote:
> Dear List,
>
> 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...

>
> 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?

Also, can you try to rmmod / modprobe hid-multitouch when the device
is not responding and see if this solves things.

>
> I have this problem since moving to hid-multitouch for handling this device.

What kind of driver did you use before?

Cheers,
Benjamin

>
> I will be happy to test and supply more information. Thanks a lot for looking into this,
>
> Jan-Matthias Braun
>
> PS: As I am not subscribed to the mailing list, please CC me.
> --
> 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-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

Hi Benjamin,

thanks for looking into the issue.

Am Dienstag, 20. November 2012, 13:47:23 schrieben Sie:
> Hi Jan-Matthias,
> 
> On Mon, Nov 19, 2012 at 12:58 PM, Jan-Matthias Braun <jan_braun@gmx.net> wrote:
> > Dear List,
> >
> > 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.
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.

> > 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.

Cheers,

Jan

> > I will be happy to test and supply more information. Thanks a lot for looking into this,
> >
> > Jan-Matthias Braun
> >
> > PS: As I am not subscribed to the mailing list, please CC me.

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Benjamin Tissoires]

Hi Jan-Matthias,

On 11/21/2012 10:33 AM, Jan-Matthias Braun wrote:
> Hi Benjamin,
> 
> thanks for looking into the issue.
> 
> Am Dienstag, 20. November 2012, 13:47:23 schrieben Sie:
>> Hi Jan-Matthias,
>>
>> On Mon, Nov 19, 2012 at 12:58 PM, Jan-Matthias Braun <jan_braun@gmx.net> wrote:
>>> Dear List,
>>>
>>> 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.

Anyway, can you try the following patch which is already include in the next 3.7 release?

Cheers,
Benjamin

>From 4e3265da686f6ff4b02fcba4c124c4af51265375 Mon Sep 17 00:00:00 2001
From: Scott Liu <scott.liu@emc.com.tw>
Date: Wed, 15 Aug 2012 17:21:55 +0800
Subject: [PATCH] HID: multitouch: Add ELAN production request when resume.

Add ELAN production request when resume.

Some Elan legacy devices require SET_IDLE to be set on resume.
It should be safe to send it to other devices too.
Tested on 3M, Stantum, Cypress, Zytronic, eGalax, and Elan panels.

Suggested by Benjamin Tissoires <benjamin.tissoires@enac.fr>

Signed-off-by: Scott Liu <scott.liu@emc.com.tw>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/hid/hid-multitouch.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 59c8b5c..e824c37 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -767,6 +767,32 @@ static int mt_reset_resume(struct hid_device *hdev)
 	mt_set_input_mode(hdev);
 	return 0;
 }
+
+static int mt_resume(struct hid_device *hdev)
+{
+	struct usb_interface *intf;
+	struct usb_host_interface *interface;
+	struct usb_device *dev;
+
+	if (hdev->bus != BUS_USB)
+		return 0;
+
+	intf = to_usb_interface(hdev->dev.parent);
+	interface = intf->cur_altsetting;
+	dev = hid_to_usb_dev(hdev);
+
+	/* Some Elan legacy devices require SET_IDLE to be set on resume.
+	 * It should be safe to send it to other devices too.
+	 * Tested on 3M, Stantum, Cypress, Zytronic, eGalax, and Elan panels. */
+
+	usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+			HID_REQ_SET_IDLE,
+			USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+			0, interface->desc.bInterfaceNumber,
+			NULL, 0, USB_CTRL_SET_TIMEOUT);
+
+	return 0;
+}
 #endif
 
 static void mt_remove(struct hid_device *hdev)
@@ -1092,6 +1118,7 @@ static struct hid_driver mt_driver = {
 	.event = mt_event,
 #ifdef CONFIG_PM
 	.reset_resume = mt_reset_resume,
+	.resume = mt_resume,
 #endif
 };
 
-- 
1.8.0

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[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 <jan_braun@gmx.net> 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

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

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 <jan_braun@gmx.net> 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

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Benjamin Tissoires]

Hi Jan-Matthias,

On Sat, Nov 24, 2012 at 7:01 PM, Jan-Matthias Braun
<jbraun@physik3.gwdg.de> 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 <jan_braun@gmx.net> 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

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

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
> <jbraun@physik3.gwdg.de> 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 <jan_braun@gmx.net> 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

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jiri Kosina]

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
> > <jbraun@physik3.gwdg.de> 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 <jan_braun@gmx.net> 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

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Rafael J. Wysocki]

On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> 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 for the pointer, I'll have a look at it tomorrow.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Rafael J. Wysocki]

On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> 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.

So with that commit your device doesn't work after resume from system suspend
unless you reload the driver?

> > 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. :-)

Can you apply the patch below to the current mainline kernel and see if it makes any
difference, please?

Rafael


---
 drivers/base/power/main.c |    4 ----
 1 file changed, 4 deletions(-)

Index: linux/drivers/base/power/main.c
===================================================================
--- linux.orig/drivers/base/power/main.c
+++ linux/drivers/base/power/main.c
@@ -589,8 +589,6 @@ static int device_resume(struct device *
 	if (!dev->power.is_suspended)
 		goto Unlock;
 
-	pm_runtime_enable(dev);
-
 	if (dev->pm_domain) {
 		info = "power domain ";
 		callback = pm_op(&dev->pm_domain->ops, state);
@@ -1136,8 +1134,6 @@ static int __device_suspend(struct devic
 
 	if (error)
 		async_error = error;
-	else if (dev->power.is_suspended)
-		__pm_runtime_disable(dev, false);
 
 	return error;
 }


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

Hi Rafael,

thanks for looking into this.

Am Donnerstag, 29. November 2012, 01:20:04 schrieb Rafael J. Wysocki:
> On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> > On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> > > 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.
> 
> So with that commit your device doesn't work after resume from system suspend
> unless you reload the driver?

Yes. Additionally, with later kernel revisions even this won't help, but I could imagine this to be a consequence of the same problem.

> > > 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. :-)
> 
> Can you apply the patch below to the current mainline kernel and see if it makes any
> difference, please?

It does: Current mainline kernel (version >3.7.0-rc7 from git) is not showing the problem, if the patch is applied.

Cheers,

Jan

> ---
>  drivers/base/power/main.c |    4 ----
>  1 file changed, 4 deletions(-)
> 
> Index: linux/drivers/base/power/main.c
> ===================================================================
> --- linux.orig/drivers/base/power/main.c
> +++ linux/drivers/base/power/main.c
> @@ -589,8 +589,6 @@ static int device_resume(struct device *
>  	if (!dev->power.is_suspended)
>  		goto Unlock;
>  
> -	pm_runtime_enable(dev);
> -
>  	if (dev->pm_domain) {
>  		info = "power domain ";
>  		callback = pm_op(&dev->pm_domain->ops, state);
> @@ -1136,8 +1134,6 @@ static int __device_suspend(struct devic
>  
>  	if (error)
>  		async_error = error;
> -	else if (dev->power.is_suspended)
> -		__pm_runtime_disable(dev, false);
>  
>  	return error;
>  }
> 
> 
> 

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Rafael J. Wysocki]

On Thursday, November 29, 2012 03:03:04 PM Jan-Matthias Braun wrote:
> Hi Rafael,
> 
> thanks for looking into this.
> 
> Am Donnerstag, 29. November 2012, 01:20:04 schrieb Rafael J. Wysocki:
> > On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> > > On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> > > > 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.
> > 
> > So with that commit your device doesn't work after resume from system suspend
> > unless you reload the driver?
> 
> Yes. Additionally, with later kernel revisions even this won't help, but I could imagine this to be a consequence of the same problem.
> 
> > > > 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. :-)
> > 
> > Can you apply the patch below to the current mainline kernel and see if it makes any
> > difference, please?
> 
> It does: Current mainline kernel (version >3.7.0-rc7 from git) is not showing
> the problem, if the patch is applied.

If you apply the patch below instead of the previous one, does it make
the problem return, or is it still good?

Rafael


---
 drivers/base/power/main.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux/drivers/base/power/main.c
===================================================================
--- linux.orig/drivers/base/power/main.c
+++ linux/drivers/base/power/main.c
@@ -513,6 +513,8 @@ static int device_resume_early(struct de
 
  Out:
 	TRACE_RESUME(error);
+
+	pm_runtime_enable(dev);
 	return error;
 }
 
@@ -589,8 +591,6 @@ static int device_resume(struct device *
 	if (!dev->power.is_suspended)
 		goto Unlock;
 
-	pm_runtime_enable(dev);
-
 	if (dev->pm_domain) {
 		info = "power domain ";
 		callback = pm_op(&dev->pm_domain->ops, state);
@@ -930,6 +930,8 @@ static int device_suspend_late(struct de
 	pm_callback_t callback = NULL;
 	char *info = NULL;
 
+	__pm_runtime_disable(dev, false);
+
 	if (dev->power.syscore)
 		return 0;
 
@@ -1133,11 +1135,8 @@ static int __device_suspend(struct devic
 
  Complete:
 	complete_all(&dev->power.completion);
-
 	if (error)
 		async_error = error;
-	else if (dev->power.is_suspended)
-		__pm_runtime_disable(dev, false);
 
 	return error;
 }



-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

[-- Attachment #1: Type: Text/Plain, Size: 1659 bytes --]

Hi Rafael,

Am Donnerstag 29. November 2012, 23:28:55 schrieb Rafael J. Wysocki:
> On Thursday, November 29, 2012 03:03:04 PM Jan-Matthias Braun wrote:
> > Am Donnerstag, 29. November 2012, 01:20:04 schrieb Rafael J. Wysocki:
> > > On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> > > > On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> > > > > 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.
> > > 
> > > So with that commit your device doesn't work after resume from system suspend
> > > unless you reload the driver?
> > 
> > Yes. Additionally, with later kernel revisions even this won't help, but I could imagine this to be a consequence of the same problem.
> > 
> > > > > 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. :-)
> > > 
> > > Can you apply the patch below to the current mainline kernel and see if it makes any
> > > difference, please?
> > 
> > It does: Current mainline kernel (version >3.7.0-rc7 from git) is not showing
> > the problem, if the patch is applied.
> 
> If you apply the patch below instead of the previous one, does it make
> the problem return, or is it still good?

again, the problem does not occur; the resume behaviour of the touchscreen is still good.

Thanks a lot for testing!

Jan

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Rafael J. Wysocki]

On Tuesday, December 04, 2012 11:11:27 PM Jan-Matthias Braun wrote:
> Hi Rafael,
> 
> Am Donnerstag 29. November 2012, 23:28:55 schrieb Rafael J. Wysocki:
> > On Thursday, November 29, 2012 03:03:04 PM Jan-Matthias Braun wrote:
> > > Am Donnerstag, 29. November 2012, 01:20:04 schrieb Rafael J. Wysocki:
> > > > On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> > > > > On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> > > > > > 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.
> > > > 
> > > > So with that commit your device doesn't work after resume from system suspend
> > > > unless you reload the driver?
> > > 
> > > Yes. Additionally, with later kernel revisions even this won't help, but I could imagine this to be a consequence of the same problem.
> > > 
> > > > > > 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. :-)
> > > > 
> > > > Can you apply the patch below to the current mainline kernel and see if it makes any
> > > > difference, please?
> > > 
> > > It does: Current mainline kernel (version >3.7.0-rc7 from git) is not showing
> > > the problem, if the patch is applied.
> > 
> > If you apply the patch below instead of the previous one, does it make
> > the problem return, or is it still good?
> 
> again, the problem does not occur; the resume behaviour of the touchscreen is still good.
> 
> Thanks a lot for testing!

Well, thank you. :-)

I'll add a changelog to this patch and submit it as a fix for the issue
you're observing.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: hid-multitouch: eGalax Touchscreen not resuming after suspend

[Jan-Matthias Braun]

Am Mittwoch, 5. Dezember 2012, 01:28:53 schrieb Rafael J. Wysocki:
> On Tuesday, December 04, 2012 11:11:27 PM Jan-Matthias Braun wrote:
> > Am Donnerstag 29. November 2012, 23:28:55 schrieb Rafael J. Wysocki:
> > > On Thursday, November 29, 2012 03:03:04 PM Jan-Matthias Braun wrote:
> > > > Am Donnerstag, 29. November 2012, 01:20:04 schrieb Rafael J. Wysocki:
> > > > > On Tuesday, November 27, 2012 09:26:11 PM Jiri Kosina wrote:
> > > > > > On Sun, 25 Nov 2012, Jan-Matthias Braun wrote:
> > > > > > > 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.
> > > > > 
> > > > > So with that commit your device doesn't work after resume from system suspend
> > > > > unless you reload the driver?
> > > > 
> > > > Yes. Additionally, with later kernel revisions even this won't help, but I could imagine this to be a consequence of the same problem.
> > > > 
> > > > > > > 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. :-)
> > > > > 
> > > > > Can you apply the patch below to the current mainline kernel and see if it makes any
> > > > > difference, please?
> > > > 
> > > > It does: Current mainline kernel (version >3.7.0-rc7 from git) is not showing
> > > > the problem, if the patch is applied.
> > > 
> > > If you apply the patch below instead of the previous one, does it make
> > > the problem return, or is it still good?
> > 
> > again, the problem does not occur; the resume behaviour of the touchscreen is still good.
> > 
> > Thanks a lot for testing!
> 
> Well, thank you. :-)
> 
> I'll add a changelog to this patch and submit it as a fix for the issue
> you're observing.

Great! Thank you and all others involved for their time!

Jan-Matthias Braun