lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
/
SubjectRe: /dev/psaux-Interface
FromSau Dan Lee <>
Date21 Apr 2004 09:15:53 +0200
>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:

    Dmitry> Also I do not see where the code makes sure that it does
    Dmitry> not bind to keyboard's port (so keyboard driver has to be
    Dmitry> loaded first).
    >>  Ask the people who wrote i8042.c and serio.c to document the
    >> interface.  I simply copied the necessary stuff from
    >> psmouse-base.c.  If that psmouse.ko works, then why should my
    >> psaux fail?

    Dmitry> Because if you look in psmouse_probe we actually check if
    Dmitry> there is a mouse behing the port.

Such probing can  only detect my touchscreen (and  many other devices)
as a PS2 mouse, due to  hardware emulation.  Why would I use Linux 2.6
if my touchscreen is degenerated into a mouse-emulating device?


    >> Adding the complexity of various devices and protocols into
    >> kernelspace is insane.

    Dmitry> The thing is that processing in kernel space is not that
    Dmitry> complex.

Even so,  it's not easy to  get it right.  In  kernel programming, you
have to take  care of many issues, such as whether  you have a process
context, when to  use spinlock, wait queues, etc.  I  even had to care
about fasync() when developing the psaux module, even though it's just
copying a few lines of sample code from the kernel hacking guide.

If it  were in user space,  it would be  simpler: I just need  to open
/dev/psaux  (a la  2.4, 2.2,  2.0, 1.0.32(?)),  block-reading  a byte,
modify  the state  of  my state  machine  in the  program, and  output
something to  a repeater device  when needed.  No SMP  issues, fasync,
etc   (assuming  /dev/psaux   and   the  repeater   device  do   those
automagically).


    Dmitry> The only thing  kernel has to do is to  parse raw data and
    Dmitry> convert to events.

Unfortunately,  it loses  data during  the conversion.   Moreover, the
current  /dev/psaux in  standard  2.6 kernel  DOES  NOT ALLOW  writing
command bytes  to the  PS2/AUX port, preventing  me from  enabling the
touchscreen behaviour  (disabling mouse emulation)  without any kernel
programming.  That's stupid.

IOW, the 2.6 kernel is implementing a policy, taking away flexibility.


    Dmitry> We have such thing - look at uinput module - it can be
    Dmitry> used to feed events back into the kernel.

There is still no provision for a userspace program to talk to the PS2
AUX port *directly*.  I don't want  my commands to be censored and the
data be translated.


-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:02    [from the cache]
©2003-2008