Re: [patch] ignore trackpad/mouse while typing

On Mon, Jan 27, 2003 at 10:49:24PM +0100, Franz Sirl wrote:

On Monday 27 January 2003 20:25, Vojtech Pavlik wrote:

quoted

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

quoted

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/