[patch] ignore trackpad/mouse while typing

[patch] ignore trackpad/mouse while typing

[Till Straumann]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

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.

[-- Attachment #2: mouse_holdoff.patch --]
[-- Type: text/plain, Size: 3682 bytes --]

This is a patch for linux-2.4.18

Author: Till Straumann <strauman@slac.stanford.edu>

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;

+ 	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)
+
+ 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)
+ 	mouse_holdoff_header = register_sysctl_table(mouse_holdoff_root_dir, 1);
+ #endif
  	return 0;
  }

  static void __exit input_exit(void)
  {
+ #if defined(CONFIG_SYSCTL)
+ 	unregister_sysctl_table(mouse_holdoff_header);
+ #endif
  	devfs_unregister(input_devfs_handle);
          if (devfs_unregister_chrdev(INPUT_MAJOR, "input"))
                  printk(KERN_ERR "input: can't unregister char major %d", INPUT_MAJOR);

Re: [patch] ignore trackpad/mouse while typing

[Ethan Benson]

On Thu, Nov 28, 2002 at 05:34:32PM -0800, Till Straumann wrote:
>
>     /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.

why didn't you just use the mac_hid/ node to hold your
mouse_holdoff_ms node?

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Michel Dänzer]

On Fre, 2002-11-29 at 02:34, Till Straumann wrote:

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


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Till Straumann]

Michel Dänzer wrote:
> On Fre, 2002-11-29 at 02:34, Till Straumann wrote:
>
>
>>+ 		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.
>
>
No: if no key is pressed for (any integer multiple of) 2^32 jiffies then
mouse events are ignored during a short period of time following the
rollover ;-)
[ i.e. the rollover of the difference, not the jiffies; the true
   relation being
    (jiffies - mouse_holdoff_last_jiffie) % 2^32 < mouse_holdoff_jiffies
]

Anyways: the patch has another problem: the trivial version cannot deal
with

  - emulated mouse buttons (ignored because input_event() first receives
    a key event which is sent to the keyboard handler who remaps it to a
    mouse/button event to be ignored since it happens shortly after the
    key event triggering it)
  - 'modifiers' (Shift, Ctrl & friends). All keys seem to be
    'auto-repeated' by the input driver resulting in repeated
    key events while a modifier is pressed, hence causing the trivial
    patch to ignore mouse events while a modifier key is held down.

I'm working on an improved version supporting a (configurable but
reasonably defaulted) list of keys who are to be considered 'modifiers'.

-- Till


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Vojtech Pavlik]

On Thu, Nov 28, 2002 at 05:34:32PM -0800, Till Straumann wrote:
> 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 ...

> -- 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 <strauman@slac.stanford.edu>
>
> 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;
>
> + 	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)
> +
> + 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)
> + 	mouse_holdoff_header = register_sysctl_table(mouse_holdoff_root_dir, 1);
> + #endif
>   	return 0;
>   }
>
>   static void __exit input_exit(void)
>   {
> + #if defined(CONFIG_SYSCTL)
> + 	unregister_sysctl_table(mouse_holdoff_header);
> + #endif
>   	devfs_unregister(input_devfs_handle);
>           if (devfs_unregister_chrdev(INPUT_MAJOR, "input"))
>                   printk(KERN_ERR "input: can't unregister char major %d", INPUT_MAJOR);


--
Vojtech Pavlik
SuSE Labs

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Till Straumann]

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

On Saturday, January 25, 2003, at 10:25 , Benjamin Herrenschmidt wrote:

> On Sat, 2003-01-25 at 22:04, Vojtech Pavlik wrote:
>
>>>> 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.

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

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

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Benjamin Herrenschmidt]

On Sat, 2003-01-25 at 18:47, Vojtech Pavlik wrote:
> On Thu, Nov 28, 2002 at 05:34:32PM -0800, Till Straumann wrote:
> > 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 ...

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.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[George Staikos]

On Saturday 25 January 2003 14:04, Benjamin Herrenschmidt wrote:
> On Sat, 2003-01-25 at 18:47, Vojtech Pavlik wrote:
> > On Thu, Nov 28, 2002 at 05:34:32PM -0800, Till Straumann wrote:
> > > 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 ...
>
> 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).

--

George Staikos


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Vojtech Pavlik]

On Sat, Jan 25, 2003 at 03:58:30PM -0500, George Staikos wrote:
> On Saturday 25 January 2003 14:04, Benjamin Herrenschmidt wrote:
> > On Sat, 2003-01-25 at 18:47, Vojtech Pavlik wrote:
> > > On Thu, Nov 28, 2002 at 05:34:32PM -0800, Till Straumann wrote:
> > > > 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 ...
> >
> > 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?

--
Vojtech Pavlik
SuSE Labs

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Benjamin Herrenschmidt]

On Sat, 2003-01-25 at 22:04, Vojtech Pavlik wrote:

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

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.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Vojtech Pavlik]

On Sat, Jan 25, 2003 at 10:25:56PM +0100, Benjamin Herrenschmidt wrote:

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

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

I don't think you can do much better than sysctl or module parameters in 2.4.

--
Vojtech Pavlik
SuSE Labs

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Vojtech Pavlik]

On Sat, Jan 25, 2003 at 07:04:27PM +0100, Till Straumann wrote:
> 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.)

You convinced me that this probably needs to be in the kernel - though
the real-time nature of it is not a good argument - we have timestamps
in the events, and thus we could sort it out in the userspace quite as
well.

But still for ease of use, so that applications see the already
processed events, it makes sense to have it in kernel.

But still I think the proper place for it (and the emulated mouse
buttons from mac-hid) is mousedev.c. At this moment it doesn't receive
keyboard events, but it trivially could. Then you'll have all the info
you need there.

Then you won't need to filter emulated/real keystrokes, since you'd
generate the emulated ones in the same source file.

/dev/input/evdev devices will still offer unprocessed events, though.

This means:

	1) For existing applications we get the needed functionality.
	   (Emulated buttons, ignoring events from mouse when keyboard
	    is in use, ...)

	2) For applications that will be ported to use the event
	   interface, they'll need to implement the emulated buttons
	   and filtering themselves. This also makes sense. X already
	   emulates the middle button for 2-button mice anyway.

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

Aww, poor you. Hope you'll recover your computer soon.

> :-(
>
> Regards
> -- Till
>
> PS: I added a few comments to the discussion below
>
> On Saturday, January 25, 2003, at 10:25 , Benjamin Herrenschmidt wrote:
>
> > On Sat, 2003-01-25 at 22:04, Vojtech Pavlik wrote:
> >
> >>>> 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.
>
> >>>
> >>>   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.
>
> > 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?
>
> > 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.
> >
> >

--
Vojtech Pavlik
SuSE Labs

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Franz Sirl]

On Saturday 25 January 2003 22:29, Vojtech Pavlik wrote:
> On Sat, Jan 25, 2003 at 10:25:56PM +0100, Benjamin Herrenschmidt wrote:
> > > > > 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?
> >
> > 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?

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Vojtech Pavlik]

On Mon, Jan 27, 2003 at 08:16:24PM +0100, Franz Sirl wrote:

> On Saturday 25 January 2003 22:29, Vojtech Pavlik wrote:
> > On Sat, Jan 25, 2003 at 10:25:56PM +0100, Benjamin Herrenschmidt wrote:
> > > > > > 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?
> > >
> > > 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?

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Till Straumann]

On Monday, January 27, 2003, at 08:25 , Vojtech Pavlik wrote:

> On Mon, Jan 27, 2003 at 08:16:24PM +0100, Franz Sirl wrote:
>
>> On Saturday 25 January 2003 22:29, Vojtech Pavlik wrote:
>>> On Sat, Jan 25, 2003 at 10:25:56PM +0100, Benjamin Herrenschmidt
>>> wrote:
>>>>>>> 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?
>>>>
>>>> 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?
>
> I don't think I want this. This *can* be solved completely in userspace,

It can, but at the expense of 2 context switches per event if you run
a filter program in user space.

-- Till.

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Franz Sirl]

On Monday 27 January 2003 20:25, Vojtech Pavlik wrote:
> On Mon, Jan 27, 2003 at 08:16:24PM +0100, Franz Sirl wrote:
> > 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?
>
> 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.

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

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [patch] ignore trackpad/mouse while typing

[Vojtech Pavlik]

On Mon, Jan 27, 2003 at 10:49:24PM +0100, Franz Sirl wrote:
> On Monday 27 January 2003 20:25, Vojtech Pavlik wrote:
> > On Mon, Jan 27, 2003 at 08:16:24PM +0100, Franz Sirl wrote:
> > > 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?
> >
> > 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.
>
> 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"?

Idea 1:	Implement a input_grab() function and ioctl for evdev that'd
stop passing any events to anyone else than the handler who called it.
This would allow userspace programs to do a grab() as well. Not much
better than your filter idea, though.

Idea 2: Leave the devices sending events to everyone, but configure the
handlers to only connect to the correct devices. This would be best,
however, since keyboard.c automatically listens to every keyboard and
/dev/input/mice to every mouse, it is next to impossible.

Idea 3: Someone suggested that handlers should have a priority value and
be passed events from the top priority to bottom, where any of them
could say 'don't pass to others'. This, however doesn't work too well if
you have two such filters which both want 'top priority'.


I think I'll implement 1, but still I'm reluctant to do it, since I
believe 2 would be the correct one.

--
Vojtech Pavlik
SuSE Labs

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/