Re: /dev/psaux-Interface

From: Dmitry Torokhov
Date: Wed Apr 21 2004 - 01:53:51 EST

On Wednesday 21 April 2004 01:31 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@xxxxxxxxxxxxx> writes:
> Dmitry> It seems that the driver allows non-exclusive access to
> Dmitry> the port - multiple users may fight to set up the
> Dmitry> mode.
> That's wrong. The driver is written so that multiple processes can
> hold the device node open at the same time, in the same way /dev/psaux
> in pre2.6 kernels was.

Don't we say the same thing?

> Dmitry> How they will agree on which one to set?
> GPM and XFree86 have been coordinating themselves well on this on all
> my Linux systems since 1993. And this has continued to be so with my
> psaux Module on Linux 2.6.

Not all the world is GPM and XFree.

> Dmitry> On the other hand I do not want psaux to give me only
> Dmitry> exclusive access as I have had emough of GPM repeater
> Dmitry> feeding X feeding Y ... etc.
> Both GPM and XFree86 are aware of vc switching, I suppose.

Not all the world is GPM and XFree.

> Dmitry> It does not support active multiplexing controller (4 AUX
> Dmitry> ports) which becomes quite common and is the only sane
> Dmitry> option when you have several mice of different types.
> That's because I don't have such a thing, and the interface of serio.c
> is not documented. Instead of guessing how the interface is supposed
> to work, I think it's better to leave it to the kernel developers.

The question was whether to include it in the kernel as it is. If it is not
compled work then it should wait a bit.

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

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

> Dmitry> I think the right way is to fix the issues with psmouse
> Dmitry> driver and use input system to tie all hardware together.
> But how can you add support of new protocols and hardware? Not
> everyone want to reimplement GPM and XFree86 drivers in kernel space.
> It's much easier to do it in user space. Adding the complexity of
> various devices and protocols into kernelspace is insane.

The thing is that processing in kernel space is not that complex. The only
thing kernel has to do is to parse raw data and convert to events. The events
are parsed by user space daemon with all required bells and whistles. See
for example Synaptics driver for Xfree86 by Peter Osterlund, or my GPM
patches for that matter.

Mousedev is a transitional thing, it will go away eventually or will have a
very limited use by legacy applications.

> The only sane way to do it, IMO, is to restructure the input layer
> slightly, so that mouse protocols are handled by userspace daemons.
> The daemon(s) are responsible for talking to the device directly via
> device nodes such as /dev/misc/psaux_direct, and translating these
> into the common protocol (IMPS2?) and hand it back to kernel space
> (via a special device node). The kernel can then combine the data
> from all daemons and repeat it on /dev/input/mice.

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at