Re: /dev/psaux-Interface

Re: /dev/psaux-Interface

[Tuukka Toivonen]

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.

Re: /dev/psaux-Interface

[Andrew Morton]

Tuukka Toivonen <tuukkat@ee.oulu.fi> 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 ;)

Re: /dev/psaux-Interface

[Kim Holviala]

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

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Andrew" == Andrew Morton <akpm@osdl.org> 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                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: /dev/psaux-Interface

[Jamie Lokier]

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

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Jamie" == Jamie Lokier <jamie@shareable.org> 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                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Neil Brown]

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

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Neil" == Neil Brown <neilb@cse.unsw.edu.au> 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                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Tuukka Toivonen]

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).

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Tuukka" == Tuukka Toivonen <tuukkat@ee.oulu.fi> 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                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Neil Brown]

On  April 21, danlee@informatik.uni-freiburg.de wrote:
> >>>>> "Neil" == Neil Brown <neilb@cse.unsw.edu.au> 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?

Simple debating technique:  start of by agreeing with someone and they
are more likely to listen to your argument. The key issue is where the
driver should be, not where the interface should be, so focus on that.

> 
> 
> BTW, how did you hack the /dev/psaux?
> 

It's not suitable for inclusion, but with this patch, I get two
modules, psdev and psmouse.
I load psdev and /dev/psaux is raw.  I load psmouse  and /dev/psaux is
normal 2.6 behaviour.

NeilBrown


 ----------- Diffstat output ------------
 ./drivers/input/Kconfig        |    2 
 ./drivers/input/mouse/Kconfig  |    7 +
 ./drivers/input/mouse/Makefile |    1 
 ./drivers/input/mouse/psdev.c  |  256 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 265 insertions(+), 1 deletion(-)

diff ./drivers/input/Kconfig~current~ ./drivers/input/Kconfig
--- ./drivers/input/Kconfig~current~	2004-04-05 14:18:30.000000000 +1000
+++ ./drivers/input/Kconfig	2004-04-05 14:18:30.000000000 +1000
@@ -42,7 +42,7 @@ config INPUT_MOUSEDEV
 
 config INPUT_MOUSEDEV_PSAUX
 	bool "Provide legacy /dev/psaux device" if EMBEDDED
-	default y
+	default n
 	depends on INPUT_MOUSEDEV
 
 config INPUT_MOUSEDEV_SCREEN_X

diff ./drivers/input/mouse/Kconfig~current~ ./drivers/input/mouse/Kconfig
--- ./drivers/input/mouse/Kconfig~current~	2004-04-05 14:18:30.000000000 +1000
+++ ./drivers/input/mouse/Kconfig	2004-04-05 14:18:30.000000000 +1000
@@ -141,3 +141,10 @@ config MOUSE_PC9800
 	  To compile this driver as a module, choose M here: the
 	  module will be called 98busmouse.
 
+config MOUSE_PSDEV
+	tristate "Raw PS/AUX driver for mouse"
+	default y
+	depends on INPUT && INPUT_MOUSE && SERIO
+	---help---
+	  Say Y if you want /dev/psaux to really be /dev/psaux
+

diff ./drivers/input/mouse/Makefile~current~ ./drivers/input/mouse/Makefile
--- ./drivers/input/mouse/Makefile~current~	2004-04-05 14:18:30.000000000 +1000
+++ ./drivers/input/mouse/Makefile	2004-04-05 14:18:30.000000000 +1000
@@ -4,6 +4,7 @@
 
 # Each configuration option enables a list of files.
 
+obj-$(CONFIG_MOUSE_PSDEV)	+= psdev.o
 obj-$(CONFIG_MOUSE_AMIGA)	+= amimouse.o
 obj-$(CONFIG_MOUSE_RISCPC)	+= rpcmouse.o
 obj-$(CONFIG_MOUSE_INPORT)	+= inport.o

diff ./drivers/input/mouse/psdev.c~current~ ./drivers/input/mouse/psdev.c
--- ./drivers/input/mouse/psdev.c~current~	2004-04-05 14:18:30.000000000 +1000
+++ ./drivers/input/mouse/psdev.c	2004-04-05 14:18:30.000000000 +1000
@@ -0,0 +1,256 @@
+/*
+ * PS/2 mouse driver
+ *
+ * Copyright (c) 2003 Neil Brown
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/poll.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/input.h>
+#include <linux/serio.h>
+#include <linux/init.h>
+#include <linux/miscdevice.h>
+#include <linux/device.h>
+
+
+MODULE_AUTHOR("Neil Brown <neilb@cse.unsw.edu.au>");
+MODULE_DESCRIPTION("PS/2 Aux port driver");
+MODULE_LICENSE("GPL");
+
+#define	BUFSIZE	128
+struct psreader {
+	struct list_head	list;
+	struct psdev		*dev;
+	char			buf[BUFSIZE];
+	int			head, tail; /* (head==tail) => empty */
+};
+static LIST_HEAD(psreaders);
+
+struct psdev {
+	struct list_head 	list;
+	struct serio		*serio;
+	struct psreader		*reader;
+};
+static LIST_HEAD(psdevs);
+static DECLARE_WAIT_QUEUE_HEAD(waitq);
+static spinlock_t lock = SPIN_LOCK_UNLOCKED;
+
+static ssize_t psaux_read(struct file * file, char * buffer, size_t count, loff_t *ppos)
+{
+	struct psreader *pr = file->private_data;
+	int copied = 0;
+	int err = 0;
+	DEFINE_WAIT(wait);
+
+	if (!count) return 0;
+	while(!copied && !err) {
+		prepare_to_wait(&waitq, &wait, TASK_INTERRUPTIBLE);
+		while (count && pr->head != pr->tail) {
+			int h = pr->head;
+			int t = pr->tail;
+			if (t < h)
+				t = BUFSIZE;
+			if (t - h > count)
+				t = h + count;
+			if (copy_to_user(buffer+copied, pr->buf+h, t-h)) {
+				err = -EFAULT;
+				break;
+			}
+			copied += t-h;
+			count -= t-h;
+			if (t == BUFSIZE) t = 0;
+			pr->head = t;
+		}
+		if (err || copied) break;
+		if ((file->f_flags & O_NONBLOCK))
+			err = -EAGAIN;
+		else 
+			schedule();
+		if (signal_pending(current))
+			err = -EINTR;
+	}
+	finish_wait(&waitq, &wait);
+	if (copied)
+		return copied;
+	else
+		return err;
+}
+
+static ssize_t psaux_write(struct file * file, const char * buffer, size_t count, loff_t *ppos)
+{
+	unsigned char c;
+	int i;
+	struct psreader *pr = file->private_data;
+	struct psdev *ps = pr->dev;
+
+	if (count == 0 ) return 0;
+	for (i = 0; i < count ; i++) {
+
+		if (get_user(c, buffer + i))
+			return -EFAULT;
+
+		if (ps == NULL && !list_empty(&psdevs))
+			ps = list_entry(psdevs.next, struct psdev, list);
+		if (ps)
+			if (serio_write(ps->serio, c))
+				break;
+	}
+	if (i == 0) return -EIO;
+	return i;
+}
+
+static unsigned int psaux_poll(struct file *file, poll_table *wait)
+{
+	struct psreader *pr = file->private_data;
+	poll_wait(file, &waitq, wait);
+
+	if (pr->head != pr->tail) 
+		return POLLIN | POLLRDNORM;
+	return 0;
+}
+
+static int psaux_open(struct inode * inode, struct file * file)
+{
+	struct psreader *pr = kmalloc(sizeof(*pr), GFP_KERNEL);
+	if (pr == NULL)
+		return -ENOMEM;
+	memset(pr, 0, sizeof(*pr));
+	spin_lock_irq(&lock);
+	list_add(&pr->list, &psreaders);
+	file->private_data = pr;
+	spin_unlock_irq(&lock);
+	return 0;
+}
+
+static int psaux_release(struct inode * inode, struct file * file)
+{
+	struct psreader *pr = file->private_data;
+	spin_lock_irq(&lock);
+	list_del(&pr->list);
+	if (pr->dev)
+		pr->dev->reader = NULL;
+	spin_unlock_irq(&lock);
+	kfree(pr);
+	return 0;
+}
+
+
+struct file_operations psaux_fops = {
+	.owner =	THIS_MODULE,
+	.read =		psaux_read,
+	.write =	psaux_write,
+	.poll =		psaux_poll,
+	.open =		psaux_open,
+	.release =	psaux_release,
+/*	.fasync =	psaux_fasync, */
+};
+
+static struct miscdevice psaux = {
+	PSMOUSE_MINOR, "psaux", &psaux_fops
+};
+
+
+static irqreturn_t psaux_interrupt(struct serio *serio,
+				   unsigned char data, unsigned int flags,
+				   struct pt_regs *regs)
+{
+	struct psdev *ps = serio->private;
+	struct psreader *pr = ps->reader;
+	unsigned long iflags;
+
+/*	printk("got %x\n", data); */
+	spin_lock_irqsave(lock, iflags);
+	if (pr) {
+		if ((pr->tail+1) % BUFSIZE != pr->head) {
+			/* there is room */
+			pr->buf[pr->tail] = data;
+			pr->tail = (pr->tail+1) % BUFSIZE;
+		}
+	} else
+	list_for_each_entry(pr, &psreaders, list) {
+		if (pr->dev == NULL) {
+			if ((pr->tail+1) % BUFSIZE != pr->head) {
+				/* there is room */
+				pr->buf[pr->tail] = data;
+				pr->tail = (pr->tail+1) % BUFSIZE;
+			}
+		}
+	}
+	spin_unlock_irqrestore(lock, iflags);
+	wake_up(&waitq);
+	return IRQ_HANDLED;
+}
+
+static void psaux_connect(struct serio *serio, struct serio_dev *dev)
+{
+	struct psdev *ps;
+	printk("psaux connect\n");
+	if ((serio->type & SERIO_TYPE) != SERIO_8042)
+		return;
+	ps = kmalloc(sizeof(*ps), GFP_KERNEL);
+	if (!ps)
+		return;
+
+	if (serio_open(serio, dev)) {
+		kfree(ps);
+		return; 
+	}
+	printk("Connect succeeded\n");
+	ps->serio = serio;
+	ps->reader = NULL;
+	serio->private = ps;
+	spin_lock_irq(&lock);
+	list_add(&ps->list, &psdevs);
+	spin_unlock_irq(&lock);
+}
+
+static void psaux_disconnect(struct serio *serio)
+{
+	struct psdev *ps = serio->private;
+
+	if (ps->reader)
+		ps->reader->dev = NULL;
+	spin_lock_irq(&lock);
+	list_del(&ps->list);
+	spin_unlock_irq(&lock);
+	serio_close(serio);
+	kfree(ps);
+}
+
+static void psaux_cleanup(struct serio *serio)
+{
+}
+
+
+static struct serio_dev psaux_dev = {
+	.interrupt =	psaux_interrupt,
+	.connect =	psaux_connect,
+	.disconnect =	psaux_disconnect,
+	.cleanup =	psaux_cleanup,
+};
+
+
+int __init psaux_init(void)
+{
+	serio_register_device(&psaux_dev);
+	misc_register(&psaux);
+	return 0;
+}
+
+void __exit psaux_exit(void)
+{
+	misc_deregister(&psaux);
+	serio_unregister_device(&psaux_dev);
+}
+
+module_init(psaux_init);
+module_exit(psaux_exit);

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Neil" == Neil Brown <neilb@cse.unsw.edu.au> writes:

    >> BTW, how did you hack the /dev/psaux?

    Neil> It's not suitable for inclusion, but with this patch, I get
    Neil> two modules, psdev and psmouse.  I load psdev and /dev/psaux
    Neil> is raw.  I load psmouse and /dev/psaux is normal 2.6
    Neil> behaviour.

    [patch snipped]


I see.  Basically, we're both (re)inventing the same thing.  :)

Now, it  is clear that there is  a need for direct  psaux port access.
It's useful for 2 reasons:

1) Compatibility with 2.4, 2.2, 2.0  kernels, so that programs need no
   modification and work as before.  This provides an easier migration
   path for those who want to upgrad to 2.6 for whatever reasons.

2) To  enable  using "strange",  not  yet  supported hardwares,  whose
   *mature* software  drivers are already available for 2.4, 2.2, 2.0,
   etc.  Not every writer of  those software drivers are interested in
   rewriting their programs in kernel space.



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Dmitry Torokhov]

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

Re: /dev/psaux-Interface

[Kim Holviala]

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

Re: /dev/psaux-Interface

[Dmitry Torokhov]

On Wednesday 21 April 2004 01:31 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> 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. 

-- 
Dmitry

Re: /dev/psaux-Interface

[Sau Dan Lee]

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

Re: /dev/psaux-Interface

[Dmitry Torokhov]

On Wednesday 21 April 2004 02:15 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
> 
> 
>     >> 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.
>

OK, here you go. It is the first cut. The driver creates an absolute device
for the touchscreen and a fake pass-through port to for the pointing device
which works in relative mode. All fancy stuff can be done in userspace via
evdev.
 
Hopefully I got Y-axis direction correctly and init sequence may need some
work. It also hijacks proto=imsp parameter until I merge Kim's protocol
selection changes. I wish I could test it but I do not have a Lifebook so
comments and suggestions are welcome.

Apply on top of patches in:
http://www.geocities.com/dt_or/input/2.6.6-rc2/

-- 
Dmitry

===== drivers/input/mouse/Makefile 1.9 vs edited =====
--- 1.9/drivers/input/mouse/Makefile	Wed Mar  3 11:17:04 2004
+++ edited/drivers/input/mouse/Makefile	Thu Apr 22 00:20:31 2004
@@ -15,4 +15,4 @@
 obj-$(CONFIG_MOUSE_SERIAL)	+= sermouse.o
 obj-$(CONFIG_MOUSE_VSXXXAA)	+= vsxxxaa.o
 
-psmouse-objs  := psmouse-base.o logips2pp.o synaptics.o
+psmouse-objs  := psmouse-base.o lbtouch.o logips2pp.o synaptics.o
===== drivers/input/mouse/psmouse-base.c 1.57 vs edited =====
--- 1.57/drivers/input/mouse/psmouse-base.c	Tue Apr 20 23:59:36 2004
+++ edited/drivers/input/mouse/psmouse-base.c	Thu Apr 22 00:59:31 2004
@@ -21,6 +21,7 @@
 #include "psmouse.h"
 #include "synaptics.h"
 #include "logips2pp.h"
+#include "lbtouch.h"
 
 MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
 MODULE_DESCRIPTION("PS/2 mouse driver");
@@ -53,7 +54,7 @@
 __obsolete_setup("psmouse_resetafter=");
 __obsolete_setup("psmouse_rate=");
 
-static char *psmouse_protocols[] = { "None", "PS/2", "PS2++", "PS2T++", "GenPS/2", "ImPS/2", "ImExPS/2", "SynPS/2"};
+static char *psmouse_protocols[] = { "None", "PS/2", "PS2++", "PS2T++", "GenPS/2", "ImPS/2", "ImExPS/2", "SynPS/2", "LBPS/2" };
 
 /*
  * psmouse_process_byte() analyzes the PS/2 data stream and reports
@@ -414,6 +415,15 @@
 			      unsigned int max_proto, int set_properties)
 {
 	int synaptics_hardware = 0;
+
+	if (max_proto == PSMOUSE_IMEX && lbtouch_init(psmouse, set_properties)) {
+		if (set_properties) {
+			psmouse->vendor = "Fujitsu";
+			psmouse->name = "Lifebook Touchscreen";
+		}
+
+		return PSMOUSE_LBTOUCH;
+	}
 
 /*
  * Try Synaptics TouchPad
===== drivers/input/mouse/psmouse.h 1.10 vs edited =====
--- 1.10/drivers/input/mouse/psmouse.h	Tue Apr 20 17:42:10 2004
+++ edited/drivers/input/mouse/psmouse.h	Thu Apr 22 00:14:52 2004
@@ -72,6 +72,7 @@
 #define PSMOUSE_IMPS		5
 #define PSMOUSE_IMEX		6
 #define PSMOUSE_SYNAPTICS 	7
+#define PSMOUSE_LBTOUCH 	8
 
 int psmouse_command(struct psmouse *psmouse, unsigned char *param, int command);
 int psmouse_sliced_command(struct psmouse *psmouse, unsigned char command);
===== drivers/input/mouse/lbtouch.c 1.0 vs 1.1 =====
--- /dev/null	Fri Aug 30 18:31:37 2002
+++ 1.1/drivers/input/mouse/lbtouch.c	Thu Apr 22 01:21:26 2004
@@ -0,0 +1,203 @@
+/*
+ *  Copyright (c) 2004 Dmitry Torokhov <dtor@mail.ru>
+ */
+
+/*
+ * Lifebook touchscreen driver for Linux
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/input.h>
+#include <linux/serio.h>
+
+#include "psmouse.h"
+#include "lbtouch.h"
+
+MODULE_AUTHOR("Dmitry Torokhov <dtor@mail.ru>");
+MODULE_DESCRIPTION("Fujitsu Lifebook touchscreen driver");
+MODULE_LICENSE("GPL");
+
+/* The default values are taken from Kenan Esau's driver */
+static int limits[4] = { 86, 955, 37, 937 };
+static int num_limits __initdata = 0;
+module_param_array_named(lbt_size, limits, int, num_limits, 0);
+MODULE_PARM_DESC(lbt_size, "Effective usable area of Lifebook touchscreen (left,right,bottom,up)");
+
+
+/*****************************************************************************
+ *	Lifebook pass-through PS/2 port support
+ ****************************************************************************/
+static int lbtouch_pt_write(struct serio *port, unsigned char c)
+{
+	switch (c) {
+		case PSMOUSE_CMD_RESET_BAT & 0xff:
+			serio_interrupt(port, PSMOUSE_RET_ACK, 0, NULL);
+			serio_interrupt(port, PSMOUSE_RET_BAT, 0, NULL);
+			serio_interrupt(port, PSMOUSE_RET_ID, 0, NULL);
+			break;
+
+		case PSMOUSE_CMD_GETID & 0xff:
+			serio_interrupt(port, PSMOUSE_RET_ACK, 0, NULL);
+			serio_interrupt(port, 0x00, 0, NULL);
+			break;
+
+		case PSMOUSE_CMD_ENABLE & 0xff:
+		case PSMOUSE_CMD_RESET_DIS & 0xff:
+			serio_interrupt(port, PSMOUSE_RET_ACK, 0, NULL);
+			break;
+
+		default:
+			serio_interrupt(port, PSMOUSE_RET_NAK, 0, NULL);
+			break;
+	}
+
+	return 0;
+}
+
+static void lbtouch_pass_pt_packet(struct serio *ptport, unsigned char *packet)
+{
+	struct psmouse *child = ptport->private;
+
+	if (child && child->state == PSMOUSE_ACTIVATED) {
+		serio_interrupt(ptport, packet[0], 0, NULL);
+		serio_interrupt(ptport, packet[1], 0, NULL);
+		serio_interrupt(ptport, packet[2], 0, NULL);
+	}
+}
+
+static void lbtouch_pt_create(struct psmouse *psmouse)
+{
+	struct psmouse_ptport *port;
+
+	psmouse->ptport = port = kmalloc(sizeof(struct psmouse_ptport), GFP_KERNEL);
+	if (!port) {
+		printk(KERN_ERR "lbtouch: not enough memory to allocate pass-through port\n");
+		return;
+	}
+
+	memset(port, 0, sizeof(struct psmouse_ptport));
+
+	port->serio.type = SERIO_PS_PSTHRU;
+	port->serio.name = "Lifebook pass-through";
+	port->serio.phys = "lbtouch-pt/serio0";
+	port->serio.write = lbtouch_pt_write;
+	port->serio.driver = psmouse;
+}
+
+/*****************************************************************************
+ *	Functions to interpret the absolute mode packets
+ ****************************************************************************/
+
+static psmouse_ret_t lbtouch_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	struct input_dev *dev = &psmouse->dev;
+	unsigned char *p = psmouse->packet;
+	int x, y, touch;
+
+	input_regs(dev, regs);
+
+	if (psmouse->pktcnt < 3)
+		return PSMOUSE_GOOD_DATA;
+
+	if (p[0] & 0x80) {
+	        x = ((unsigned int)(p[0] & 0x30) << 4) + p[1];
+        	y = ((unsigned int)(p[0] & 0xc0) << 2) + p[2];
+		touch = p[0] & 0x04 ? 1 : 0;
+
+		input_report_key(dev, BTN_TOUCH, touch);
+		if (touch) {
+			input_report_abs(dev, ABS_X, x - limits[0]);
+			input_report_abs(dev, ABS_Y, limits[3] + limits[3] - y);
+		}
+
+		if ((p[0] &= 0x03) != 0 && psmouse->ptport && psmouse->ptport->serio.dev) {
+			p[1] = p[2] = 0;
+			lbtouch_pass_pt_packet(&psmouse->ptport->serio, p);
+		}
+	} else if (psmouse->ptport && psmouse->ptport->serio.dev) {
+		lbtouch_pass_pt_packet(&psmouse->ptport->serio, p);
+	}
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+/*****************************************************************************
+ *	Driver initialization/cleanup functions
+ ****************************************************************************/
+
+static inline void set_abs_params(struct input_dev *dev, int axis, int min, int max, int fuzz, int flat)
+{
+	dev->absmin[axis] = min;
+	dev->absmax[axis] = max;
+	dev->absfuzz[axis] = fuzz;
+	dev->absflat[axis] = flat;
+
+	set_bit(axis, dev->absbit);
+}
+
+static void lbtouch_disconnect(struct psmouse *psmouse)
+{
+	unsigned char param[1];
+
+	param[0] = 0x06;
+
+	if (psmouse_command(psmouse, param, PSMOUSE_CMD_SETRES) ||
+	    psmouse_command(psmouse, NULL, PSMOUSE_CMD_ENABLE) ||
+	    psmouse_command(psmouse, NULL, PSMOUSE_CMD_ENABLE) ||
+	    psmouse_command(psmouse, NULL, PSMOUSE_CMD_ENABLE))
+		printk(KERN_WARNING "lbtouch.c: Failed to restore touchscreen PS/2 emulation\n");
+}
+
+int lbtouch_init(struct psmouse *psmouse, int set_properties)
+{
+	unsigned char param[1];
+
+	if (psmouse->serio->type != SERIO_8042)
+		return 0;
+
+	param[0] = 0x07;
+	if (psmouse_command(psmouse, param, PSMOUSE_CMD_SETRES) ||
+	    psmouse_command(psmouse, NULL, PSMOUSE_CMD_ENABLE) ||
+	    psmouse_command(psmouse, NULL, PSMOUSE_CMD_ENABLE) ||
+	    psmouse_command(psmouse, NULL, PSMOUSE_CMD_ENABLE)) {
+		printk(KERN_ERR "lbtouch.c: Failed to enable touchscreen native mode\n");
+		return 0;
+	}
+
+	if (set_properties) {
+		set_bit(EV_ABS, psmouse->dev.evbit);
+		set_abs_params(&psmouse->dev, ABS_X, limits[0], limits[1], 0, 0);
+		set_abs_params(&psmouse->dev, ABS_Y, limits[2], limits[3], 0, 0);
+
+		set_bit(EV_KEY, psmouse->dev.evbit);
+		set_bit(BTN_TOUCH, psmouse->dev.keybit);
+
+		clear_bit(EV_REL, psmouse->dev.evbit);
+		clear_bit(REL_X, psmouse->dev.relbit);
+		clear_bit(REL_Y, psmouse->dev.relbit);
+
+		psmouse->protocol_handler = lbtouch_process_byte;
+		psmouse->disconnect = lbtouch_disconnect;
+
+		lbtouch_pt_create(psmouse);
+	}
+
+	return 1;
+}
===== drivers/input/mouse/lbtouch.h 1.0 vs 1.1 =====
--- /dev/null	Fri Aug 30 18:31:37 2002
+++ 1.1/drivers/input/mouse/lbtouch.h	Thu Apr 22 01:21:29 2004
@@ -0,0 +1,16 @@
+/*
+ * Fujistsu Lifebook PS/2 touchscreen driver header
+ *
+ * Copyright (c) 2004 Dmitry Torokhov <dtor@mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#ifndef _LBTOUCH_H
+#define _LBTOUCH_H
+
+int lbtouch_init(struct psmouse *psmouse, int set_properties);
+
+#endif

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:

    Dmitry> OK, here you go. It is the first cut. The driver creates
    Dmitry> an absolute device for the touchscreen and a fake
    Dmitry> pass-through port to for the pointing device which works
    Dmitry> in relative mode. All fancy stuff can be done in userspace
    Dmitry> via evdev.

I  still  haven't  tried  it.   But upon  first  inspection,  I  found
something undesirable already.

+static void lbtouch_pass_pt_packet(struct serio *ptport, unsigned char *packet)
+{
+	struct psmouse *child = ptport->private;
+
+	if (child && child->state == PSMOUSE_ACTIVATED) {
+		serio_interrupt(ptport, packet[0], 0, NULL);
+		serio_interrupt(ptport, packet[1], 0, NULL);
+		serio_interrupt(ptport, packet[2], 0, NULL);
+	}
+}
+

So,  you're  imposing the  policy  that  the  packets must  as  3-byte
packets?  My  experiences in  writing my XFree86  driver is  that some
bytes  are sometimes  dropped, for  reasons I  don't know.   My driver
would  attempt to  resync, although  not reliably  because  the packet
format   in   touch-screen   mode   does  not   provide   a   reliable
synchronization mechanism (such  as parity, a special bit  to mark the
end of a packet, etc.).

I don't know whether the dropping  of bytes is specific to my machine,
or is common to all B142 models.


+static psmouse_ret_t lbtouch_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	struct input_dev *dev = &psmouse->dev;
+	unsigned char *p = psmouse->packet;
+	int x, y, touch;
+
+	input_regs(dev, regs);
+
+	if (psmouse->pktcnt < 3)
+		return PSMOUSE_GOOD_DATA;
+

The  same problem.   You  wait  for a  complete  3-byte packet  before
emitting an event.  What happens to dropped bytes?


And what  happens to the timeout  feature in my  XFree86 driver?  That
feature is  the main reason I  write my driver, because  that's what I
want and  couldn't find (in others' implementation  of the touchscreen
driver).  The feature could be either in a XFree86 driver, or a kernel
mouse driver.  But I'm not going to write another XFree86 driver.  The
feature is already there in my  XFree86 driver, and I just want direct
byte-level  communication  to the  PSAUX  port.   No 3-byte  boundarys
imposed.  No censoring of data in either direction.  It's that simple.
What make that so difficult?



-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Dmitry Torokhov]

On Thursday 22 April 2004 02:06 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
> 
>     Dmitry> OK, here you go. It is the first cut. The driver creates
>     Dmitry> an absolute device for the touchscreen and a fake
>     Dmitry> pass-through port to for the pointing device which works
>     Dmitry> in relative mode. All fancy stuff can be done in userspace
>     Dmitry> via evdev.
> 
> I  still  haven't  tried  it.   But upon  first  inspection,  I  found
> something undesirable already.
> 
> +static void lbtouch_pass_pt_packet(struct serio *ptport, unsigned char *packet)
> +{
> +	struct psmouse *child = ptport->private;
> +
> +	if (child && child->state == PSMOUSE_ACTIVATED) {
> +		serio_interrupt(ptport, packet[0], 0, NULL);
> +		serio_interrupt(ptport, packet[1], 0, NULL);
> +		serio_interrupt(ptport, packet[2], 0, NULL);
> +	}
> +}
> +
> 
> So,  you're  imposing the  policy  that  the  packets must  as  3-byte
> packets?

Yes, this is my uderstanding of Lifebook protocol. It is incapable of anything
but bare PS/2 as far as the pointing device goes. If we ever get a spec we can
revisit it.

> My  experiences in  writing my XFree86  driver is  that some 
> bytes  are sometimes  dropped, for  reasons I  don't know.   My driver
> would  attempt to  resync, although  not reliably  because  the packet
> format   in   touch-screen   mode   does  not   provide   a   reliable
> synchronization mechanism (such  as parity, a special bit  to mark the
> end of a packet, etc.).
>

There is a timeout and synchronization attempt in psmosue_interrupt (parent
of this module) so you should be covered. 

> I don't know whether the dropping  of bytes is specific to my machine,
> or is common to all B142 models.
> 
> 
> +static psmouse_ret_t lbtouch_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
> +{
> +	struct input_dev *dev = &psmouse->dev;
> +	unsigned char *p = psmouse->packet;
> +	int x, y, touch;
> +
> +	input_regs(dev, regs);
> +
> +	if (psmouse->pktcnt < 3)
> +		return PSMOUSE_GOOD_DATA;
> +
> 
> The  same problem.   You  wait  for a  complete  3-byte packet  before
> emitting an event.  What happens to dropped bytes?
> 

The packet is dropped when we wait for a byte for too long.

-- 
Dmitry

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Kim" == Kim Holviala <kim@holviala.com> writes:

    Kim> 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.

    Kim> I agree 100%, and that's why I'm working on the driver. I
    Kim> think the biggest issue right now is the Fujitsu TouchScreen
    Kim> - I'll try to steal one of those laptops from work later this
    Kim> week and maybe come up with a solution. It has a Synaptics
    Kim> touchpad too so I get to test that as well.

So, are  you going to port  my XFree86 driver for  my touchscreen into
kernel space?


-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[Kim Holviala]

On Wednesday 21 April 2004 10:18, Sau Dan Lee wrote:

>     Kim> I agree 100%, and that's why I'm working on the driver. I
>     Kim> think the biggest issue right now is the Fujitsu TouchScreen
>     Kim> - I'll try to steal one of those laptops from work later this
>     Kim> week and maybe come up with a solution. It has a Synaptics
>     Kim> touchpad too so I get to test that as well.
>
> So, are  you going to port  my XFree86 driver for  my touchscreen into
> kernel space?

That's what I was thinking.. I had one of those laptops a year ago from work, 
but I gave it away since the keyboard started acting and the touchscreen 
filter on top of the normal TFT looked too blurry to me...

But yes, if and when I get an extra Lifebook I'll look into porting your 
driver.




Kim

Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Kim" == Kim Holviala <kim@holviala.com> writes:

    >>  So, are you going to port my XFree86 driver for my touchscreen
    >> into kernel space?

    Kim> That's what I was thinking.. I had one of those laptops a
    Kim> year ago from work, but I gave it away since the keyboard
    Kim> started acting and the touchscreen filter on top of the
    Kim> normal TFT looked too blurry to me...

    Kim> But yes, if and when I get an extra Lifebook I'll look into
    Kim> porting your driver.

Mine  is  a Lifebook  B142,  not  the  newest ones.   The  touchscreen
hardware may thus be different.

Moreover, I implemented features in my drivers which require timeouts.
That'd be too complicated for me to program in kernel space.


The driver can be downloaded from:

http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/lifebook20010712.tgz


-- 
Sau Dan LEE                     李守敦(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

Re: /dev/psaux-Interface

[tabris]

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

Sau Dan Lee <danlee@informatik.uni-freiburg.de> wrote ..
> >>>>> "Jamie" == Jamie Lokier <jamie@shareable.org> 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.
>
    I'd jump in here at a better point in the thread, but I'm at work right now and this is the only message I can reply to atm...

    I personally have the following problem. I have two mice, one a MS PS/2 Intellimouse. the second, a Logitech optomechanical cordless mouse (and keyboard too) attached via USB (both mouse and keyboard use same receiver as well as USB connection)

    The PS/2 mouse, which requires me to either have the driver built-in, or to manually modprobe, works more or less fine, in both X and console (using GPM). But, my USB mouse, which works fine in X, screws up in console mode. I'm using GPM's repeater function for X.

    Basically what happens is that the USB mouse can move around, but I can't use the buttons. It echoes some of the control codes to my console, and hence makes it useless for cutting and pasting.

    Admittedly, I could just hook up the mouse and keyboard to the PS/2 ports using some adapters, bypassing the USB. and it would probably work. But, why? Why is this broken in 2.6, but not in 2.4?


> 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?
>
>
<snip discussion of Modems>
> SEPARATION  of POLICY  and MECHANISM  is an  important concept  in the
> design of unix.
>
>
<snip discussion of graphics cards>
>
>
>     >> 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.
    I agree here. Admittedly GPM isn't perfect, and should perhaps be rewritten, but it belongs in userspace.
>
> 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?
Because khttpd wasn't that useful, was a bit ugly. Also Tux superseded it. And last of all, most of the stuff that Tux patched to make things faster... were merged into mainline and made available to userspace. So that Apache could do most/all of what Tux could, in userspace, w/ little overhead/cost.
> (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: danlee@informatik.uni-freiburg.de
> Home page: http://www.informatik.uni-freiburg.de/~danlee
>

/dev/psaux-Interface

[Bernhard Gruber]

Hi there,

Story:
As Windows2000 was just so unstable and slow I decided to use Linux on
my Thinkpad 570E. Installation of gentoo was no problem (even if it
took quite long) and I first installed a 2.4.25-kernel. Everything
worked fine there and I could use the trackpoint utilities from Till
Straumann to set the features of the trackpoint. The only problem was,
that ACPI (and APM) did not function properly and so I couldn't get the
current state of the battery (which is quite a large problem for a
laptop). So I tried the 2.6.3-kernel. Apart from minor problems which
could be solved rather quickly I got all devices up and running
including battery monitoring. However, the trackpoint utility did not
work anymore and so the special features like press-to-select and
HARDWARE sensitivity setup do not work until today.

Problem:
As I've read so far, the approach in 2.6.x-kernel was to remove
user-space-drivers as much as possible and one of the consequences was
that the /dev/psaux-Device does not exist as in 2.4.x-kernels. However,
there are some special devices (not only the trackpoint but also
touchscreens for example) which had drivers for 2.4.x-kernels using the
/dev/psaux-interface and most people who programmed those drivers either
don't have the time or don't use/own those devices anymore. Furthermore,
writing kernel device drivers requires more skill and they are harder
to debug. So there's no real hope that they will  ever be ported...

Suggestion:
I would suggest using a /dev/psaux-compatibility option which gives back
the old interface so that these drivers work. This is only meant as a
user-selectable option and I don't think that the new input system
should be changed apart from that! There is already an existing approach
to a kernel patch which can be found here
http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/ It can be
integrated easily into the kernel but it seems like there are still bugs
in there. I'm in contact with the author because the trackpoint utilities
creates a segmentation fault when writing to the device but we could not
figure out a solution yet (it’s strange that his touchscreen device
functions without any problems). We are sure that it would not be a huge
problem to solve it for you guys out there, so if anyone wants to help us
please contact b-gruber[at]gmx.de and I’ll send you a more detailed error
report.


PS: Sorry if my english sounds a little bit bumpy sometimes but I don’t
speak english natively.
I would appreciate if you could cc all answers to my Email-adress as I
haven't subscribed to this mailing-list!

Re: /dev/psaux-Interface

[Bernhard Gruber]

OK, I think, we found out WHY it did not function with my trackpoint.
Actually, it was not the trackpoint but the fact, that I had compiled
in SMP-support into the kernel. I removed it and now the trackpoint
utilities work just fine! It's very likely, that this psaux-module
will work with ANY old driver/utility written for 2.4.X-kernels as
long as you follow the steps on the homepage and remove SMP-support!