On Monday April 19, [email protected] wrote:
>
> > No. That's not a problem specific with my touchscreen. It's a
> > general problem with the design of the input layer. It is
> > implementing *policies* (on how to interpret data read from the
> > PS2/AUX port), instead of providing a *mechanism* to access (read and
> > write) that port.
>
> well, it's the kernels job to abstract hardware. You don't also expose
> raw scsi and ide devices to userspace, you abstract them away and
> provide a uniform "block device" interface to userspace.
> The input layer tries to do the same wrt HID devices and imo it makes
> sense. Why should userspace care if a mouse is attached to the USB port
> or via the USB->PS/2 connector thingy to the PS/2 port. Requiring
> different configuration for both cases, and potentially even requiring
> different userspace applications for each type make it sound like
> abstracting this away from userspace does have merit.
I agree that it is good for the kernel to provide hardware
abstractions, and that "mouse" is an appropriate device to provide an
abstract interface for.
It does not follow that all drivers below that abstraction should live
in the kernel.
Some drivers should live in the kernel, some shouldn't. Issues such
as performance and multiple access tend to suggest whether a driver
needs to be in the kernel.
I don't believe that the driver for a mouse device needs to be in the
kernel for performance reasons or for shared access reasons.
The input layer has a "uinput" module that allows a user-space program
to act as an input-layer device.
I have a userspace program that talks to my ALPS touchpad (through a
hacked /dev/psaux that talks direct to the psaux port) and converts
taps etc into "input layer" messages that are passed back into
/dev/input/uinput.
Thus "user-space" - my X server - just reads from /dev/input/mice and
doesn't care what sort of mouse there is, as you suggest.
But "user-space" - my ALPS touchpad handler - does care that my
"mouse" is an ALPS dual-point touchpad and does the appropriate thing.
I did consider writing a kernel driver for the ALPS touchpad, but due
to the dearth of documentation and the fact that it seemed very hard
to automatically detect it, I decided that such a driver would be too
hard to support.
So here is my vote in favour of "Let's make /dev/psaux a clean channel
to the PS/AUX device" - at least conditionally.
NeilBrown
>>>>> "Neil" == Neil Brown <[email protected]> writes:
Neil> I agree that it is good for the kernel to provide hardware
Neil> abstractions, and that "mouse" is an appropriate device to
Neil> provide an abstract interface for.
So, the next step is to port efax or Hylafax into kernel space. Why
leave the /dev/ttyS? hanging out there? Why not encapsulated them and
provide a /dev/fax that does what efax or Hylafax do?
And then, it's time to port Ghostscript and lpd into the kernel. Why
leave the raw /dev/lp0 there? Why not move abstract them and provide
a /dev/postscript_printer instead? Why lpd? Have a virtual
filesystem pqfs, so that we can easily copy postscript files to that
fs (instead of lpr), use ls to inspect what print jobs are there
(instead of lpq) and use rm to remove pending jobs (instead of lprm)?
Neil> It does not follow that all drivers below that abstraction
Neil> should live in the kernel.
Exactly! Look at autofs and nfs. The respective daemons are in
userland (I know there is knfsd -- as a OPTION). Why? Why not move
them into the kernel altogether? What's the advantage of implementing
these daemons in userland? That's exactly the advantage of handling
mouse protocol using a gpm-like program.
Neil> I have a userspace program that talks to my ALPS touchpad
Neil> (through a hacked /dev/psaux that talks direct to the psaux
Neil> port) and converts taps etc into "input layer" messages that
Neil> are passed back into /dev/input/uinput.
That's what I have in mind: have a userland daemon that bridges
between the raw port and uinput. This leaves great flexibility for
the daemon to do whatever the writer feel appropriate. I hope you
agree that it is easier to develop and debug programs in userland and
in kernel space. Providing API for such a daemon would provide
fertile soil for people to implement different useful things.
BTW, how did you hack the /dev/psaux?
Neil> I did consider writing a kernel driver for the ALPS
Neil> touchpad, but due to the dearth of documentation and the
Neil> fact that it seemed very hard to automatically detect it, I
Neil> decided that such a driver would be too hard to support.
So, writing userland programs are generally easier than having to
touch the kernel -- even when you're just writing a module. A daemon
that seg-faults doesn't hurt. A daemon that runs into infinite loops
can be killed. It's much safer and easier to implement the mouse
protocol interpreter in userland. And I guess 'gpm' and its dozens of
drivers can be more easily transformed into a bridge between
/dev/psaux or /dev/ttyS? (or even a TCP/UDP socket!) and uinput. I'll
bet on gpm, given its maturity vs. the kernel 2.6 mouse drivers.
Neil> So here is my vote in favour of "Let's make /dev/psaux a
Neil> clean channel to the PS/AUX device" - at least
Neil> conditionally.
I second! Let's free /dev/psaux. We want the /dev/psaux as in 2.4,
2.2, 2.0, ... We don't want a faked, censored one as in 2.6.0--5.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
Quite heated discussion, which is why I've avoided it =) But just to
clarify my intentions... Dmitry raised some valid issues about the problems
in the current version of psaux driver. I might try fixing some/all of
them, however I believe I got a better idea.
On Wed, 21 Apr 2004, Sau Dan Lee wrote:
>I second! Let's free /dev/psaux. We want the /dev/psaux as in 2.4,
>2.2, 2.0, ... We don't want a faked, censored one as in 2.6.0--5.
We shouldn't want _the_ /dev/psaux, but something similar, possibly
better. What I'm after (and probably Sau Dan Lee too) is direct access to
at least psaux-port.
My idea is to modify serio to expose all (or at least all unconnected)
ports into userspace, where programs can write/read them just like the
/dev/psaux before. Then it's just matter of symlinking /dev/psaux into
correct device.
The biggest problem as I see is that this is much more intrusive change and
a standalone kernel driver (as psaux.ko currently is) is impossible.
I'll be back when I have some code, before that, all suggestions are
welcome (special thanks for Dmitry for insights).
>>>>> "Tuukka" == Tuukka Toivonen <[email protected]> writes:
Tuukka> We shouldn't want _the_ /dev/psaux, but something similar,
Tuukka> possibly better. What I'm after (and probably Sau Dan Lee
Tuukka> too) is direct access to at least psaux-port.
Right!
Tuukka> My idea is to modify serio to expose all (or at least all
Tuukka> unconnected) ports into userspace, where programs can
Tuukka> write/read them just like the /dev/psaux before. Then it's
Tuukka> just matter of symlinking /dev/psaux into correct device.
Good suggestion.
Actually, I have a side issue with input/i8042 related things: The
keyboard on my laptop worked slightly different: On 2.4.*, SysRq is
activated using a [Fn] key-combo, which agrees with the keycap labels
on the laptop keyboard. After upgrading to 2.6, that key-combo no
longer works. Instead, I must use Alt-PrintScreen as the key for
SysRq. (And unfortunately, PrintScreen is a [Fn] combo on the laptop,
thus requiring press 3 keys at the same time for SysRq, and a fourth
key to use the various SysRq features. Very inconvenient.) Is this
again due to some dirty translation processes down in the input layer?
Is the input layer always assuming that Alt-PrintScreen == SysRq?
This is not always true. Can the input layer be so configured that it
never tries to interpret the scancodes, but pass them to the upper
layers?
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee