* Spurious touchpad events with closed LID @ 2017-06-26 16:54 Pali Rohár 2017-06-26 17:03 ` Dmitry Torokhov 0 siblings, 1 reply; 11+ messages in thread From: Pali Rohár @ 2017-06-26 16:54 UTC (permalink / raw) To: Dmitry Torokhov, linux-kernel, linux-input [-- Attachment #1: Type: text/plain, Size: 690 bytes --] Hi! When I'm using dock with external input devices (keyboard + mouse) and LID is closed, I'm getting spurious touchpad events and random mouse clicks and movements. It is because top part of LID is above touchpad and probably generates touch pushes. Year (or two?) when I had conversation with ALPS people I was told that Windows driver is automatically turning touchpad off when ACPI LID close event is received (and similarly turn touchpad on). Maybe Linux should do similar thing? Random movement or touchpad clicks is really annoying. But I'm not sure if kernel or userspace should do this job... What do you think? -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-26 16:54 Spurious touchpad events with closed LID Pali Rohár @ 2017-06-26 17:03 ` Dmitry Torokhov 2017-06-26 19:09 ` Pali Rohár 0 siblings, 1 reply; 11+ messages in thread From: Dmitry Torokhov @ 2017-06-26 17:03 UTC (permalink / raw) To: Pali Rohár; +Cc: linux-kernel, linux-input On Mon, Jun 26, 2017 at 06:54:53PM +0200, Pali Rohár wrote: > Hi! > > When I'm using dock with external input devices (keyboard + mouse) and > LID is closed, I'm getting spurious touchpad events and random mouse > clicks and movements. > > It is because top part of LID is above touchpad and probably generates > touch pushes. > > Year (or two?) when I had conversation with ALPS people I was told that > Windows driver is automatically turning touchpad off when ACPI LID close > event is received (and similarly turn touchpad on). > > Maybe Linux should do similar thing? Random movement or touchpad clicks > is really annoying. But I'm not sure if kernel or userspace should do > this job... What do you think? It is a matter of policy (deciding when device is "usable") and this should be controlled from userspace. Kernel should provide necessary knobs for it though. For a long time I was saying that it should be done at device core level, but I do not think we will ever get there. On ChromeOS input devices export "inhibit" attribute that basically overrides open/close count and prevents delivery of events to userspace, and power management driver controls this attribute together with wake up and others. This allows us to implement policies like "the touchpad should only be active and a wakeup source while the device is in laptop mode, but not in tablet or tent mode, or when lid is closed", "disable keyboard in tablet mode or when list is closed", etc. Drivers can also implement inhibit/uninhibit methods that can put inhibited devices into lower power mode. I am not too happy with the implementation (I'd like to see if we could merge inhibit/uninhibit and open/close), that is why I haven't pushed it upstream yet. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-26 17:03 ` Dmitry Torokhov @ 2017-06-26 19:09 ` Pali Rohár 2017-06-28 20:15 ` Pavel Machek 0 siblings, 1 reply; 11+ messages in thread From: Pali Rohár @ 2017-06-26 19:09 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-kernel, linux-input, Pavel Machek [-- Attachment #1: Type: Text/Plain, Size: 2570 bytes --] On Monday 26 June 2017 19:03:12 Dmitry Torokhov wrote: > On Mon, Jun 26, 2017 at 06:54:53PM +0200, Pali Rohár wrote: > > Hi! > > > > When I'm using dock with external input devices (keyboard + mouse) > > and LID is closed, I'm getting spurious touchpad events and random > > mouse clicks and movements. > > > > It is because top part of LID is above touchpad and probably > > generates touch pushes. > > > > Year (or two?) when I had conversation with ALPS people I was told > > that Windows driver is automatically turning touchpad off when > > ACPI LID close event is received (and similarly turn touchpad on). > > > > Maybe Linux should do similar thing? Random movement or touchpad > > clicks is really annoying. But I'm not sure if kernel or userspace > > should do this job... What do you think? > > It is a matter of policy (deciding when device is "usable") and this > should be controlled from userspace. Kernel should provide necessary > knobs for it though. For a long time I was saying that it should be > done at device core level, but I do not think we will ever get > there. > > On ChromeOS input devices export "inhibit" attribute that basically > overrides open/close count and prevents delivery of events to > userspace, and power management driver controls this attribute > together with wake up and others. Hm... this sounds like a "disable" property for each event device which I was talking about months ago (ccing Pavel). Very similar problem is on Nokia N900, where touchscreen needs to be turned off when screen is locked and phone in pocket. > This allows us to implement > policies like "the touchpad should only be active and a wakeup > source while the device is in laptop mode, but not in tablet or tent > mode, or when lid is closed", "disable keyboard in tablet mode or > when list is closed", etc. Exactly. Userspace receive all needed events and then tell kernel to "mute" input device based on own userspace policies. > Drivers can also implement inhibit/uninhibit methods that can put > inhibited devices into lower power mode. Sounds good. Once events are not delivered to userspace, kernel does not have to receive them too and can power off that input device (if hw support such thing). > I am not too happy with the > implementation (I'd like to see if we could merge inhibit/uninhibit > and open/close), that is why I haven't pushed it upstream yet. Can you send some links to that implementation/patch series? -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-26 19:09 ` Pali Rohár @ 2017-06-28 20:15 ` Pavel Machek 2017-06-28 22:44 ` Bastien Nocera 0 siblings, 1 reply; 11+ messages in thread From: Pavel Machek @ 2017-06-28 20:15 UTC (permalink / raw) To: Pali Rohár; +Cc: Dmitry Torokhov, linux-kernel, linux-input [-- Attachment #1: Type: text/plain, Size: 2236 bytes --] Hi! > > > When I'm using dock with external input devices (keyboard + mouse) > > > and LID is closed, I'm getting spurious touchpad events and random > > > mouse clicks and movements. > > > > > > It is because top part of LID is above touchpad and probably > > > generates touch pushes. > > > > > > Year (or two?) when I had conversation with ALPS people I was told > > > that Windows driver is automatically turning touchpad off when > > > ACPI LID close event is received (and similarly turn touchpad on). > > > > > > Maybe Linux should do similar thing? Random movement or touchpad > > > clicks is really annoying. But I'm not sure if kernel or userspace > > > should do this job... What do you think? > > > > It is a matter of policy (deciding when device is "usable") and this > > should be controlled from userspace. Kernel should provide necessary > > knobs for it though. For a long time I was saying that it should be > > done at device core level, but I do not think we will ever get > > there. > > > > On ChromeOS input devices export "inhibit" attribute that basically > > overrides open/close count and prevents delivery of events to > > userspace, and power management driver controls this attribute > > together with wake up and others. > > Hm... this sounds like a "disable" property for each event device which > I was talking about months ago (ccing Pavel). Very similar problem is on > Nokia N900, where touchscreen needs to be turned off when screen is > locked and phone in pocket. Yes, disable property would be nice. > > This allows us to implement > > policies like "the touchpad should only be active and a wakeup > > source while the device is in laptop mode, but not in tablet or tent > > mode, or when lid is closed", "disable keyboard in tablet mode or > > when list is closed", etc. While policy normally belongs to userspace, I'd argue this is workaround for a hardware bug, and in-kernel solution would be acceptable. Anyway, disable attribute would be nice first step. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-28 20:15 ` Pavel Machek @ 2017-06-28 22:44 ` Bastien Nocera 2017-06-29 7:31 ` Pali Rohár 0 siblings, 1 reply; 11+ messages in thread From: Bastien Nocera @ 2017-06-28 22:44 UTC (permalink / raw) To: Pavel Machek, Pali Rohár; +Cc: Dmitry Torokhov, linux-kernel, linux-input On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > <snip> > While policy normally belongs to userspace, I'd argue this is > workaround for a hardware bug, and in-kernel solution would be > acceptable. > > Anyway, disable attribute would be nice first step. It's already fixed for those of us on recent distributions. The "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled when the lid is closed, when libinput is used to process the events. Usually, non-crappy hardware will do that in firmware, but software is easier to patch ;) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-28 22:44 ` Bastien Nocera @ 2017-06-29 7:31 ` Pali Rohár 2017-06-29 10:08 ` Pavel Machek 2017-06-29 10:37 ` Bastien Nocera 0 siblings, 2 replies; 11+ messages in thread From: Pali Rohár @ 2017-06-29 7:31 UTC (permalink / raw) To: Bastien Nocera; +Cc: Pavel Machek, Dmitry Torokhov, linux-kernel, linux-input On Thursday 29 June 2017 00:44:27 Bastien Nocera wrote: > On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > > > <snip> > > While policy normally belongs to userspace, I'd argue this is > > workaround for a hardware bug, and in-kernel solution would be > > acceptable. > > > > Anyway, disable attribute would be nice first step. > > It's already fixed for those of us on recent distributions. The > "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled > when the lid is closed, when libinput is used to process the events. But this does not fix other usage of /dev/input/* and also does not fix pressing spurious keys in linux virtual tty (ctrl+alt+f1). So it is not a fix. Also important question is: How you detect which input device is "internal", non-removable part of notebook and which one is external? You can have external USB touchpad, and also you can have external PS/2 keyboard connected to docking station (which was e.g. my situation). Also there are PS/2 to active USB converters, to make whole situation complicated. And moreover some internal notebook keyboards are connected via USB and some touchpads via i2c/smbus. I think this detection is not easy or at least I have no idea how to do properly. Existence of PS/2 keyboard does not mean it is internal and existence of USB keyboard does not mean it is external. Maybe ACPI/DSDT provides some information? (No idea, just asking) > Usually, non-crappy hardware will do that in firmware, but software is > easier to patch ;) -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-29 7:31 ` Pali Rohár @ 2017-06-29 10:08 ` Pavel Machek 2017-06-29 10:11 ` Pali Rohár 2017-06-29 10:37 ` Bastien Nocera 1 sibling, 1 reply; 11+ messages in thread From: Pavel Machek @ 2017-06-29 10:08 UTC (permalink / raw) To: Pali Rohár Cc: Bastien Nocera, Dmitry Torokhov, linux-kernel, linux-input [-- Attachment #1: Type: text/plain, Size: 1852 bytes --] Hi! On Thu 2017-06-29 09:31:02, Pali Rohár wrote: > On Thursday 29 June 2017 00:44:27 Bastien Nocera wrote: > > On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > > > > > <snip> > > > While policy normally belongs to userspace, I'd argue this is > > > workaround for a hardware bug, and in-kernel solution would be > > > acceptable. > > > > > > Anyway, disable attribute would be nice first step. > > > > It's already fixed for those of us on recent distributions. The > > "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled > > when the lid is closed, when libinput is used to process the events. > > But this does not fix other usage of /dev/input/* and also does not fix > pressing spurious keys in linux virtual tty (ctrl+alt+f1). So it is not > a fix. > > Also important question is: How you detect which input device is > "internal", non-removable part of notebook and which one is external? > > You can have external USB touchpad, and also you can have external PS/2 > keyboard connected to docking station (which was e.g. my situation). > > Also there are PS/2 to active USB converters, to make whole situation > complicated. > > And moreover some internal notebook keyboards are connected via USB and > some touchpads via i2c/smbus. > > I think this detection is not easy or at least I have no idea how to do > properly. Existence of PS/2 keyboard does not mean it is internal and > existence of USB keyboard does not mean it is external. > > Maybe ACPI/DSDT provides some information? (No idea, just asking) I'm not sure it is complex. You simply add DMI blacklist of the bad systems, with IDs of bad devices. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-29 10:08 ` Pavel Machek @ 2017-06-29 10:11 ` Pali Rohár 2017-06-29 10:15 ` Pavel Machek 0 siblings, 1 reply; 11+ messages in thread From: Pali Rohár @ 2017-06-29 10:11 UTC (permalink / raw) To: Pavel Machek; +Cc: Bastien Nocera, Dmitry Torokhov, linux-kernel, linux-input On Thursday 29 June 2017 12:08:37 Pavel Machek wrote: > Hi! > > On Thu 2017-06-29 09:31:02, Pali Rohár wrote: > > On Thursday 29 June 2017 00:44:27 Bastien Nocera wrote: > > > On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > > > > > > > <snip> > > > > While policy normally belongs to userspace, I'd argue this is > > > > workaround for a hardware bug, and in-kernel solution would be > > > > acceptable. > > > > > > > > Anyway, disable attribute would be nice first step. > > > > > > It's already fixed for those of us on recent distributions. The > > > "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled > > > when the lid is closed, when libinput is used to process the events. > > > > But this does not fix other usage of /dev/input/* and also does not fix > > pressing spurious keys in linux virtual tty (ctrl+alt+f1). So it is not > > a fix. > > > > Also important question is: How you detect which input device is > > "internal", non-removable part of notebook and which one is external? > > > > You can have external USB touchpad, and also you can have external PS/2 > > keyboard connected to docking station (which was e.g. my situation). > > > > Also there are PS/2 to active USB converters, to make whole situation > > complicated. > > > > And moreover some internal notebook keyboards are connected via USB and > > some touchpads via i2c/smbus. > > > > I think this detection is not easy or at least I have no idea how to do > > properly. Existence of PS/2 keyboard does not mean it is internal and > > existence of USB keyboard does not mean it is external. > > > > Maybe ACPI/DSDT provides some information? (No idea, just asking) > > I'm not sure it is complex. You simply add DMI blacklist of the bad > systems, with IDs of bad devices. My original request is to disable internal keyboard, touchpad and trackpoint on notebook when it is docked and LID is closed. It has nothing to do with DMI blacklist or so. -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-29 10:11 ` Pali Rohár @ 2017-06-29 10:15 ` Pavel Machek 2017-06-29 10:24 ` Pali Rohár 0 siblings, 1 reply; 11+ messages in thread From: Pavel Machek @ 2017-06-29 10:15 UTC (permalink / raw) To: Pali Rohár Cc: Bastien Nocera, Dmitry Torokhov, linux-kernel, linux-input [-- Attachment #1: Type: text/plain, Size: 2533 bytes --] On Thu 2017-06-29 12:11:12, Pali Rohár wrote: > On Thursday 29 June 2017 12:08:37 Pavel Machek wrote: > > Hi! > > > > On Thu 2017-06-29 09:31:02, Pali Rohár wrote: > > > On Thursday 29 June 2017 00:44:27 Bastien Nocera wrote: > > > > On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > > > > > > > > > <snip> > > > > > While policy normally belongs to userspace, I'd argue this is > > > > > workaround for a hardware bug, and in-kernel solution would be > > > > > acceptable. > > > > > > > > > > Anyway, disable attribute would be nice first step. > > > > > > > > It's already fixed for those of us on recent distributions. The > > > > "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled > > > > when the lid is closed, when libinput is used to process the events. > > > > > > But this does not fix other usage of /dev/input/* and also does not fix > > > pressing spurious keys in linux virtual tty (ctrl+alt+f1). So it is not > > > a fix. > > > > > > Also important question is: How you detect which input device is > > > "internal", non-removable part of notebook and which one is external? > > > > > > You can have external USB touchpad, and also you can have external PS/2 > > > keyboard connected to docking station (which was e.g. my situation). > > > > > > Also there are PS/2 to active USB converters, to make whole situation > > > complicated. > > > > > > And moreover some internal notebook keyboards are connected via USB and > > > some touchpads via i2c/smbus. > > > > > > I think this detection is not easy or at least I have no idea how to do > > > properly. Existence of PS/2 keyboard does not mean it is internal and > > > existence of USB keyboard does not mean it is external. > > > > > > Maybe ACPI/DSDT provides some information? (No idea, just asking) > > > > I'm not sure it is complex. You simply add DMI blacklist of the bad > > systems, with IDs of bad devices. > > My original request is to disable internal keyboard, touchpad and > trackpoint on notebook when it is docked and LID is closed. > > It has nothing to do with DMI blacklist or so. Well, you have a buggy notebook. On non-buggy ones, touchpad will not generate events when closed. That's where the DMI blacklist comes to mind. (Of course, disable attribute would still be nice for other cases.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-29 10:15 ` Pavel Machek @ 2017-06-29 10:24 ` Pali Rohár 0 siblings, 0 replies; 11+ messages in thread From: Pali Rohár @ 2017-06-29 10:24 UTC (permalink / raw) To: Pavel Machek; +Cc: Bastien Nocera, Dmitry Torokhov, linux-kernel, linux-input On Thursday 29 June 2017 12:15:00 Pavel Machek wrote: > On Thu 2017-06-29 12:11:12, Pali Rohár wrote: > > On Thursday 29 June 2017 12:08:37 Pavel Machek wrote: > > > Hi! > > > > > > On Thu 2017-06-29 09:31:02, Pali Rohár wrote: > > > > On Thursday 29 June 2017 00:44:27 Bastien Nocera wrote: > > > > > On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > > > > > > > > > > > <snip> > > > > > > While policy normally belongs to userspace, I'd argue this is > > > > > > workaround for a hardware bug, and in-kernel solution would be > > > > > > acceptable. > > > > > > > > > > > > Anyway, disable attribute would be nice first step. > > > > > > > > > > It's already fixed for those of us on recent distributions. The > > > > > "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled > > > > > when the lid is closed, when libinput is used to process the events. > > > > > > > > But this does not fix other usage of /dev/input/* and also does not fix > > > > pressing spurious keys in linux virtual tty (ctrl+alt+f1). So it is not > > > > a fix. > > > > > > > > Also important question is: How you detect which input device is > > > > "internal", non-removable part of notebook and which one is external? > > > > > > > > You can have external USB touchpad, and also you can have external PS/2 > > > > keyboard connected to docking station (which was e.g. my situation). > > > > > > > > Also there are PS/2 to active USB converters, to make whole situation > > > > complicated. > > > > > > > > And moreover some internal notebook keyboards are connected via USB and > > > > some touchpads via i2c/smbus. > > > > > > > > I think this detection is not easy or at least I have no idea how to do > > > > properly. Existence of PS/2 keyboard does not mean it is internal and > > > > existence of USB keyboard does not mean it is external. > > > > > > > > Maybe ACPI/DSDT provides some information? (No idea, just asking) > > > > > > I'm not sure it is complex. You simply add DMI blacklist of the bad > > > systems, with IDs of bad devices. > > > > My original request is to disable internal keyboard, touchpad and > > trackpoint on notebook when it is docked and LID is closed. > > > > It has nothing to do with DMI blacklist or so. > > Well, you have a buggy notebook. On non-buggy ones, touchpad will not > generate events when closed. > > That's where the DMI blacklist comes to mind. Such blacklist would be huge. Lot of notebooks working in this way. > (Of course, disable attribute would still be nice for other cases.) Yes. -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Spurious touchpad events with closed LID 2017-06-29 7:31 ` Pali Rohár 2017-06-29 10:08 ` Pavel Machek @ 2017-06-29 10:37 ` Bastien Nocera 1 sibling, 0 replies; 11+ messages in thread From: Bastien Nocera @ 2017-06-29 10:37 UTC (permalink / raw) To: Pali Rohár; +Cc: Pavel Machek, Dmitry Torokhov, linux-kernel, linux-input On Thu, 2017-06-29 at 09:31 +0200, Pali Rohár wrote: > On Thursday 29 June 2017 00:44:27 Bastien Nocera wrote: > > On Wed, 2017-06-28 at 22:15 +0200, Pavel Machek wrote: > > > > > > > <snip> > > > While policy normally belongs to userspace, I'd argue this is > > > workaround for a hardware bug, and in-kernel solution would be > > > acceptable. > > > > > > Anyway, disable attribute would be nice first step. > > > > It's already fixed for those of us on recent distributions. The > > "ID_INPUT_TOUCHPAD_INTEGRATION=internal" touchpads will be disabled > > when the lid is closed, when libinput is used to process the > > events. > > But this does not fix other usage of /dev/input/* and also does not > fix > pressing spurious keys in linux virtual tty (ctrl+alt+f1). So it is > not > a fix. > > Also important question is: How you detect which input device is > "internal", non-removable part of notebook and which one is external? We have heuristics and a database. Look at the hwdb/ subdirectory in systemd. > Maybe ACPI/DSDT provides some information? (No idea, just asking) It could and should, but it's usually empty because when some hardware makers can't be bothered to change the device's name, they'll hardly spend that time adding location information, are they? ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-06-29 10:37 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-26 16:54 Spurious touchpad events with closed LID Pali Rohár 2017-06-26 17:03 ` Dmitry Torokhov 2017-06-26 19:09 ` Pali Rohár 2017-06-28 20:15 ` Pavel Machek 2017-06-28 22:44 ` Bastien Nocera 2017-06-29 7:31 ` Pali Rohár 2017-06-29 10:08 ` Pavel Machek 2017-06-29 10:11 ` Pali Rohár 2017-06-29 10:15 ` Pavel Machek 2017-06-29 10:24 ` Pali Rohár 2017-06-29 10:37 ` Bastien Nocera
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.