ignore trackpad/mouse while typing

/proc/sys/dev/input/mouse_holdoff_ms

for tuning the time period during which the mouse is to be ignored after a keystroke (valid range from 0 [disabled] ... 3000 ).

NOTE: Official 'SYSCTL' numbers should be assigned
for the 'input' and 'input/mouse_holdoff_ms' nodes.

Review

Quoted 3 lines · Till Straumann

(quoted diff) +3 -0

+ 		if ( jiffies - mouse_holdoff_last_jiffie < mouse_holdoff_jiffies )
+ 			return;
+ 		/* Note: we could lose mouse events when the jiffie counter rolls over... */

I think the difference is always correct.

OK, here's a trivial patch (linux-2.4.18) for disabling/ignoring the mouse/trackpad while typing. It can be very convenient on notebook computers.
NOTE: this patch works only on machines using the 'new' input layer (e.g. Apple Powerbook, ibook, ...)

The holdoff time can be adjusted via sysctl/procfs - see description in the patch file.

-- Till

PS: Please CC me if there are comments/questions; I'm not subscribed to this mailing list.

This is a patch for linux-2.4.18

Author: Till Straumann <[email protected]>

Apply this patch as follows:
- chdir to the linux kernel source topdir
- issue 'patch -p0 < <this file>'
NOTE: it is alway a good idea to use --dry-run first

Using this patch, it is possible to ignore mouse events while your are typing which can be very convenient on notebook computers equipped with trackpads.

NOTE: Works only for mice/keyboards who use the 'new' input

      layer (USB, powermac, ...).

You will get a new file (and a respective sysctl)

/proc/sys/dev/input/mouse_holdoff_ms

for tuning the time period during which the mouse is to be ignored after a keystroke (valid range from 0 [disabled] ... 3000 ).

NOTE: Official 'SYSCTL' numbers should be assigned
for the 'input' and 'input/mouse_holdoff_ms' nodes.

*** drivers/input/input.c.orig Thu Nov 28 12:00:07 2002
--- drivers/input/input.c Thu Nov 28 12:18:58 2002
***************
*** 28,33 ****
--- 28,37 ----
* Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic */

+ #include <linux/config.h>
+ #include <linux/proc_fs.h>
+ #include <linux/sysctl.h>
+
#include <linux/init.h>
#include <linux/sched.h>
#include <linux/smp_lock.h>
***************
*** 60,65 ****
--- 64,74 ----
static int input_number;
static long input_devices[NBITS(INPUT_DEVICES)];

+ static unsigned long mouse_holdoff_jiffies = 0;
+ static unsigned long mouse_holdoff_ms_min = 0;
+ static unsigned long mouse_holdoff_ms_max = 3000;
+ static unsigned long mouse_holdoff_last_jiffie = 0;
+
void input_event(struct input_dev *dev, unsigned int type, unsigned int code, int value) {
struct input_handle *handle = dev->handle;
***************
*** 71,76 ****
--- 80,94 ----
if (type > EV_MAX || !test_bit(type, dev->evbit))
return;

(quoted diff) +9 -0

+ 	if ( EV_KEY == type && code < BTN_MISC ) {
+ 		/* a 'true' key event */
+ 		mouse_holdoff_last_jiffie = jiffies;
+ 	} else if ( EV_ABS == type || EV_REL == type || (EV_KEY == type && code >= BTN_MISC ) ) {
+ 		if ( jiffies - mouse_holdoff_last_jiffie < mouse_holdoff_jiffies )
+ 			return;
+ 		/* Note: we could lose mouse events when the jiffie counter rolls over... */
+ 	}
+
  	switch (type) {
 
  		case EV_KEY:

***************
*** 417,422 ****
--- 435,470 ----
devfs_unregister(handle);
}

+ #if defined(CONFIG_SYSCTL)

(quoted diff) +29 -0

+
+ static struct ctl_table_header *mouse_holdoff_header;
+
+ static ctl_table mouse_holdoff_files[] =
+ {
+ 	{ 0xdead, "mouse_holdoff_ms",
+ 	  &mouse_holdoff_jiffies, sizeof(mouse_holdoff_jiffies),
+ 	  0666, NULL,
+ 	  proc_doulongvec_ms_jiffies_minmax, NULL, NULL,
+ 	  (void*)&mouse_holdoff_ms_min,
+ 	  (void*)&mouse_holdoff_ms_max
+ 	},
+ 	{ 0 }
+ };
+
+ static ctl_table mouse_holdoff_input_dir[] =
+ {
+ 	{ 0xbeef, "input", NULL, 0, 0555, mouse_holdoff_files },
+ 	{ 0 }
+ };
+
+ static ctl_table mouse_holdoff_root_dir[] =
+ {
+ 	{ CTL_DEV, "dev", NULL, 0, 0555, mouse_holdoff_input_dir },
+ 	{ 0 }
+ };
+
+ #endif
+
  static int __init input_init(void)
  {
  	if (devfs_register_chrdev(INPUT_MAJOR, "input", &input_fops)) {

***************
*** 424,434 ****
--- 472,488 ----
return -EBUSY;
}
input_devfs_handle = devfs_mk_dir(NULL, "input", NULL);
+ #if defined(CONFIG_SYSCTL)

(quoted diff) +2 -0

+ 	mouse_holdoff_header = register_sysctl_table(mouse_holdoff_root_dir, 1);
+ #endif
  	return 0;

Quoted 6 lines · Till Straumann

OK, here's a trivial patch (linux-2.4.18) for disabling/ignoring the mouse/trackpad while typing. It can be very convenient on notebook computers.
NOTE: this patch works only on machines using the 'new' input layer (e.g. Apple Powerbook, ibook, ...)

Quoted 2 lines

The holdoff time can be adjusted via sysctl/procfs - see description in the patch file.

It's a very nice idea, but I'd prefer this to be handled somewhere higher than the IDE code, preferably in X ...

Quoted 10 lines · Vojtech Pavlik

Quoted 8 lines · Till Straumann

OK, here's a trivial patch (linux-2.4.18) for disabling/ignoring the mouse/trackpad while typing. It can be very convenient on notebook computers.
NOTE: this patch works only on machines using the 'new' input layer (e.g. Apple Powerbook, ibook, ...)

The holdoff time can be adjusted via sysctl/procfs - see description in the patch file.

Quoted 2 lines

It's a very nice idea, but I'd prefer this to be handled somewhere higher than the IDE code, preferably in X ...

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Quoted 14 lines · Benjamin Herrenschmidt

Quoted 12 lines · Vojtech Pavlik

Quoted 8 lines · Till Straumann

OK, here's a trivial patch (linux-2.4.18) for disabling/ignoring the mouse/trackpad while typing. It can be very convenient on notebook computers.
NOTE: this patch works only on machines using the 'new' input layer (e.g. Apple Powerbook, ibook, ...)

The holdoff time can be adjusted via sysctl/procfs - see description in the patch file.

It's a very nice idea, but I'd prefer this to be handled somewhere higher than the IDE code, preferably in X ...

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Mine is one of those machines. I have to turn off gpm for sure, and X is
quite oversensitive too (tuned it in KDE, but still this functionality would be very nice).

Quoted 8 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Mine is one of those machines. I have to turn off gpm for sure, and X is
quite oversensitive too (tuned it in KDE, but still this functionality would be very nice).

How about implementing it in mousedev.c?

Quoted 4 lines · Vojtech Pavlik

Quoted 4 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Quoted 8 lines

Quoted 6 lines

Mine is one of those machines. I have to turn off gpm for sure,
and X is
quite oversensitive too (tuned it in KDE, but still this functionality would
be very nice).

How about implementing it in mousedev.c?

Right, though it would need hooks in kbddev or something to know about keystrokes.

Also, I don't like the sysctl's as those need
allocating sysctl numbers,

which are always a problem. In 2.5,
we could have these in sysfs, though for 2.4 I'm not sure what to do.

Ben.

Hi.

Thanks for your feedback. Please let me work on this a little more. The first version of the patch has 2 flaws:

- emulated mouse buttons are treated as normal key events and are hence suppressed (that's already fixed but introduces a very ugly dependency on the mac-hid driver).
- the same applies to modifier keys. Unfortunately, we need a list of these keys (and there is obviously no way to know what keys are 'modifiers' for a specific application program (such as X)).

Unfortunately, I still see the kernel as the proper place to handle this (feature shared by all applications; 'semi-real time' nature of the feature.
'input' is the place where mouse and key events come together.)

Then, there is one more problem: I had a disk-crash and I have to wait for my new disk before I can continue working (or even look at the code).

:-(

Regards
-- Till

PS: I added a few comments to the discussion below

Quoted 6 lines · Benjamin Herrenschmidt

Quoted 4 lines · Vojtech Pavlik

Quoted 4 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

I agree.

Quoted 11 lines

Quoted 8 lines

Quoted 6 lines

Mine is one of those machines. I have to turn off gpm for sure,
and X is
quite oversensitive too (tuned it in KDE, but still this functionality would
be very nice).

How about implementing it in mousedev.c?

Right, though it would need hooks in kbddev or something to know about keystrokes.

Yeah - that's why I put it into 'input' - that's the only piece of code who knows about both, key and mouse events. BTW: I put the control file into /proc/sys../input and not mac-hid because the feature is not limited to macs.

Quoted 2 lines

Also, I don't like the sysctl's as those need
allocating sysctl numbers,

Unfortunately, the list of 'modifier' keys needs to be configurable as well.
How can we do that without sysctl?

Quoted 7 lines

which are always a problem. In 2.5,
we could have these in sysfs, though for 2.4 I'm not sure what to do.

Ben.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Quoted 5 lines

Quoted 3 lines

Mine is one of those machines. I have to turn off gpm for sure, and X is
quite oversensitive too (tuned it in KDE, but still this functionality would be very nice).

How about implementing it in mousedev.c?

Right, though it would need hooks in kbddev or something to know about keystrokes.

Also, I don't like the sysctl's as those need allocating sysctl numbers, which are always a problem. In 2.5, we could have these in sysfs, though for 2.4 I'm not sure what to do.

Quoted 9 lines · Benjamin Herrenschmidt

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Mine is one of those machines. I have to turn off gpm for sure,
and X is quite oversensitive too (tuned it in KDE, but still this functionality would be very nice).

Quoted 4 lines

Quoted 1 line

How about implementing it in mousedev.c?

Right, though it would need hooks in kbddev or something to know about keystrokes.

It could accept keyboards as an event source for this purpose. I'd like to keep this out of the input core.

Quoted 10 lines · Vojtech Pavlik

Quoted 9 lines · Benjamin Herrenschmidt

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Mine is one of those machines. I have to turn off gpm for sure,
and X is quite oversensitive too (tuned it in KDE, but still this functionality would be very nice).

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

How about implementing it in mousedev.c?

Right, though it would need hooks in kbddev or something to know about keystrokes.

It could accept keyboards as an event source for this purpose. I'd like to keep this out of the input core.

Hmm, this reminds me of one feature I would need in the input core to support 1-button mices in userspace (or at least in a totally self-contained module), namely the ability to register "filters" that are called early in input_event() and where a return value !=0 lets it return immediately from input_event() without processing the event.

Eg. something along these lines:

	ret = 0;
        list_for_each_entry(filter, &dev->f_list, d_node)
                if (filter->open)
                        ret |= filter->handler->event(handle, type, code,
value);
	if (ret) return;

Comments?

Quoted 40 lines · Franz Sirl

Quoted 11 lines · Vojtech Pavlik

Quoted 9 lines · Benjamin Herrenschmidt

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Well... the problem happpens in console as well, and with other non-X apps like MacOnLinux. Some Apple PowerBooks have over-sensitive trackpad. Apple themselves implement a similar mecanism in the kernel driver of OS X.

Mine is one of those machines. I have to turn off gpm for sure,
and X is quite oversensitive too (tuned it in KDE, but still this functionality would be very nice).

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

How about implementing it in mousedev.c?

Right, though it would need hooks in kbddev or something to know about keystrokes.

It could accept keyboards as an event source for this purpose. I'd like
to keep this out of the input core.

Hmm, this reminds me of one feature I would need in the input core to support
1-button mices in userspace (or at least in a totally self-contained module),
namely the ability to register "filters" that are called early in input_event() and where a return value !=0 lets it return immediately from
input_event() without processing the event.

Eg. something along these lines:

	ret = 0;
        list_for_each_entry(filter, &dev->f_list, d_node)
                if (filter->open)
                        ret |= filter->handler->event(handle, type,
code,
value);
	if (ret) return;

Quoted 1 line

Comments?

I don't think I want this. This *can* be solved completely in userspace,

the only problem would be that the interface to the userspace program doing it wouldn't be the same as to evdev.c, and that the kernel *dev.c modules could not bind to do it.

For mice, there is no problem - the mouse protocol can be implemented over a bidirectional pipe.

For making another evdev device, you can use uinput.

You'd only have problems should you want to create a joystick device, which you most likely won't need to do.

--
Vojtech Pavlik
SuSE Labs

Quoted 8 lines · Franz Sirl

Hmm, this reminds me of one feature I would need in the input core to support 1-button mices in userspace (or at least in a totally self-contained module), namely the ability to register "filters" that are called early in input_event() and where a return value !=0 lets it return immediately from input_event() without processing the event.

Eg. something along these lines:

Quoted 8 lines

	ret = 0;
        list_for_each_entry(filter, &dev->f_list, d_node)
                if (filter->open)
                        ret |= filter->handler->event(handle, type, code,
value);
	if (ret) return;

Comments?

I don't think I want this. This *can* be solved completely in userspace, the only problem would be that the interface to the userspace program doing it wouldn't be the same as to evdev.c, and that the kernel *dev.c modules could not bind to do it.

For mice, there is no problem - the mouse protocol can be implemented over a bidirectional pipe.

For making another evdev device, you can use uinput.

Quoted 23 lines · Vojtech Pavlik

Quoted 8 lines · Franz Sirl

Hmm, this reminds me of one feature I would need in the input core to support 1-button mices in userspace (or at least in a totally self-contained module), namely the ability to register "filters" that are called early in input_event() and where a return value !=0 lets it return immediately from input_event() without processing the event.

Eg. something along these lines:

Quoted 8 lines

	ret = 0;
        list_for_each_entry(filter, &dev->f_list, d_node)
                if (filter->open)
                        ret |= filter->handler->event(handle, type, code,
value);
	if (ret) return;

Comments?

I don't think I want this. This *can* be solved completely in userspace, the only problem would be that the interface to the userspace program doing it wouldn't be the same as to evdev.c, and that the kernel *dev.c modules could not bind to do it.

Quoted 4 lines

For mice, there is no problem - the mouse protocol can be implemented over a bidirectional pipe.

For making another evdev device, you can use uinput.

Coding a uinput solution brought up this request. Basically there are 2 methods to support 1-button mice:

1. remap 2 keys on the keyboard to middle and right button
2. remap the left mouse button with SHIFT/CTRL/ALT/etc

Currently theres the ugly hack that does 1. in the kernel. Now, just for ease of explanation, lets go with a "clean" kernel module. So I register the module as a handler for keyboard and 1-button mice events and additionally register it as mouse input device. For case 1. I remapped F11 and F12 to middle and right mouse button, I see a F11, and submit a "middle mouse button" event. All nice so far, but how do I prevent F11 and F12 reaching other handlers in the list and potentially confusing the applications? If I implement case 2. the problem is essentially the same, except that I have to prevent the "left mouse button" event to reach other handlers.

If I do it in userspace via uinput the underlying problem remains the same.

Do you have better ideas to solve that in a clean and generic way besides my "filter idea"?