RE: SERIO_USERDEV patch for 2.6

RE: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

Giuseppe Bilotta wrote:
> Dmitry Torokhov wrote:
> > On Tuesday 01 June 2004 05:23 pm, Giuseppe Bilotta wrote:
> > > Dmitry Torokhov wrote:
> > > > echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> > > >
> > > > or something alont these lines. At least that's my grand plan ;)
> > >
> > > I like this kind of idea. Many options should be settable this
> > > way (think for example about Synaptics and ALPS touchpad
> >
> > Yes, exactly, it will allow much more flexible option handling. Still,
> > as far as your examples go:
> >
> > > configurations: whether to use multipointers separately or
> > > together,
> > - userspace task - always persent separate devices and have
application
> >   (GPM or X) multiplex data together.
> 
> Ok, in this case your ALPS patch need a little working ;) (Last
> time I saw it it ORed the touchpad and stick values.)

Yes it needs indeed. I have something here that treats stick as a
mouse on a passthrough port, much like Synaptics driver. It's not
ready for publishing yet though.  

> 
> > > (de)activation of tapping,
> > - may be userspace task - i.e can be done in userspace if device can
> >   report BTN_TOUCH event. If not then kernel has to toggle it.
> 
> > > button remapping etc).
> > - userspace task
> 
> When you say "userspace task", are you saying that the
> filtering out of, say, BTN_TOUCH events should happen at a
> higher level than the kernel driver not reporting them at all?
> Say, in gpm?

Exactly. If you check Peter Osterlund's X driver or my GPM patches
you will see that they get BTN_TOUCH or even ABS_PRESSURE events
and then decide for themselves what should be considered a tap and
what is not. And the logic is not dependent on a particular model
but rather on set of capabilities that device reports.

Kernel task is to convert data from individual devices into unified
representation and userpace task is to do with that data whatever
it wants. X driver does not (should not) care whether a mouse is a
serial or PS/2 or USB. It only wants to know that it reports 2
relative axis motions and has X number of buttons and X number of
wheels.

Now operation of a touchscreen is different from operation of touchpad
which is different from standard mouse and userspace has to distinguish
between these, but that's because they are different classes of input
devices and should be handled [slightly] differently.

--
Dmitry

RE: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Dmitry Torokhov wrote:
> Giuseppe Bilotta wrote:
> > Ok, in this case your ALPS patch need a little working ;) (Last
> > time I saw it it ORed the touchpad and stick values.)
> 
> Yes it needs indeed. I have something here that treats stick as a
> mouse on a passthrough port, much like Synaptics driver. It's not
> ready for publishing yet though.  

Ok, thanks.

> > When you say "userspace task", are you saying that the
> > filtering out of, say, BTN_TOUCH events should happen at a
> > higher level than the kernel driver not reporting them at all?
> > Say, in gpm?
> 
> Exactly. If you check Peter Osterlund's X driver or my GPM patches
> you will see that they get BTN_TOUCH or even ABS_PRESSURE events
> and then decide for themselves what should be considered a tap and
> what is not. And the logic is not dependent on a particular model
> but rather on set of capabilities that device reports.

I see and get the point.

> Kernel task is to convert data from individual devices into unified
> representation and userpace task is to do with that data whatever
> it wants. X driver does not (should not) care whether a mouse is a
> serial or PS/2 or USB. It only wants to know that it reports 2
> relative axis motions and has X number of buttons and X number of
> wheels.
> 
> Now operation of a touchscreen is different from operation of touchpad
> which is different from standard mouse and userspace has to distinguish
> between these, but that's because they are different classes of input
> devices and should be handled [slightly] differently.

I guess the problem with X is that it has to work on a wide 
variety of systems, not all of which expose the same 
capabilities the same way, which is why it has the tendency to 
prefer direct acces ...

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    Vojtech> On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen
    Vojtech> wrote:
    >> Giuseppe Bilotta wrote: >The new system has some ups and
    >> downs. The biggest "down", >which is that of RAW mode not being
    >> available anymore (it's >emulated!) could be circumvented by
    >> having both the RAW and >translated codes move between layers.
    >> 
    >> Ouch! If the user asks for raw mode, he doesn't get it, but
    >> some emulated mode? To me this sounds like a big
    >> incompatibility.

    Vojtech> Q1: What would you do if the user has an USB keyboard?

If he was  raw mode from a  USB keyboard, he should get  the raw data.
Of course, he should know what he's doing.


    Vojtech> Q2: What application should be looking at the raw data
    Vojtech> outside the kernel and why?

What application should be looking at  the raw data from an RS232 port
outside the kernel and why?

Why do you  leave 'efax' in userspace, letting  it read/write raw data
to/from the modem via the RS232?


    >> Fortunately this patch (written together with Sau Dan Lee)
    >> should give _really_ raw mode in 2.6.x too (but it's not
    >> compatible with the raw mode in 2.4.x):
    >> 
    >> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
 
In a nutshell, I hate to be restricted by YOUR own imaginations of how
people should hack  the system.

Raw keyboard  data, for  instance, can be  captured for  analyzing how
people use the  keyboard and coming up with  a more efficient keyboard
layout (c.f. Dvorak).  That's already beyond your imaginations.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 12:39:40PM +0200, Sau Dan Lee wrote:

>     Vojtech> Q1: What would you do if the user has an USB keyboard?
> 
> If he was  raw mode from a  USB keyboard, he should get  the raw data.
> Of course, he should know what he's doing.

The USB communication is not byte-oriented, so that wouldn't work.
Anyway, if we could pass the USB data in some form through the console
in raw mode, this would of course break XFree86, as it wouldn't
understand it.

>     Vojtech> Q2: What application should be looking at the raw data
>     Vojtech> outside the kernel and why?
> 
> What application should be looking at  the raw data from an RS232 port
> outside the kernel and why?

Terminal. Terminals use the data directly. 

Actually it's pretty annoying there isn't a higher level abstraction of
modem than a RS232 port, because when you have a softmodem, the driver
needs to implement a fake RS232 port, including fake RTS/CTS, DSR/DTR
lines, and completely fake AT commands, so that applications that expect
to talk to a RS232 port work with it.

Anyway, the RS232 port is a multi purpose port, where you can attach
many different devices to it. For the keyboard port, there is only one
option, the keyboard. Of course, unless you create a device that can use
it, but in that case you can easily write a kernel driver for it.

> Why do you  leave 'efax' in userspace, letting it read/write raw data
> to/from the modem via the RS232?

Because I draw the line of what is supposed to be in the kernel and what
belongs to userspace on a different place than you. 

>     >> Fortunately this patch (written together with Sau Dan Lee)
>     >> should give _really_ raw mode in 2.6.x too (but it's not
>     >> compatible with the raw mode in 2.4.x):
>     >> 
>     >> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
>  
> In a nutshell, I hate to be restricted by YOUR own imaginations of how
> people should hack  the system.

You're not. You're free to hack the kernel drivers. You can do whatever
you wish. But I also have the option to not use your creations in the
input system.

> Raw keyboard  data, for  instance, can be  captured for  analyzing how
> people use the  keyboard and coming up with  a more efficient keyboard
> layout (c.f. Dvorak).  That's already beyond your imaginations.

The raw data not what you want to use there. You want the keystroke
data, and for that you can use the /dev/input/event interface, where you
get them in a sane format (as opposed to the PS/2 rawmode, which can
send up ot 8 bytes for a single keystroke).

Then your statistic analyser will work just fine even on a Sun, Mac, or
with an USB keyboard.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    Vojtech> Q2: What application should be looking at the raw data
    Vojtech> outside the kernel and why?
    >>  What application should be looking at the raw data from an
    >> RS232 port outside the kernel and why?

    Vojtech> Terminal. Terminals use the data directly.

Now, what prevents people from  connecting terminals to a computer via
the PS/2 mouse port?

There are  mice which can be attached  to both the RS232  port AND the
PS/2 mouse port, needing only  an adaptor.  It should also be possible
to use  a similar technique  to connect a  terminal to the  PS/2 mouse
port.  This would be useful when you run out of RS232 ports.

Your  approach   in  the  input  system  completely   rules  out  this
possibility.


    Vojtech> Anyway, the RS232 port is a multi purpose port, where you
    Vojtech> can attach many different devices to it. For the keyboard
    Vojtech> port, there is only one option, the keyboard. 

What a big assumption.  Yes, I admit that I don't know of any hardware
implementations  that use  the PS/2  (or AT)  keyboard port  for other
purposes.  Maybe there are POS systems like that?


    Vojtech> Of course, unless you create a device that can use it,
    Vojtech> but in that case you can easily write a kernel driver for
    Vojtech> it.

How about  the PS/2 mouse  port?  It's not  just for mice.   There ARE
implementations using it for other things: touchpad, touchscreen, etc.
Your input  driver places that  stupid assumption that there  can't be
other devices  outside your support list  that may use  the PS/2 mouse
port, and  you make the  stupid assumption on  HOW the port  should be
used.  That's within your  imaginations.  You're limiting other people
to  your own  imaginations.   Worse still,  there  are ALREADY  things
beyond your imaginations.



    >> In a nutshell, I hate to be restricted by YOUR own imaginations
    >> of how people should hack the system.

    Vojtech> You're not. You're free to hack the kernel drivers. 

Not everyone using  Linux is patient enough to  explore the Wonderland
of kernel hacking.  Many immigrants from 2.4 are highly disappointed
by the new but incompatible mouse/keyboard behaviours.  Some of them
returned to their 2.4 homeland because of this.

Not every new immigrant are that devoted to make the new country good.
Many simply hop  back to the original country, or  hop to another that
_may_ suit them better.



    >> Raw keyboard data, for instance, can be captured for analyzing
    >> how people use the keyboard and coming up with a more efficient
    >> keyboard layout (c.f. Dvorak).  That's already beyond your
    >> imaginations.

    Vojtech> The raw data not what you want to use there. You want the
    Vojtech> keystroke data,

No.   I want  the  raw bytes.   (That's  also useful  for debugging  a
hardware,  in  case  people  are  making  or  experimenting  with  new
hardware.)


    Vojtech>  and for that you can use the /dev/input/event interface,

But that's polluted  with some (0,0,0) events.  In  some situations, I
NEED the raw, uninterpreted bytes,  much like people liking to watch a
film or read  a book in the *original* language  version, not a dubbed
or translated version.

    Vojtech> where you get them in a sane format (as opposed to the
    Vojtech> PS/2 rawmode, which can send up ot 8 bytes for a single
    Vojtech> keystroke).

Sane != helpful or more useful.

I could study the  I-Ching in English, but I would prefer  to do it in
Chinese.  Now, your  approach is forcing me to do  it in English.  And
you believe that's a good idea.



    Vojtech> Then your statistic analyser will work just fine even on
    Vojtech> a Sun, Mac, or with an USB keyboard.

But it will not be able  to handle the specifics.  (That's the problem
with  generic tools  in  general.  But  you  shouldn't be  restricting
people to only those tools.  Some people have specific needs, and they
should not be ignored.)



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 01:40:03PM +0200, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
> 
>     Vojtech> Q2: What application should be looking at the raw data
>     Vojtech> outside the kernel and why?
>     >>  What application should be looking at the raw data from an
>     >> RS232 port outside the kernel and why?
> 
>     Vojtech> Terminal. Terminals use the data directly.
> 
> Now, what prevents people from  connecting terminals to a computer via
> the PS/2 mouse port?

Their sanity.

Anyway, I don't oppose having the raw data available.

> There are  mice which can be attached  to both the RS232  port AND the
> PS/2 mouse port, needing only  an adaptor.  It should also be possible
> to use  a similar technique  to connect a  terminal to the  PS/2 mouse
> port.  This would be useful when you run out of RS232 ports.

Go ahead and try it. You'll fry your KBD port.

> Your  approach   in  the  input  system  completely   rules  out  this
> possibility.

Not such a big loss.

>     Vojtech> Anyway, the RS232 port is a multi purpose port, where you
>     Vojtech> can attach many different devices to it. For the keyboard
>     Vojtech> port, there is only one option, the keyboard. 
> 
> What a big assumption.  Yes, I admit that I don't know of any hardware
> implementations  that use  the PS/2  (or AT)  keyboard port  for other
> purposes.  Maybe there are POS systems like that?

No. The KBD interface is asymetric, only works on short distances, is
slow, cannot pass arbitrary data through, as it's by default translated
by the keyboard contoller, already assuming it's sending keyboard data,
all in all, it's completely unsuitable for anything else than a
keyboard.

You even cannot connect a mouse over it in the default mode of the port.

>     Vojtech> Of course, unless you create a device that can use it,
>     Vojtech> but in that case you can easily write a kernel driver for
>     Vojtech> it.
> 
> How about  the PS/2 mouse  port?  It's not  just for mice.   There ARE
> implementations using it for other things: touchpad, touchscreen, etc.

All simulate a mouse. Some have somewhat extended protocols, but those
protocols are still bound by mouse packet constraints, because the
controllers tend to do nasty things to the data passing through, like
merging input from multiple devices together into one stream by summing
the packets, etc.

> Your input  driver places that  stupid assumption that there  can't be
> other devices  outside your support list  that may use  the PS/2 mouse
> port, and  you make the  stupid assumption on  HOW the port  should be
> used.  That's within your  imaginations.  You're limiting other people
> to  your own  imaginations.   Worse still,  there  are ALREADY  things
> beyond your imaginations.

No. I'm just saying - if you want something that's not in the kernel
drivers, just write a driver for it. But the driver must be able to
coexist with the other drivers.

Your psaux/userspace serio driver is fine, except it cannot coexist with
the other drivers.

> Not everyone using  Linux is patient enough to  explore the Wonderland
> of kernel hacking.  Many immigrants from 2.4 are highly disappointed
> by the new but incompatible mouse/keyboard behaviours.  Some of them
> returned to their 2.4 homeland because of this.

Life's a change.

Anyway, at least 99% setups just keep working in 2.6.

> Not every new immigrant are that devoted to make the new country good.
> Many simply hop  back to the original country, or  hop to another that
> _may_ suit them better.

That's their freedom to do.

>     >> Raw keyboard data, for instance, can be captured for analyzing
>     >> how people use the keyboard and coming up with a more efficient
>     >> keyboard layout (c.f. Dvorak).  That's already beyond your
>     >> imaginations.
> 
>     Vojtech> The raw data not what you want to use there. You want the
>     Vojtech> keystroke data,
> 
> No.   I want  the  raw bytes.   (That's  also useful  for debugging  a
> hardware,  in  case  people  are  making  or  experimenting  with  new
> hardware.)

Sure. For debugging purposes, yes. But for analyzing the typing
behavior, the abstract data is better.

>     Vojtech>  and for that you can use the /dev/input/event interface,
> 
> But that's polluted  with some (0,0,0) events.  In  some situations, I
> NEED the raw, uninterpreted bytes,  much like people liking to watch a
> film or read  a book in the *original* language  version, not a dubbed
> or translated version.

Polluted. ;) Sorry, they're intentional. They're EV_SYN, SYN_REPORT
events, as you can find in input.h. They inform you that this is the end
of the whole report, which is useful for example for mice, where you
have more than one event (REL_X, REL_Y) per a report. 

The application reading the device is supposed to queue all events up to
the SYN_REPORT event, and then process them, so that a mouse pointer
will move diagonally instead of following the sides of a rectangle,
which would be very annoying.

> 
>     Vojtech> where you get them in a sane format (as opposed to the
>     Vojtech> PS/2 rawmode, which can send up ot 8 bytes for a single
>     Vojtech> keystroke).
> 
> Sane != helpful or more useful.
> 
> I could study the  I-Ching in English, but I would prefer  to do it in
> Chinese.  Now, your  approach is forcing me to do  it in English.  And
> you believe that's a good idea.

In your example, you wanted to study the frequency of keypresses, and
their relations. For that, it's best to ask the kernel to report
keypresses to you.

Should you want to analyze the keyboard protocol, the raw data is the
way to go. But that's been done many times before anyway.

>     Vojtech> Then your statistic analyser will work just fine even on
>     Vojtech> a Sun, Mac, or with an USB keyboard.
> 
> But it will not be able  to handle the specifics.  (That's the problem
> with  generic tools  in  general.  But  you  shouldn't be  restricting
> people to only those tools.  Some people have specific needs, and they
> should not be ignored.)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: keyboard problem with 2.6.6

[Sau Dan Lee]

>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

    >>  How about the PS/2 mouse port?  It's not just for mice.  There
    >> ARE implementations using it for other things: touchpad,
    >> touchscreen, etc.

    Vojtech> All simulate a mouse. 

Yeah.  All can fall back to  PS/2 mouse emulation mode.  But to enable
the extended features,  you need to write to the  port to enable them,
and then interpret the extended data formats.



    Vojtech> No. I'm just saying - if you want something that's not in
    Vojtech> the kernel drivers, just write a driver for it. But the
    Vojtech> driver must be able to coexist with the other drivers.

It's easier to write a mouse  driver in userspace than in kernel.  But
with the  input system  in 2.6, I  am *forced*  to write it  in kernel
space, and  reboot and  reboot and reboot  when it oops.   Writing the
driver in kernel  space, I at most get a segfault.   Plus I cannot use
everything from glibc.  It simply  takes more time and energy to write
a kernel space driver.


    Vojtech> Your psaux/userspace serio driver is fine, except it
    Vojtech> cannot coexist with the other drivers.

That's why I've abandoned it.  It's obsolete.

Our (Tuukka and I) SERIO_USERDEV  patch does work with kernel drivers,
and allow  both kernel  and userland drivers  to coexist.   Again, I'm
disappointed that you still haven't discovered this.


Now, it's time  for you to try our SERIO_USERDEV  patch, plus my crude
userspace atkbd.c and psmouse drivers.


    Vojtech> Anyway, at least 99% setups just keep working in 2.6.

But  not 100%  compatibly.   Mouse  moving twice  as  fast, mouse  not
accelerating, etc.  And  tp4d not working any more.   And touch screen
not working. ...


    Vojtech> The raw data not what you want to use there. You want the
    Vojtech> keystroke data,
    >>  No.  I want the raw bytes.  (That's also useful for debugging
    >> a hardware, in case people are making or experimenting with new
    >> hardware.)

    Vojtech> Sure. For debugging purposes, yes. But for analyzing the
    Vojtech> typing behavior, the abstract data is better.

It depends on  what level I want  to analyze at.  How come  you have a
crystal ball telling you that you know what I want?



    >> I could study the I-Ching in English, but I would prefer to do
    >> it in Chinese.  Now, your approach is forcing me to do it in
    >> English.  And you believe that's a good idea.

    Vojtech> In your example, you wanted to study the frequency of
    Vojtech> keypresses, and their relations. For that, it's best to
    Vojtech> ask the kernel to report keypresses to you.

No.  The kernel has already translated the data.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 03:25:10PM +0200, Sau Dan Lee wrote:
 
>     Vojtech> Your psaux/userspace serio driver is fine, except it
>     Vojtech> cannot coexist with the other drivers.
> 
> That's why I've abandoned it.  It's obsolete.
> 
> Our (Tuukka and I) SERIO_USERDEV  patch does work with kernel drivers,
> and allow  both kernel  and userland drivers  to coexist.   Again, I'm
> disappointed that you still haven't discovered this.

The newest I could find:

linux-2.6.5-userdev.20040507.patch

Known problems:
	- The kernel internal psmouse driver should not be loaded when using
	  user space driver, otherwise the drivers may try to initialize the
	  device into incompatible state.

That's what I call 'cannot coexist with other kernel drivers'.
Coexisting would mean that when someone wants to open the raw device,
the serio layer would disconnect the psmouse driver, and give control to
the raw device instead. I believe that could work.

Anyway, looking at the patch, it's not bad, and it's quite close to what
I was considering to write. I'd like to keep it separate from the
serio.c file, although it's obvious it'll require to be linked to it
statically, because it needs hooks there - it cannot be a regular serio
driver.

> Now, it's time  for you to try our SERIO_USERDEV  patch, plus my crude
> userspace atkbd.c and psmouse drivers.

It's indeed time for me to examine the SERIO_USERDEV patch, and I
should've examined it earlier than now, sorry for that, but I don't need
to test your userspace drivers, as I'm not interested in those.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> 
> Anyway, looking at the patch, it's not bad, and it's quite close to what
> I was considering to write. I'd like to keep it separate from the
> serio.c file, although it's obvious it'll require to be linked to it
> statically, because it needs hooks there - it cannot be a regular serio
> driver.
> 

Do we really have to have this stuff directly in serio? How about being able
to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
separate (serio_raw?) module bind to such ports

Warning - the patch below is not really tested and may not apply to Linus'
tree. 

-- 
Dmitry


===================================================================


ChangeSet@1.1743.7.10, 2004-05-29 22:19:16-05:00, dtor_core@ameritech.net
  Input: i8042 - add kernel parameter to allow mark some of AUX ports
         as raw (SERIO_8042_RAW). This will cause psmouse module ignore
         these ports and will allow bytestream driver serve data to the
         userspace.


 Documentation/kernel-parameters.txt |    2 ++
 drivers/input/serio/i8042.c         |   15 +++++++++++++--
 include/linux/serio.h               |    1 +
 3 files changed, 16 insertions(+), 2 deletions(-)


===================================================================



diff -Nru a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt	2004-05-30 10:08:34 -05:00
+++ b/Documentation/kernel-parameters.txt	2004-05-30 10:08:34 -05:00
@@ -464,6 +464,8 @@
 	i8042.noaux	[HW] Don't check for auxiliary (== mouse) port
 	i8042.nomux	[HW] Don't check presence of an active multiplexing
 			     controller
+	i8042.raw	[HW] Specifies which AUX ports should be marked as raw
+			Format: <aux1>,<aux2>,<aux3>,<aux4>
 	i8042.reset	[HW] Reset the controller during init and cleanup
 	i8042.unlock	[HW] Unlock (ignore) the keylock
 
diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c	2004-05-30 10:08:34 -05:00
+++ b/drivers/input/serio/i8042.c	2004-05-30 10:08:34 -05:00
@@ -52,6 +52,11 @@
 module_param_named(dumbkbd, i8042_dumbkbd, bool, 0);
 MODULE_PARM_DESC(dumbkbd, "Pretend that controller can only read data from keyboard");
 
+static unsigned int i8042_aux_raw[4];
+static unsigned int i8042_aux_raw_nargs;
+module_param_array_named(raw, i8042_aux_raw, bool, i8042_aux_raw_nargs, 0);
+MODULE_PARM_DESC(raw, "Specifies which AUX ports should be marked as RAW");
+
 __obsolete_setup("i8042_noaux");
 __obsolete_setup("i8042_nomux");
 __obsolete_setup("i8042_unlock");
@@ -651,8 +656,9 @@
 		return -1;
 	}
 
-	printk(KERN_INFO "serio: i8042 %s port at %#lx,%#lx irq %d\n",
+	printk(KERN_INFO "serio: i8042 %s port %s at %#lx,%#lx irq %d\n",
 	       values->name,
+	       port->type == SERIO_8042_RAW ? "(raw)" : "",
 	       (unsigned long) I8042_DATA_REG,
 	       (unsigned long) I8042_COMMAND_REG,
 	       values->irq);
@@ -936,6 +942,8 @@
 	sprintf(i8042_mux_names[index], "i8042 Aux-%d Port", index);
 	sprintf(i8042_mux_phys[index], I8042_MUX_PHYS_DESC, index + 1);
 	sprintf(i8042_mux_short[index], "AUX%d", index);
+	if (i8042_aux_raw[index])
+		port->type = SERIO_8042_RAW;
 	port->name = i8042_mux_names[index];
 	port->phys = i8042_mux_phys[index];
 	port->driver = values;
@@ -970,8 +978,11 @@
 				i8042_init_mux_values(i8042_mux_values + i, i8042_mux_port + i, i);
 				i8042_port_register(i8042_mux_values + i, i8042_mux_port + i);
 			}
-		else
+		else {
+			if (i8042_aux_raw[0])
+				i8042_aux_port.type = SERIO_8042_RAW;
 			i8042_port_register(&i8042_aux_values, &i8042_aux_port);
+		}
 	}
 
 	i8042_port_register(&i8042_kbd_values, &i8042_kbd_port);
diff -Nru a/include/linux/serio.h b/include/linux/serio.h
--- a/include/linux/serio.h	2004-05-30 10:08:34 -05:00
+++ b/include/linux/serio.h	2004-05-30 10:08:34 -05:00
@@ -108,6 +108,7 @@
 #define SERIO_PC9800	0x04000000UL
 #define SERIO_PS_PSTHRU	0x05000000UL
 #define SERIO_8042_XL	0x06000000UL
+#define SERIO_8042_RAW	0x07000000UL
 
 #define SERIO_PROTO	0xFFUL
 #define SERIO_MSC	0x01

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:

> On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > 
> > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > I was considering to write. I'd like to keep it separate from the
> > serio.c file, although it's obvious it'll require to be linked to it
> > statically, because it needs hooks there - it cannot be a regular serio
> > driver.
> > 
> 
> Do we really have to have this stuff directly in serio? How about being able
> to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> separate (serio_raw?) module bind to such ports

We don't have to. But it'd be rather convenient to have it. It would
work for all serio ports, not just i8042, etc, etc.

And if kept in a separate file (serio-dev.c), it wouldn't mess up things
too much.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:
> 
> > On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > > 
> > > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > > I was considering to write. I'd like to keep it separate from the
> > > serio.c file, although it's obvious it'll require to be linked to it
> > > statically, because it needs hooks there - it cannot be a regular serio
> > > driver.
> > > 
> > 
> > Do we really have to have this stuff directly in serio? How about being able
> > to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> > separate (serio_raw?) module bind to such ports
> 
> We don't have to. But it'd be rather convenient to have it. It would
> work for all serio ports, not just i8042, etc, etc.
> 
> And if kept in a separate file (serio-dev.c), it wouldn't mess up things
> too much.

I'm starting to get nervous about testing this stuff ... do you 
think it will it make to 2.6.7? :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 06:10:52PM +0200, Giuseppe Bilotta wrote:
> Vojtech Pavlik wrote:
> > On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:
> > 
> > > On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > > > 
> > > > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > > > I was considering to write. I'd like to keep it separate from the
> > > > serio.c file, although it's obvious it'll require to be linked to it
> > > > statically, because it needs hooks there - it cannot be a regular serio
> > > > driver.
> > > > 
> > > 
> > > Do we really have to have this stuff directly in serio? How about being able
> > > to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> > > separate (serio_raw?) module bind to such ports
> > 
> > We don't have to. But it'd be rather convenient to have it. It would
> > work for all serio ports, not just i8042, etc, etc.
> > 
> > And if kept in a separate file (serio-dev.c), it wouldn't mess up things
> > too much.
> 
> I'm starting to get nervous about testing this stuff ... do you 
> think it will it make to 2.6.7? :)
 
No way. ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 06:10:52PM +0200, Giuseppe Bilotta wrote:
> > I'm starting to get nervous about testing this stuff ... do you 
> > think it will it make to 2.6.7? :)
>  
> No way. ;)

Damn! :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Sunday 30 May 2004 10:58 am, Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 10:09:18AM -0500, Dmitry Torokhov wrote:
> 
> > On Sunday 30 May 2004 08:42 am, Vojtech Pavlik wrote:
> > > 
> > > Anyway, looking at the patch, it's not bad, and it's quite close to what
> > > I was considering to write. I'd like to keep it separate from the
> > > serio.c file, although it's obvious it'll require to be linked to it
> > > statically, because it needs hooks there - it cannot be a regular serio
> > > driver.
> > > 
> > 
> > Do we really have to have this stuff directly in serio? How about being able
> > to mark some serio ports as working in raw mode (i8042.raw=0,1,1,0) and have
> > separate (serio_raw?) module bind to such ports
> 
> We don't have to. But it'd be rather convenient to have it. It would
> work for all serio ports, not just i8042, etc, etc.
> 
> And if kept in a separate file (serio-dev.c), it wouldn't mess up things
> too much.
> 

Well, my argument is that we only have immediate need for raw access to 
PC-style AUX ports because of wide variety of connected devices. Serial
ports have other historical means of accessing them, busmice ports have
well known devices attached.

Once we have sysfs integration in place I imagine we will be able to
implement dynamic binding of serio drivers and ports, atkbd and psmouse
being default ones and user will be able to rebind a specific port to
let's say serio-raw or some other driver that does not have automatic
hardware detection yet.

But in the meantime marking several ports raw will allow most of the users
use old means of communicating with their pointing devices without too
much effort.
 
-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 11:16:31AM -0500, Dmitry Torokhov wrote:

> Well, my argument is that we only have immediate need for raw access to 
> PC-style AUX ports because of wide variety of connected devices. Serial
> ports have other historical means of accessing them, busmice ports have
> well known devices attached.

Busmice don't even have a byte-oriented protocol, so they're not
relevant here, and indeed for serial ports we can use ttyS.

Now there are a few drivers for the KBD/AUX interface that are not
i8042-based - most drivers in the serio directory. Those all would need
to be patched for enabling raw mode.

> Once we have sysfs integration in place I imagine we will be able to
> implement dynamic binding of serio drivers and ports, atkbd and psmouse
> being default ones and user will be able to rebind a specific port to
> let's say serio-raw or some other driver that does not have automatic
> hardware detection yet.

If we can do that reasonably easily via sysfs, then I'm all for that
route.

> But in the meantime marking several ports raw will allow most of the users
> use old means of communicating with their pointing devices without too
> much effort.

It'd be good to find out what devices we don't support yet (I know of
ALPS, which we have a patch pending for and IBM TouchPoints), too. 

As an interim solution, your patch plus a simple serio->userspace driver
would work, too.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Sunday 30 May 2004 03:51 pm, Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 11:16:31AM -0500, Dmitry Torokhov wrote:
> 
> > But in the meantime marking several ports raw will allow most of the users
> > use old means of communicating with their pointing devices without too
> > much effort.
> 
> It'd be good to find out what devices we don't support yet (I know of
> ALPS, which we have a patch pending for and IBM TouchPoints), too. 
> 

Sau Dan Lee's Lifebook touchscreen ;) The data processing seems to be
trivial, but I don't have any idea how to detect it. And without being
able to explicitly control binding for a specific serio port its hard
to do drivers for hardware that we can't autodetect. We just have to
assume that device behind a port is of specific type and when there
are many ports its usually wrong.
 
> As an interim solution, your patch plus a simple serio->userspace driver
> would work, too.
> 

-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 06:50:48PM -0500, Dmitry Torokhov wrote:

> > > But in the meantime marking several ports raw will allow most of the users
> > > use old means of communicating with their pointing devices without too
> > > much effort.
> > 
> > It'd be good to find out what devices we don't support yet (I know of
> > ALPS, which we have a patch pending for and IBM TouchPoints), too. 
> > 
> 
> Sau Dan Lee's Lifebook touchscreen ;) The data processing seems to be
> trivial, but I don't have any idea how to detect it. And without being
> able to explicitly control binding for a specific serio port its hard
> to do drivers for hardware that we can't autodetect. We just have to
> assume that device behind a port is of specific type and when there
> are many ports its usually wrong.

Conclusion: We need sysfs, and we need it soon.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SERIO_USERDEV patch for 2.6

[Tuukka Toivonen]

On Sun, 30 May 2004, Vojtech Pavlik wrote:

>The newest I could find:
>linux-2.6.5-userdev.20040507.patch

Yes, it's still the newest. Applies cleanly against 2.6.6 too.
I didn't want to add features before getting some feedback.

>Coexisting would mean that when someone wants to open the raw device,
>the serio layer would disconnect the psmouse driver, and give control to
>the raw device instead. I believe that could work.

If the user is careful, in practice both kernel and userspace drivers
can work simultaneously with the current code. But if you prefer otherwise,
I'll change it, no problem. However, this could take a few days
or so (busy with real work).

Dmitry suggested adding a kernel parameter to specify which ports would
allow to be read in raw mode and which would be handled by kernel drivers.
In my opinion, almost the same is achieved more conveniently by handling
in raw mode simply exactly those ports that are opened from userspace
(ie. "cat serio1" would disconnect kernel driver), and everything else by
kernel drivers.
No additional parameters would be then necessary, nor module reloads
to change anything.

The only exception I can see is if the kernel driver is loaded first
and its autodetection confuses a device. Or, for example, kernel
driver sets Touchpad into its custom mode, but then user wants to run
standard PS/2 mouse driver in user space. I don't know if the latter
driver could reset the Touchpad back into PS/2 mouse emulation mode.

>I'd like to keep it separate from the
>serio.c file, although it's obvious it'll require to be linked to it
>statically, because it needs hooks there

Agreed. I'll do that (serio-dev.c). Disadvantage: the functions
can not be anymore inline (unless I put lots of stuff into header
file) which may make code less efficient. Hopefully not significantly.

Also, I have to rename serio.c into serio-core.c so that it can be linked
into serio.o with serio-dev.o. The diff will be a bit ugly.

>It's indeed time for me to examine the SERIO_USERDEV patch, and I

Thanks for that :)

>I don't need to test your [San Dan Lee's] userspace drivers,
>as I'm not interested in those.

Fair enough. Just provide a mechanism that allows user space
protocol drivers, and let other people do them if they insist ;)

Re: SERIO_USERDEV patch for 2.6

[Sau Dan Lee]

    Tuukka> Dmitry suggested adding a kernel parameter to specify
    Tuukka> which ports would allow to be read in raw mode and which
    Tuukka> would be handled by kernel drivers.

That means changes have to be made to ALL drivers.  That looks "ugly".


    Tuukka> In my opinion, almost the same is achieved more
    Tuukka> conveniently by handling in raw mode simply exactly those
    Tuukka> ports that are opened from userspace (ie. "cat serio1"
    Tuukka> would disconnect kernel driver), and everything else by
    Tuukka> kernel drivers.  No additional parameters would be then
    Tuukka> necessary, nor module reloads to change anything.

I have a suggestion using sysfs or procfs:

In some directory (e.g. /proc/input/serio):

        unbound_ports/  (contains a pseudo file for each serio port
                         that is not attached to any device yet)
        keyboards/      (contains a pseudo file for each serio port
                         that is attached to the keyboard device)
        mice/           (contains a pseudo file for each serio port
                         attached to mousedev.ko)
        touchscreens/   (contains a pseudo file for each serio port
                         attached to tsdev.ko)
        direct/         (contains a pseudo file for each serio port
                         that is exposed to userland (currently via "misc")
                         directly, RAW)
etc.  The contents of the pseudo files are unimportant.  (We could use
it to show useful info, though.)

Initially,  all  serio  ports  have  their  corresponding  pseudofiles
created   under   "unbound_ports".   When   a   serio  device   module
(e.g. mousedev) is loaded,  the module, in the current implementation,
will attach all mouse device  to it.  So, the corresponding entries in
"unbound_ports/" will be moved to "mice/".

If we now  want the PS AUX port  to be accessed directly, we  do a "mv
unbound_ports/isa0060.serio1 direct/".   The serio port isa0060/serio1
will   then   be  detached   from   mousedev.ko   and  reattached   to
SERIO_USERDEV,  which then  creates  /dev/misc/isa0060.serio1 for  raw
access.   Similarly,  the  user  can  "mv" any  device  between  these
directories.  Moving  it to "unbound_ports" disconnects  the port from
any device.  This userland interface should be doable!

If  I   try  to  "mv   unbound_ports/isa0060.serio1  keyboards/",  the
operation should fail because  the keyboard device cannot handle ports
connected  to  mice.  An  "rm  mice/isa0060.serio1"  should either  be
forbidden, or  be automatically translated  to "mv mice/isa0060.serio1
unbound_ports/".


Advantage: currently, the  binding of serio ports to  serio devices is
basically hardcoded  into the serio  device modules.  The  user cannot
override anything.  This is very  inflexible.  (It'd be nice it add an
option so  that they don't  attach to any  ports, leaving the  task to
some start-up scripts, which do "mv" in that proc directory.)  Suppose
that  tomorrow, someone  comes  up with  a  mousedev2.ko with  special
features that  mousedev.ko doesn't provide.  Moreover, he  has 2 mice,
and wants to attach one  to mousedev.ko and the other to mousedev2.ko.
Now,  using this  proc/sysfs  interface, he  has  complete freedom  to
attach any mouse to any serio device module.  (Without this, he has to
write mousedev2.ko  in a way  so that it  only attaches to one  of his
mice, and load this moudle before mousedev.ko, so that mousedev2 grabs
the desired mouse before mousedev steals all the two mice.)

A  similar  interface  can  also  be  used  for  fine-controlling  the
connection between input devices and input handlers.




    >> I'd like to keep it separate from the serio.c file, although
    >> it's obvious it'll require to be linked to it statically,
    >> because it needs hooks there

    Tuukka> Agreed. I'll do that (serio-dev.c). Disadvantage: the
    Tuukka> functions can not be anymore inline (unless I put lots of
    Tuukka> stuff into header file) which may make code less
    Tuukka> efficient. Hopefully not significantly.

I've also  though about separating SERIO_USERDEV into  a separate file
during the development and testing of that patch.  Like both of you, I
realized that  it is difficult to  do, because it  requires many hooks
deep into the  guts of serio.c.  Moreover, we  would need the #ifdef's
anyway,  if we  want  to  make the  USERDEV  an optional  compile-time
feature.  So, ...

The separate file doesn't have  to be linked statically.  We could use
function pointer  (i.e. hooks) variables,  or a SINGLE pointer  to one
structure  containing  func.   pointers  to  all  required  functions.
Initially, these are NULL, and serio.c would check this before calling
the hooks.  After loading the "serio_userdev" module, the module would
set these  pointers to its  functions.  Then, serio.c will  call these
functions.  These function pointers can  be removed with #if's to save
space when we  don't want the USERDEV feature  during compilation.  Of
course, the  world is not  that ideal.  There are  concurrency issues,
and we need  to keep track of which  _existing_ ports are userdev-ized
and  which aren't.   Moreover,  one more  level  of indirection  means
reduced efficiency.  I don't think it worths these complications.



BTW,   Tuukka,   I   suggest   renaming   the   "isa0060/serio?"    to
"isa0060.serio?".  The  reason is that the old  names are incompatible
with  sysfs.  I  just played  around with  sysfs, and  found something
funny:  

        $ ls /sys/class/misc
        isa0060/serio0  isa0060/serio1

        $ ls /sys/class/misc/isa0060
        ls: /sys/class/misc/isa0060: No such file or directory

This is  due to  a "/" in  the filename "isa0060/serio0",  which rests
under /sys/class/misc/.

(Should  this be  considered  a  sysfs bug?   Anyway,  renaming it  to
"isa0060.serio0" can avoid the problem.)



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Tuesday 01 June 2004 11:50 am, Sau Dan Lee wrote:
> 
>     Tuukka> Dmitry suggested adding a kernel parameter to specify
>     Tuukka> which ports would allow to be read in raw mode and which
>     Tuukka> would be handled by kernel drivers.
> 
> That means changes have to be made to ALL drivers.  That looks "ugly".

That is only an interim solution that will be used until we have proper
sysfs support and are able to re-bind a specific driver to a specific
port. And it seems that only i8042 needs to be changed. As I said before
serial ports still accessible via /dev/ttySx, and other architectures that
provide access to SERIO_8042 type ports have much less diverse set of
peripherials... The changes can be made on as-needed basis.

So the cons of my proposal:
- Drivers need to be modified but changes are very limited.

Pros of my proposal:
- Completely non-intrusive as far as serio subsystem goes.
- The rawdev serio driver can still be used later when we have sysfs.

> 
> 
>     Tuukka> In my opinion, almost the same is achieved more
>     Tuukka> conveniently by handling in raw mode simply exactly those
>     Tuukka> ports that are opened from userspace (ie. "cat serio1"
>     Tuukka> would disconnect kernel driver), and everything else by
>     Tuukka> kernel drivers.  No additional parameters would be then
>     Tuukka> necessary, nor module reloads to change anything.
>
> I have a suggestion using sysfs or procfs:
> 
> In some directory (e.g. /proc/input/serio):
> 
>         unbound_ports/  (contains a pseudo file for each serio port
>                          that is not attached to any device yet)
>         keyboards/      (contains a pseudo file for each serio port
>                          that is attached to the keyboard device)
>         mice/           (contains a pseudo file for each serio port
>                          attached to mousedev.ko)
>         touchscreens/   (contains a pseudo file for each serio port
>                          attached to tsdev.ko)
>         direct/         (contains a pseudo file for each serio port
>                          that is exposed to userland (currently via "misc")
>                          directly, RAW)
> etc.  The contents of the pseudo files are unimportant.  (We could use
> it to show useful info, though.)
> 
> Initially,  all  serio  ports  have  their  corresponding  pseudofiles
> created   under   "unbound_ports".   When   a   serio  device   module
> (e.g. mousedev) is loaded,  the module, in the current implementation,
> will attach all mouse device  to it.  So, the corresponding entries in
> "unbound_ports/" will be moved to "mice/".
> 
> If we now  want the PS AUX port  to be accessed directly, we  do a "mv
> unbound_ports/isa0060.serio1 direct/".   The serio port isa0060/serio1

Using mv would be implementation trouble, i would rahter do:

echo "rawdev" > /sys/bus/serio/devices/serio0/driver

or something alont these lines. At least that's my grand plan ;)

-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Dmitry Torokhov wrote:
> echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> 
> or something alont these lines. At least that's my grand plan ;)

I like this kind of idea. Many options should be settable this 
way (think for example about Synaptics and ALPS touchpad 
configurations: whether to use multipointers separately or 
together, (de)activation of tapping, button remapping etc).

Yes, we need sysfs ...

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: SERIO_USERDEV patch for 2.6

[Dmitry Torokhov]

On Tuesday 01 June 2004 05:23 pm, Giuseppe Bilotta wrote:
> Dmitry Torokhov wrote:
> > echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> > 
> > or something alont these lines. At least that's my grand plan ;)
> 
> I like this kind of idea. Many options should be settable this 
> way (think for example about Synaptics and ALPS touchpad 

Yes, exactly, it will allow much more flexible option handling. Still,
as far as your examples go: 

> configurations: whether to use multipointers separately or 
> together,
- userspace task - always persent separate devices and have application
  (GPM or X) multiplex data together.

> (de)activation of tapping,
- may be userspace task - i.e can be done in userspace if device can
  report BTN_TOUCH event. If not then kernel has to toggle it.

> button remapping etc).  
- userspace task

-- 
Dmitry

Re: SERIO_USERDEV patch for 2.6

[Giuseppe Bilotta]

Dmitry Torokhov wrote:
> On Tuesday 01 June 2004 05:23 pm, Giuseppe Bilotta wrote:
> > Dmitry Torokhov wrote:
> > > echo "rawdev" > /sys/bus/serio/devices/serio0/driver
> > > 
> > > or something alont these lines. At least that's my grand plan ;)
> > 
> > I like this kind of idea. Many options should be settable this 
> > way (think for example about Synaptics and ALPS touchpad 
> 
> Yes, exactly, it will allow much more flexible option handling. Still,
> as far as your examples go: 
> 
> > configurations: whether to use multipointers separately or 
> > together,
> - userspace task - always persent separate devices and have application
>   (GPM or X) multiplex data together.

Ok, in this case your ALPS patch need a little working ;) (Last 
time I saw it it ORed the touchpad and stick values.)

> > (de)activation of tapping,
> - may be userspace task - i.e can be done in userspace if device can
>   report BTN_TOUCH event. If not then kernel has to toggle it.

> > button remapping etc).  
> - userspace task

When you say "userspace task", are you saying that the 
filtering out of, say, BTN_TOUCH events should happen at a 
higher level than the kernel driver not reporting them at all? 
Say, in gpm?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)