lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: /dev/psaux-Interface
On Monday April 19, arjanv@redhat.com 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
-
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 14:02    [W:0.113 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site