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

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

[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

[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

[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

[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

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

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

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

[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

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