psaux.c release 2004-04-19
This is psaux.c linux kernel driver for kernels 2.6.x,
a direct PS/2 serial port (aka /dev/psaux) driver.
Available from:
http://www.ee.oulu.fi/~tuukkat/rel/psaux-2004-04-19.tar.gz
(includes README with more information)
The driver was originally written by Lee Sau Dan
http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/
but I fixed some bugs (most importantly SMP).
I've seen lots of discussions about different mouse behaviour (or
completely non-functioning mouse). If you have one of those problems, this
driver should restore the kernel 2.4.x behaviour.
Any suggestions/hopes to get it included into mainstream kernel?
P.S. is there any documentation about the serio interface (serio_open()
etc...)? I couldn't find anywhere.
Tuukka Toivonen <[email protected]> wrote:
>
> psaux.c release 2004-04-19
>
> This is psaux.c linux kernel driver for kernels 2.6.x,
> a direct PS/2 serial port (aka /dev/psaux) driver.
>
> Available from:
> http://www.ee.oulu.fi/~tuukkat/rel/psaux-2004-04-19.tar.gz
>
> (includes README with more information)
>
> The driver was originally written by Lee Sau Dan
> http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/
> but I fixed some bugs (most importantly SMP).
>
> I've seen lots of discussions about different mouse behaviour (or
> completely non-functioning mouse). If you have one of those problems, this
> driver should restore the kernel 2.4.x behaviour.
>
> Any suggestions/hopes to get it included into mainstream kernel?
I'd imagine that the input developers would regard that as a step in the
wrong direction.
Have you sent a report regarding the touchscreen problem? Is it a
straightforward bug, or has real functionality been lost?
> P.S. is there any documentation about the serio interface (serio_open()
> etc...)? I couldn't find anywhere.
Always a good question ;)
On Monday 19 April 2004 11:52, you wrote:
> > I've seen lots of discussions about different mouse behaviour (or
> > completely non-functioning mouse). If you have one of those problems,
> > this driver should restore the kernel 2.4.x behaviour.
>
> I'd imagine that the input developers would regard that as a step in the
> wrong direction.
Not that I'm the Offical Input Developer(tm) but I'm currently doing
modifications to the PS/2 mouse support which will hopefully restore full
functionality for most mice. I'm still coding it and I estimate a day or two
until I get it working tested patch which I will then send here.
Once question though: I'm currently coding against 2.6.5 - should I do the
patch against something else?
> Have you sent a report regarding the touchscreen problem? Is it a
> straightforward bug, or has real functionality been lost?
This wasn't directed to me, but right now I'm focusing on normal mice. I need
to steal the laptop away from wife to test a Synaptic touchpad....
Kim
>>>>> "Andrew" == Andrew Morton <[email protected]> writes:
>> The driver was originally written by Lee Sau Dan
>> http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/ but I
>> fixed some bugs (most importantly SMP).
>>
>> I've seen lots of discussions about different mouse behaviour
>> (or completely non-functioning mouse). If you have one of those
>> problems, this driver should restore the kernel 2.4.x
>> behaviour.
>>
>> Any suggestions/hopes to get it included into mainstream
>> kernel?
Andrew> I'd imagine that the input developers would regard that as
Andrew> a step in the wrong direction.
I know what you mean. But please see
http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/
for my arguments against the direction currently taken by the input
developers.
Moreover, while most people report problems of various severity with
the mouse after upgrading to 2.6, the direct psaux port does solve
most of those problems, providing a smooth migration path. Actually,
I would still be staying with 2.4.* if I didn't write my psaux module,
because the touchscreen function on my notebook is important to me. I
have written my XFree86 driver for it, and I'm not going to port it to
kernel space.
While most Linux people frown upon Microsoft for putting the GUI in
the NT kernel, I frown upon the input developers for moving the
functions of 'gpm' into kernel space. I can't see any good reasons to
deprecate 'gpm' that way.
Andrew> Have you sent a report regarding the touchscreen problem?
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.
Andrew> Is it a straightforward bug, or has real functionality
Andrew> been lost?
Yes. Directly talking to a device on the PS2/AUX port (like what we
can do to a RS232 port) is no longer possible in 2.6, until my psaux
module. This is certainly a lost functionality.
See my page with URL given above for a more detailed discussion.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
> 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.
Arjan van de Ven wrote:
> 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.
Not quite. Both SCSI and IDE layers offer "generic" access for
sending commands to the device which the kernel doesn't understand.
> 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 in this case: the touchpad should be handled by the input
layer, for uniformity if nothing else.
However, what happens when the thing connected to the PS/2 port isn't
a mouse or keyboard, just a strange device talking bytes? With 2.4
kernels you could talk to it.
-- Jamie
>>>>> "Jamie" == Jamie Lokier <[email protected]> writes:
>> 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.
Isn't it possible to use the PS/2 AUX port for purposes other than
HID? In 2.4, /dev/psaux looks like /dev/ttyS1 to the userspace. Is
there a good reason to make them different in 2.6?
Imagine the kernel now hiding /dev/ttyS* and ASSUMING that all of them
are Class 2.0 fax-modems. Instead of letting you issue the AT command
set to the fax-modem and getting the response directly from the
device, the kernel now *abstracts* that away from usespace. Imagine
that the kernel now *forbids* the userspace programs to use AT
commands directly. Userspace is now only allowed to use ioctls to
issue "dial", "hang up", "receive fax page" commands. Would that be
nice?
SEPARATION of POLICY and MECHANISM is an important concept in the
design of unix.
And how about the display? Shouldn't the kernel abstract it away from
userspace? Why should we have different XFree86 display drivers?
Shouldn't they be all implemented in kernel, so that XFree86 and all
graphics programs only need to access the graphics system in a uniform
way, without caring about the differences between different graphics
adaptors?
>> 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.
You still need to configure your kernel by means of boot parameters or
module options. Are users already complaining about surprising mouse
sensitivity? Don't they need to tune some parameters to obtain the
desired behaviours? I can't see how you can do fewer configurations,
or avoid them at all.
Jamie> I agree in this case: the touchpad should be handled by the
Jamie> input layer, for uniformity if nothing else.
But why not do it in a user-space daemon? GPM has been doing that for
10 years already, and it has been doing it quite well. I even
demonstrated to many people how I configure both a RS232 mouse and a
PS/2 mouse to work in X at the same time, and those people were
surprised that this was even possible. Thanks to GPM.
My philosophy is: if something can be done in userspace, then do it in
userspace. Only leave the essential things in kernel space. So, we
don't have XFree86 in kernel space. It's not a good idea.
Of course, if performance is an issue, we may consider moving
something from userspace into kernel: kernel NFS daemon, firewall.
Isn't khttpd now removed? Why? (But even with knfsd, you still have
the CHOICE to use a userland nfsd instead.) I don't believe 'gpm' has
performance problems -- the mouse port is usally 1200 baud only.
Jamie> However, what happens when the thing connected to the PS/2
Jamie> port isn't a mouse or keyboard, just a strange device
Jamie> talking bytes? With 2.4 kernels you could talk to it.
And now... it's not possible anymore. Assuming that everything
attached to the PS/2 AUX port must be a mouse is a design mistake. It
is like assuming that the RS232 port must be attached to a fax-modem.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Monday 19 April 2004 03:35 am, Tuukka Toivonen wrote:
> psaux.c release 2004-04-19
>
> This is psaux.c linux kernel driver for kernels 2.6.x,
> a direct PS/2 serial port (aka /dev/psaux) driver.
>
> Available from:
> http://www.ee.oulu.fi/~tuukkat/rel/psaux-2004-04-19.tar.gz
>
> (includes README with more information)
>
> The driver was originally written by Lee Sau Dan
> http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/
> but I fixed some bugs (most importantly SMP).
>
> I've seen lots of discussions about different mouse behaviour (or
> completely non-functioning mouse). If you have one of those problems, this
> driver should restore the kernel 2.4.x behaviour.
>
> Any suggestions/hopes to get it included into mainstream kernel?
>
It seems that the driver allows non-exclusive access to the port - multiple
users may fight to set up the mode. How they will agree on which one to set?
On the other hand I do not want psaux to give me only exclusive access as
I have had emough of GPM repeater feeding X feeding Y ... etc.
It does not support active multiplexing controller (4 AUX ports) which
becomes quite common and is the only sane option when you have several
mice of different types.
Also I do not see where the code makes sure that it does not bind to
keyboard's port (so keyboard driver has to be loaded first).
I think the right way is to fix the issues with psmouse driver and use input
system to tie all hardware together.
--
Dmitry
On Tuesday 20 April 2004 15:56, Dmitry Torokhov wrote:
> I think the right way is to fix the issues with psmouse driver and use
> input system to tie all hardware together.
I agree 100%, and that's why I'm working on the driver. I think the biggest
issue right now is the Fujitsu TouchScreen - I'll try to steal one of those
laptops from work later this week and maybe come up with a solution. It has a
Synaptics touchpad too so I get to test that as well.
Kim