Fujitsu B-Series Lifebook PS/2 TouchScreen driver

Hi!

I've reimplemented the Lifebook touchscreen driver using libps2 and input, to make it short and fitting into the kernel drivers.

Please comment on code and test for functionality!

PS.: The driver should register two input devices. It doesn't yet, since that isn't very straightforward in the psmouse framework.

Second thing is that I am not shure that it is a good idea to integrate the lbtouch-support into the psmouse-driver since there is no real way of deciding if the device you are talking to is REALLY a lifebook-touchsreen or not.

IMHO the driver should be standalone and the user should decide which driver he wants to use. As default the touchscreen-functionality will be disabled and only the quick-point device will work like a normal PS2-mouse.

Quoted 5 lines

Second thing is that I am not shure that it is a good idea to integrate the lbtouch-support into the psmouse-driver since there is no real way of deciding if the device you are talking to is REALLY a lifebook-touchsreen or not.

...

Quoted 4 lines

IMHO the driver should be standalone and the user should decide which driver he wants to use. As default the touchscreen-functionality will be disabled and only the quick-point device will work like a normal PS2-mouse.

I just want to point out that this is a problem for distributions and for not-so-technical users.

Is there *really* no way to know if you're on a lifebook? Can't you use say the DMI identification mechanism to find this out ? If so, I think integrating into the regular driver very much is the right thing to do... it makes things JustWork(tm) for users without any need for manual configuration (which also makes distribution makers happy).

Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:

Quoted 12 lines · Kenan Esau

Quoted 5 lines

Second thing is that I am not shure that it is a good idea to integrate the lbtouch-support into the psmouse-driver since there is no real way of deciding if the device you are talking to is REALLY a lifebook-touchsreen or not.

...

Quoted 4 lines

IMHO the driver should be standalone and the user should decide which driver he wants to use. As default the touchscreen-functionality will be disabled and only the quick-point device will work like a normal PS2-mouse.

Quoted 8 lines

I just want to point out that this is a problem for distributions and for not-so-technical users.

Is there *really* no way to know if you're on a lifebook? Can't you use say the DMI identification mechanism to find this out ? If so, I think integrating into the regular driver very much is the right thing to do... it makes things JustWork(tm) for users without any need for manual configuration (which also makes distribution makers happy).

Yes that would be nice. But the lifebook-touchscreen hardware is also used in other notebooks. For example the Panasonic Toughbook CF28. But we could still use DMI to check whether we are on a lifebook b-series and then initialize the hardware. This would still get 95% of all cases. For all the other ones we would have to provide some kind of force-switch.

Second thing is that I am not shure that it is a good idea to integrate the lbtouch-support into the psmouse-driver since there is no real way of deciding if the device you are talking to is REALLY a lifebook-touchsreen or not.

I also don't think that it is useful to have two devices for the touchscreen. I assume you want to have one device for relative movements and one for the absolute ones!? But for the implementor in userspace (X, SDL,...) it will be easier if ALL events from this HW-device come via one device-node.

I think my driver works and is clean enough for integration into the kernel. We can talk about integrating calls to libps2 instead of doing the stuff myself (I am a big fan of preventing code-duplication) but don't you think it would be more wise to use a driver which works (since the very early 2.6-days) and build upon that instead of trying to implement your own one from the scratch and using snippets from very old and obsolete code?

Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

Quoted 7 lines

Hi!

I've reimplemented the Lifebook touchscreen driver using libps2 and input, to make it short and fitting into the kernel drivers.

Please comment on code and test for functionality!

Quoted 2 lines

PS.: The driver should register two input devices. It doesn't yet, since that isn't very straightforward in the psmouse framework.

First of all it's good to see lifebook-support integrated.

I have tested your driver on my box but the initialization fails. Do you have hardware available for testing?

As far as I can see the
init-sequence is the one from Haralds xfree 3.3.6-driver. There is a reason why this sequence is not like that anymore in my driver.

This
sequence does not always work and there is not something like a "magic knock sequence".

The lifebook-touchscreen hardware is a little bit slow
and it happens quite often that it does not understand a command that you send.

This is the reason why you often have to send a command several times until the hardware understands...
Probably this was what was seen by Harald on the USB-bus and he just used this sequence.

Second thing is that I am not shure that it is a good idea to integrate the lbtouch-support into the psmouse-driver since there is no real way of deciding if the device you are talking to is REALLY a lifebook-touchsreen or not.

You have put the init-sequence for the hw into the lifebook_detect-function which is not correct since this not really a "detect" but a HW-init.

IMHO the driver should be standalone and the user should decide which driver he wants to use. As default the touchscreen-functionality will be disabled and only the quick-point device will work like a normal PS2-mouse.

I also don't think that it is useful to have two devices for the touchscreen. I assume you want to have one device for relative movements and one for the absolute ones!?

But for the implementor in userspace (X,
SDL,...) it will be easier if ALL events from this HW-device come via one device-node.

I attached the current version of my driver here so people can also have a look at it. I didn't release this version on my homepage yet and the only difference between the released version an this one is that the y-axis is swapped. I did this since all input devices seem to have a common idea of where y=0 is and my driver was the only one where y was just the other way round.

One more thing I observed by inspecting your code is that your untouch-event will never happen.

I think my driver works and is clean enough for integration into the kernel. We can talk about integrating calls to libps2 instead of doing the stuff myself (I am a big fan of preventing code-duplication) but don't you think it would be more wise to use a driver which works (since the very early 2.6-days) and build upon that instead of trying to implement your own one from the scratch and using snippets from very old and obsolete code?

And as far as I can see you don't even have access to the hardware!?!?

Quoted 2 lines

Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

Quoted 1 line

Hi!

Quoted 3 lines

As far as I can see the
init-sequence is the one from Haralds xfree 3.3.6-driver. There is a reason why this sequence is not like that anymore in my driver.

OK.

Quoted 3 lines

This
sequence does not always work and there is not something like a "magic knock sequence".

You mean that the only needed bit is setting the resolution to '7'?

Quoted 3 lines

The lifebook-touchscreen hardware is a little bit slow
and it happens quite often that it does not understand a command that you send.

I don't believe this - the PS/2 protocol has handshakes for both sides, so each side can slow down as much as it wants. PLUS, the clock is driven by the device.

Quoted 4 lines

This is the reason why you often have to send a command several times until the hardware understands...
Probably this was what was seen by Harald on the USB-bus and he just used this sequence.

USB?!

Quoted 5 lines

Quoted 3 lines

This
sequence does not always work and there is not something like a "magic knock sequence".

You mean that the only needed bit is setting the resolution to '7'?

The lifebook touchscreen has some extensions to the standard protocol:

0xe8 0x06: Stop absolute coordinate output
0xe8 0x07: Start absolute coordinate outpout (3-byte packets) 0xe8 0x08: Start absolute coord. output with 6-byte packets

Quoted 4 lines

Quoted 3 lines

The lifebook-touchscreen hardware is a little bit slow
and it happens quite often that it does not understand a command that you send.

Quoted 3 lines

I don't believe this - the PS/2 protocol has handshakes for both sides, so each side can slow down as much as it wants. PLUS, the clock is driven by the device.

I dont't know the PS2-specs. But I know the lifebook hardware quite well. While implementing my driver (for xfree 4.0 at that time) I noticed that it happens often that the device came back with an error or resend. I fixed this by just waiting a short time and then retry.

If you agree I will take your patch as the basis and make it work. Now I know how you want it to look like.

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

This
sequence does not always work and there is not something like a "magic knock sequence".

You mean that the only needed bit is setting the resolution to '7'?

The lifebook touchscreen has some extensions to the standard protocol:

Quoted 3 lines

0xe8 0x06: Stop absolute coordinate output
0xe8 0x07: Start absolute coordinate outpout (3-byte packets) 0xe8 0x08: Start absolute coord. output with 6-byte packets

Are the 6-byte packets carrying any more information than the 3-byte packets do, for example pressure? Would it be useful to go for the 6-byte mode instead in the driver?

Have you tried whether the controller responds to the GETID (f2), GETINFO (e9) and POLL (eb) commands? Maybe we could detect it that way.

Quoted 2 lines

If you agree I will take your patch as the basis and make it work. Now I know how you want it to look like.

That would be very much appreciated.

Am Sonntag, den 13.02.2005, 13:01 +0100 schrieb Vojtech Pavlik:

Quoted 14 lines · Kenan Esau

Quoted 12 lines

Quoted 6 lines

Quoted 4 lines

This
sequence does not always work and there is not something like a "magic knock sequence".

You mean that the only needed bit is setting the resolution to '7'?

The lifebook touchscreen has some extensions to the standard protocol:

0xe8 0x06: Stop absolute coordinate output
0xe8 0x07: Start absolute coordinate outpout (3-byte packets) 0xe8 0x08: Start absolute coord. output with 6-byte packets

Quoted 3 lines

Are the 6-byte packets carrying any more information than the 3-byte packets do, for example pressure? Would it be useful to go for the 6-byte mode instead in the driver?

No the 6-byte mode does not carry any more information. Sorry but no pressure-info...

Quoted 2 lines

Have you tried whether the controller responds to the GETID (f2), GETINFO (e9) and POLL (eb) commands? Maybe we could detect it that way.

I have to try those commands and check the response. I know that they are supported but I have never tried them.

[...]

Quoted 4 lines

Quoted 2 lines

If you agree I will take your patch as the basis and make it work. Now I know how you want it to look like.

That would be very much appreciated.

OK. I'll send you a new patch within the next week.

Quoted 7 lines · Vojtech Pavlik

+       if (set_properties) {
+               psmouse->vendor = "Fujitsu Lifebook"; +               psmouse->name = "TouchScreen"; +       }

drivers/input/mouse/lifebook.c new file +2 -0

+
+       psmouse->dev.evbit[0] = BIT(EV_ABS) | BIT(EV_KEY) | BIT(EV_REL);

drivers/input/mouse/lifebook.c line 131

Quoted 10 lines

drivers/input/mouse/lifebook.c new file +10 -0

+       psmouse->dev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
+       psmouse->dev.keybit[LONG(BTN_TOUCH)] = BIT(BTN_TOUCH);
+       psmouse->dev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
+       input_set_abs_params(&psmouse->dev, ABS_X, 130, 885, 0, 0);
+       input_set_abs_params(&psmouse->dev, ABS_Y, 272, 830, 0, 0);
+
+       psmouse->protocol_handler = lifebook_process_byte;
+       psmouse->disconnect = lifebook_disconnect;
+       psmouse->reconnect = lifebook_reconnect;
+       psmouse->pktsize = 3;

Hi Vojtech,

I have been trying not alter kernel state in probe routines (still has to touch hardware for mice that do not have separate detection routine) unless set_properties is set. So all of the above should be in "if (set_properties)" statement.

Hi!

I've reimplemented the Lifebook touchscreen driver using libps2 and input, to make it short and fitting into the kernel drivers.

Please comment on code and test for functionality!

PS.: The driver should register two input devices. It doesn't yet, since that isn't very straightforward in the psmouse framework.

Hi!

I've reimplemented the Lifebook touchscreen driver using libps2 and input, to make it short and fitting into the kernel drivers.

Please comment on code and test for functionality!

PS.: The driver should register two input devices. It doesn't yet, since that isn't very straightforward in the psmouse framework.

Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

Here are my changes. I have tested everything on my lifebook B2175 and it works fine for me. I have used DMI for probing. Does anyone have an Idea what devices we have to add to the DMI-probing?

Please comment on the code.

diff -Naur -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.c linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.c

drivers/input/mouse/lifebook.c +20 -0

@@ -0,0 +1,150 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik <[email protected]>
+ *
+ * Copyright (c) 2005 Kenan Esau <[email protected]>
+ *
+ * TouchScreen detection, absolute mode setting and packet layout is taken from
+ * Harald Hoyer's description of the device.
+ *
+ * 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/input.h>
+#include <linux/serio.h>
+#include <linux/libps2.h>
+#include <linux/dmi.h>
+

drivers/input/mouse/lifebook.c +4 -0

+        pkt_cur_touch = packet[0] & LBTOUCH_TOUCHED;
+
+        if ( psmouse->pktcnt != 3 )
+                return PSMOUSE_GOOD_DATA;

drivers/input/mouse/lifebook.c +5 -0

+        input_report_key(dev, BTN_LEFT, pkt_lb);
+        input_report_key(dev, BTN_RIGHT, pkt_rb);
+        input_report_key(dev, BTN_TOUCH, pkt_cur_touch);
+
+	/* currently touched */

drivers/input/mouse/lifebook.c +8 -0

+	input_sync(dev);
+
+        /* save the state for the currently received packet */
+	pkt_lst_touch = pkt_cur_touch;
+
+        return PSMOUSE_FULL_PACKET;
+}
+

drivers/input/mouse/lifebook.c +28 -0

+        psmouse->set_rate(psmouse, psmouse->rate);
+        psmouse->set_resolution(psmouse, psmouse->resolution);
+        
+        if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE))
+		return -1;
+
+        return 0;
+}
+
+static void lifebook_disconnect(struct psmouse *psmouse)
+{
+	psmouse_reset(psmouse);
+}
+
+int lifebook_detect(struct psmouse *psmouse, int set_properties)
+{
+	if (!dmi_check_system(lifebook_dmi_table))
+                return -1;
+
+	if (set_properties) {
+		psmouse->vendor = "Fujitsu Lifebook";
+		psmouse->name = "TouchScreen";
+                psmouse->dev.evbit[0] = BIT(EV_ABS) | BIT(EV_KEY) | BIT(EV_REL);
+                psmouse->dev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
+                psmouse->dev.keybit[LONG(BTN_TOUCH)] = BIT(BTN_TOUCH);
+                psmouse->dev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
+                input_set_abs_params(&psmouse->dev, ABS_X, 130, 885, 0, 0);
+                input_set_abs_params(&psmouse->dev, ABS_Y, 272, 830, 0, 0);

diff -Naur -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.h linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.h

drivers/input/mouse/lifebook.h +16 -0

@@ -0,0 +1,16 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik
+ *
+ * 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 _LIFEBOOK_H
+#define _LIFEBOOK_H
+
+int lifebook_detect(struct psmouse *psmouse, int set_properties);
+
+#endif

diff -Naur -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/mouse/Makefile linux-2.6.11-rc3-kenan/drivers/input/mouse/Makefile

drivers/input/mouse/Makefile +1 -1

@@ -14,4 +14,4 @@
 obj-$(CONFIG_MOUSE_SERIAL)	+= sermouse.o
 obj-$(CONFIG_MOUSE_VSXXXAA)	+= vsxxxaa.o
 
-psmouse-objs  := psmouse-base.o alps.o logips2pp.o synaptics.o
+psmouse-objs  := psmouse-base.o alps.o logips2pp.o synaptics.o lifebook.o

diff -Naur -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/mouse/psmouse-base.c linux-2.6.11-rc3-kenan/drivers/input/mouse/psmouse-base.c

drivers/input/mouse/psmouse-base.c +17 -7

@@ -24,6 +24,7 @@
 #include "synaptics.h"
 #include "logips2pp.h"
 #include "alps.h"
+#include "lifebook.h"
 
 #define DRIVER_DESC	"PS/2 mouse driver"
 

@@ -62,7 +63,7 @@
 __obsolete_setup("psmouse_resetafter=");
 __obsolete_setup("psmouse_rate=");
 
-static char *psmouse_protocols[] = { "None", "PS/2", "PS2++", "ThinkPS/2", "GenPS/2", "ImPS/2", "ImExPS/2", "SynPS/2", "AlpsPS/2" };
+static char *psmouse_protocols[] = { "None", "PS/2", "PS2++", "ThinkPS/2", "GenPS/2", "ImPS/2", "ImExPS/2", "SynPS/2", "AlpsPS/2", "LBPS/2" };
 
 /*
  * psmouse_process_byte() analyzes the PS/2 data stream and reports

@@ -463,6 +464,9 @@
 		}
 	}
 
+	if (max_proto > PSMOUSE_IMEX && lifebook_detect(psmouse, set_properties) == 0)
+		return PSMOUSE_LIFEBOOK;
+
 	if (max_proto > PSMOUSE_IMEX && genius_detect(psmouse, set_properties) == 0)
 		return PSMOUSE_GENPS;
 

@@ -565,13 +569,13 @@
  * psmouse_initialize() initializes the mouse to a sane state.
  */
 
-static void psmouse_initialize(struct psmouse *psmouse)
+static int psmouse_initialize(struct psmouse *psmouse)
 {
 /*
  * We set the mouse into streaming mode.
  */
-
-	ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
+	if (ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM))
+                return -1;
 
 /*
  * We set the mouse report rate, resolution and scaling.

@@ -580,8 +584,11 @@
 	if (psmouse_max_proto != PSMOUSE_PS2) {
 		psmouse->set_rate(psmouse, psmouse->rate);
 		psmouse->set_resolution(psmouse, psmouse->resolution);
-		ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSCALE11);
+                if (ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSCALE11))
+                        return -1;
 	}
+
+        return 0;
 }
 
 /*

@@ -719,6 +726,7 @@
 	}
 
 	psmouse->rate = psmouse_rate;
+        psmouse->initialize = psmouse_initialize;
 	psmouse->resolution = psmouse_resolution;
 	psmouse->resetafter = psmouse_resetafter;
 	psmouse->smartscroll = psmouse_smartscroll;

@@ -747,7 +755,8 @@
 
 	psmouse_set_state(psmouse, PSMOUSE_CMD_MODE);
 
-	psmouse_initialize(psmouse);
+        if (psmouse->initialize(psmouse))
+                printk(KERN_ERR"input: %s initialization failed\n", psmouse->devname);
 
 	if (parent && parent->pt_activate)
 		parent->pt_activate(parent);

@@ -804,7 +813,8 @@
 	 */
 	psmouse_set_state(psmouse, PSMOUSE_CMD_MODE);
 
-	psmouse_initialize(psmouse);
+        if (psmouse->initialize(psmouse))
+                printk(KERN_ERR"input: %s initialization failed\n", psmouse->devname);
 
 	if (parent && parent->pt_activate)
 		parent->pt_activate(parent);

diff -Naur -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/mouse/psmouse.h linux-2.6.11-rc3-kenan/drivers/input/mouse/psmouse.h

drivers/input/mouse/psmouse.h +2 -0

@@ -60,6 +60,7 @@
 	void (*set_rate)(struct psmouse *psmouse, unsigned int rate);
 	void (*set_resolution)(struct psmouse *psmouse, unsigned int resolution);
 
+        int (*initialize)(struct psmouse *psmouse);
 	int (*reconnect)(struct psmouse *psmouse);
 	void (*disconnect)(struct psmouse *psmouse);
 

@@ -77,6 +78,7 @@
 	PSMOUSE_IMEX,
 	PSMOUSE_SYNAPTICS,
 	PSMOUSE_ALPS,
+	PSMOUSE_LIFEBOOK,
 };
 
 int psmouse_sliced_command(struct psmouse *psmouse, unsigned char command);

drivers/input/mouse/lifebook.c line 40

Quoted 9 lines · Kenan Esau

drivers/input/mouse/lifebook.c +9 -0

+static struct dmi_system_id lifebook_dmi_table[] = {
+     {
+             .ident = "Fujitsu Siemens Lifebook B-Sereis",
+             .matches = {
+                     DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
+             },
+     },
+     { }
+};

This might be a bit too much generic. Are you sure there are no B Series lifebooks without a touchscreen?

drivers/input/mouse/lifebook.c line 53

Quoted 11 lines

drivers/input/mouse/lifebook.c +11 -0

+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+     unsigned char *packet = psmouse->packet;
+     struct input_dev *dev = &psmouse->dev;
+
+        unsigned long x = 0;
+        unsigned long y = 0;
+        static uint8_t pkt_lst_touch = 0;
+     static uint8_t pkt_cur_touch = 0;
+     uint8_t pkt_lb = packet[0] & LBTOUCH_LB;
+     uint8_t pkt_rb = packet[0] & LBTOUCH_RB;

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+
+                psmouse->protocol_handler = lifebook_process_byte;
+                psmouse->disconnect = lifebook_disconnect;
+                psmouse->reconnect  = lifebook_initialize;

drivers/input/mouse/lifebook.c line 150

Quoted 6 lines

drivers/input/mouse/lifebook.c +6 -0

+                psmouse->initialize = lifebook_initialize;
+                psmouse->pktsize = 3;
+     }
+
+     return 0;
+}

The change to the psmouse interface I'm leaving to Dmitry to comment on.

Quoted 5 lines · Kenan Esau

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+static struct dmi_system_id lifebook_dmi_table[] = {
+     {
+             .ident = "Fujitsu Siemens Lifebook B-Sereis",
+             .matches = {

Quoted 9 lines

drivers/input/mouse/lifebook.c line 40

Quoted 5 lines

drivers/input/mouse/lifebook.c +5 -0

+                     DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
+             },
+     },
+     { }
+};

This might be a bit too much generic. Are you sure there are no B Series lifebooks without a touchscreen?

And another concern: does this notebook (or others using this touchscreen) have an active MUX? We don't want to force LBTOUCH protocol on an external mouse.

Quoted 11 lines

drivers/input/mouse/lifebook.c line 53

Quoted 11 lines

drivers/input/mouse/lifebook.c +11 -0

+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+     unsigned char *packet = psmouse->packet;
+     struct input_dev *dev = &psmouse->dev;
+
+        unsigned long x = 0;
+        unsigned long y = 0;
+        static uint8_t pkt_lst_touch = 0;
+     static uint8_t pkt_cur_touch = 0;
+     uint8_t pkt_lb = packet[0] & LBTOUCH_LB;
+     uint8_t pkt_rb = packet[0] & LBTOUCH_RB;

We usually don't use userspace types here. unsigned char or u8 for kernel.

Quoted 4 lines

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+
+                psmouse->protocol_handler = lifebook_process_byte;
+                psmouse->disconnect = lifebook_disconnect;
+                psmouse->reconnect  = lifebook_initialize;

Quoted 8 lines

drivers/input/mouse/lifebook.c line 150

Quoted 6 lines

drivers/input/mouse/lifebook.c +6 -0

+                psmouse->initialize = lifebook_initialize;
+                psmouse->pktsize = 3;
+     }
+
+     return 0;
+}

The change to the psmouse interface I'm leaving to Dmitry to comment on.

I don't think that we need a separate initialize handler simply because it is called just once, at initialization time. Here we know exactly what device (protocol) we are dealing with, no need for indirection.

All B-Series Lifebooks have the same touchscreen-hardware. But Dmitri's concern is correct -- at the moment I would enforce the LBTOUCH-protocol on external mice...

I have to fix this. I will additionally to the DMI stuff use "Status Request". On a "Request ID"-Command the Device always answers with a 0x00 -- could this also be helpfull?

Am Dienstag, den 15.02.2005, 09:43 -0500 schrieb Dmitry Torokhov:

Quoted 16 lines · Vojtech Pavlik

Quoted 5 lines · Kenan Esau

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+static struct dmi_system_id lifebook_dmi_table[] = {
+     {
+             .ident = "Fujitsu Siemens Lifebook B-Sereis",
+             .matches = {

Quoted 9 lines

drivers/input/mouse/lifebook.c line 40

Quoted 5 lines

drivers/input/mouse/lifebook.c +5 -0

+                     DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
+             },
+     },
+     { }
+};

This might be a bit too much generic. Are you sure there are no B Series lifebooks without a touchscreen?

Quoted 3 lines

And another concern: does this notebook (or others using this touchscreen) have an active MUX? We don't want to force LBTOUCH protocol on an external mouse.

All B-Series Lifebooks have the same touchscreen-hardware. But Dmitri's concern is correct -- at the moment I would enforce the LBTOUCH-protocol on external mice...

I have to fix this. I will additionally to the DMI stuff use "Status Request". On a "Request ID"-Command the Device always answers with a 0x00 -- could this also be helpfull?

Quoted 27 lines

Quoted 11 lines

drivers/input/mouse/lifebook.c line 53

Quoted 11 lines

drivers/input/mouse/lifebook.c +11 -0

+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+     unsigned char *packet = psmouse->packet;
+     struct input_dev *dev = &psmouse->dev;
+
+        unsigned long x = 0;
+        unsigned long y = 0;
+        static uint8_t pkt_lst_touch = 0;
+     static uint8_t pkt_cur_touch = 0;
+     uint8_t pkt_lb = packet[0] & LBTOUCH_LB;
+     uint8_t pkt_rb = packet[0] & LBTOUCH_RB;

We usually don't use userspace types here. unsigned char or u8 for kernel.

Quoted 4 lines

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+
+                psmouse->protocol_handler = lifebook_process_byte;
+                psmouse->disconnect = lifebook_disconnect;
+                psmouse->reconnect  = lifebook_initialize;

Quoted 8 lines

drivers/input/mouse/lifebook.c line 150

Quoted 6 lines

drivers/input/mouse/lifebook.c +6 -0

+                psmouse->initialize = lifebook_initialize;
+                psmouse->pktsize = 3;
+     }
+
+     return 0;
+}

The change to the psmouse interface I'm leaving to Dmitry to comment on.

Quoted 4 lines

I don't think that we need a separate initialize handler simply because it is called just once, at initialization time. Here we know exactly what device (protocol) we are dealing with, no need for indirection.

I introduced the new initialize-handler since psmouse->initialize() is also used in psmouse-base.c. This is to prevent putting if-statements on each place where the initialization-function for a certain protocol is called in psmouse-base.c.

I admit since I am also using a different reconnect-function than psmouse-base it's not such a huge benefit but think of a new protocol/device which uses the same reconnect-function as psmouse-base but a different init-function.

My goal was to have no dependency from psmouse-base to the lifebook-handling (none but lifebook_detect()). Thus the indirection is IMHO needed.

Quoted 38 lines

Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

Here are my changes. I have tested everything on my lifebook B2175 and it works fine for me. I have used DMI for probing. Does anyone have an Idea what devices we have to add to the DMI-probing?

Please comment on the code.

diff -Naur -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.c linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.c

drivers/input/mouse/lifebook.c +26 -0

@@ -0,0 +1,150 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik <[email protected]>
+ *
+ * Copyright (c) 2005 Kenan Esau <[email protected]>
+ *
+ * TouchScreen detection, absolute mode setting and packet layout is taken from
+ * Harald Hoyer's description of the device.
+ *
+ * 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/input.h>
+#include <linux/serio.h>
+#include <linux/libps2.h>
+#include <linux/dmi.h>
+
+#include "psmouse.h"
+#include "lifebook.h"
+
+#define LBTOUCH_TOUCHED 0x04
+#define LBTOUCH_X_HIGH  0x30
+#define LBTOUCH_Y_HIGH  0xC0

drivers/input/mouse/lifebook.c line 30

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+#define LBTOUCH_LB      0x01
+#define LBTOUCH_RB      0x02
+
+static int max_y = 937;

This doesn't look correct. I think the correct value here is 1024, because that's what is the maximum possible value transfered in the packet. With 937 you can get negative values in your code.

drivers/input/mouse/lifebook.c line 40

Quoted 9 lines

drivers/input/mouse/lifebook.c +9 -0

+static struct dmi_system_id lifebook_dmi_table[] = {
+	{
+		.ident = "Fujitsu Siemens Lifebook B-Sereis",
+		.matches = {
+			DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
+		},
+	},
+	{ }
+};

This might be a bit too much generic. Are you sure there are no B Series lifebooks without a touchscreen?

drivers/input/mouse/lifebook.c line 53

Quoted 11 lines

drivers/input/mouse/lifebook.c +11 -0

+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	unsigned char *packet = psmouse->packet;
+	struct input_dev *dev = &psmouse->dev;
+
+        unsigned long x = 0;
+        unsigned long y = 0;
+        static uint8_t pkt_lst_touch = 0;
+	static uint8_t pkt_cur_touch = 0;
+	uint8_t pkt_lb = packet[0] & LBTOUCH_LB;
+	uint8_t pkt_rb = packet[0] & LBTOUCH_RB;

Tab/space damage here. Do we really need constants for everything? They don't carry any information value, because we already know what the mask means from the left side of the assignment.

Another use for constants is where the value would possibly change, which again isn't the case with masks.

Also, input_regs() is missing here.

Quoted 10 lines

drivers/input/mouse/lifebook.c +10 -0

+        pkt_cur_touch = packet[0] & LBTOUCH_TOUCHED;
+
+        if ( psmouse->pktcnt != 3 )
+                return PSMOUSE_GOOD_DATA;
+
+	/* calculate X and Y */
+	if (pkt_cur_touch) {
+		x = (packet[1] | ((packet[0] & LBTOUCH_X_HIGH) << 4 ));
+		y = max_y - 
+                    (packet[2] | ((packet[0] & LBTOUCH_Y_HIGH) << 2 ));

drivers/input/mouse/lifebook.c line 68

Quoted 4 lines

drivers/input/mouse/lifebook.c +4 -0

+	} else {
+		x = ((packet[0] & 0x10) ? packet[1]-256 : packet[1]);
+		y = - ((packet[0] & 0x20) ? packet[2]-256 : packet[2]);
+	}

This doesn't make sense. As far as I know, there is bit 3 in byte 0 which signifies a relative packet. We don't need to take the decision how to interpret the axis values based on the touch bit!

Quoted 6 lines

drivers/input/mouse/lifebook.c +5 -0

+        input_report_key(dev, BTN_LEFT, pkt_lb);
+        input_report_key(dev, BTN_RIGHT, pkt_rb);
+        input_report_key(dev, BTN_TOUCH, pkt_cur_touch);
+
+	/* currently touched */

drivers/input/mouse/lifebook.c line 84

Quoted 10 lines

drivers/input/mouse/lifebook.c +10 -0

+	if (pkt_cur_touch) {
+                input_report_abs(dev, ABS_X, x);
+                input_report_abs(dev, ABS_Y, y);
+        }
+
+	/* quickpoint move */
+	if ( !pkt_cur_touch && !pkt_lst_touch  &&  (x || y ) ) {
+                input_report_rel(dev, REL_X, x);
+                input_report_rel(dev, REL_Y, y);
+        }

You don't need to check for x and y being nonzero here.

This looks like a stupid workaround for not using the relative/absolute bit I refer to above properly.

Also, you can simply merge the reporting and computing of the x/y values, making the use of the two variables completely unnecessary.

Quoted 14 lines

drivers/input/mouse/lifebook.c +13 -0

+	input_sync(dev);
+
+        /* save the state for the currently received packet */
+	pkt_lst_touch = pkt_cur_touch;
+
+        return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = &psmouse->ps2dev;
+        unsigned char param;
+

drivers/input/mouse/lifebook.c line 103

Quoted 5 lines

drivers/input/mouse/lifebook.c +5 -0

+        if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+        if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;

Do we need two resets here? I'd expect RESET_BAT to override completely everything.

drivers/input/mouse/lifebook.c line 111

Quoted 9 lines

drivers/input/mouse/lifebook.c +8 -0

+
+        /* 
+           Enable absolute output -- ps2_command fails always but if
+           you leave this call out the touchsreen will never send
+           absolute coordinates
+        */ 
+        param = 0x07;
+        ps2_command(ps2dev, &param, PSMOUSE_CMD_SETRES);

Have you checked whether really the touchscreen sends a 0xfe error back, or some other value, or timeout? i8042.debug=1 is your friend here.

Quoted 1 line

Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

drivers/input/mouse/lifebook.c line 111

Quoted 8 lines

drivers/input/mouse/lifebook.c +8 -0

+
+        /* 
+           Enable absolute output -- ps2_command fails always but if
+           you leave this call out the touchsreen will never send
+           absolute coordinates
+        */ 
+        param = 0x07;
+        ps2_command(ps2dev, &param, PSMOUSE_CMD_SETRES);

Have you checked whether really the touchscreen sends a 0xfe error back, or some other value, or timeout? i8042.debug=1 is your friend here.

Quoted 9 lines

Quoted 8 lines

drivers/input/mouse/lifebook.c +8 -0

+
+        /* 
+           Enable absolute output -- ps2_command fails always but if
+           you leave this call out the touchsreen will never send
+           absolute coordinates
+        */ 
+        param = 0x07;
+        ps2_command(ps2dev, &param, PSMOUSE_CMD_SETRES);

Quoted 2 lines

Have you checked whether really the touchscreen sends a 0xfe error back, or some other value, or timeout? i8042.debug=1 is your friend here.

Yes the answer is 0xfe.

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

drivers/input/mouse/lifebook.c +8 -0

+
+        /* 
+           Enable absolute output -- ps2_command fails always but if
+           you leave this call out the touchsreen will never send
+           absolute coordinates
+        */ 
+        param = 0x07;
+        ps2_command(ps2dev, &param, PSMOUSE_CMD_SETRES);

Quoted 4 lines

Quoted 2 lines

Have you checked whether really the touchscreen sends a 0xfe error back, or some other value, or timeout? i8042.debug=1 is your friend here.

Yes the answer is 0xfe.

Would you be so kind to post the 'dmesg' log?

Quoted 1 line

Would you be so kind to post the 'dmesg' log?

Shure -- here you are...

...
input: LBPS/2 Fujitsu Lifebook TouchScreen on isa0060/serio1 drivers/input/serio/i8042.c: d4 -> i8042 (command) [78488524] drivers/input/serio/i8042.c: f5 -> i8042 (parameter) [78488524] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78488532] drivers/input/serio/i8042.c: d4 -> i8042 (command) [78488753] drivers/input/serio/i8042.c: ff -> i8042 (parameter) [78488753] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78488759] drivers/input/serio/i8042.c: aa <- i8042 (interrupt, aux, 12) [78488822] drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [78488823] drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489004] drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [78489004] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78489009] drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489009] drivers/input/serio/i8042.c: 07 -> i8042 (parameter) [78489009] drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12) [78489014]

drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489014] drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [78489014] drivers/input/serio/i8042.c: fc <- i8042 (interrupt, aux, 12) [78489018]

drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489216] drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [78489216] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78489218] drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489219]

drivers/input/serio/i8042.c: 03 -> i8042 (parameter) [78489219] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78489223] drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489223] drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [78489223] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78489228] drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489229] drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [78489229] drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [78489233]

Quoted 3 lines

drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489009] drivers/input/serio/i8042.c: 07 -> i8042 (parameter) [78489009] drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12) [78489014]

Ok, this is a regular 'I don't know what you mean' response from the pad.

Quoted 3 lines

drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489014] drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [78489014] drivers/input/serio/i8042.c: fc <- i8042 (interrupt, aux, 12) [78489018]

But this return code is _very_ unusual. 0xfc means 'basic assurance test failure' and should be reported only as a response to the 0xff command.

Quoted 12 lines

Quoted 4 lines

drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489009] drivers/input/serio/i8042.c: 07 -> i8042 (parameter) [78489009] drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12) [78489014]

Ok, this is a regular 'I don't know what you mean' response from the pad.

Quoted 3 lines

drivers/input/serio/i8042.c: d4 -> i8042 (command) [78489014] drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [78489014] drivers/input/serio/i8042.c: fc <- i8042 (interrupt, aux, 12) [78489018]

Quoted 2 lines

But this return code is _very_ unusual. 0xfc means 'basic assurance test failure' and should be reported only as a response to the 0xff command.

Kenan, can you check whether the 0xfc response is there even if you don't do the setres 7 command before this one?

Quoted 5 lines

Quoted 2 lines

But this return code is _very_ unusual. 0xfc means 'basic assurance test failure' and should be reported only as a response to the 0xff command.

Kenan, can you check whether the 0xfc response is there even if you don't do the setres 7 command before this one?

Yes OK -- I will check. But as far as I know the 0xfe-answer from the touchscreen means: "Please resend the last command".

And 0xfc means:
"Error I didn't get that".

I also checked my original standalone-driver: Because of this behaviour I always retried the last command 3 times if the responce from the device was 0xfe or 0xfc.

Quoted 4 lines

I also checked my original standalone-driver: Because of this behaviour I always retried the last command 3 times if the responce from the device was 0xfe or 0xfc.

And did it actually help? Did the touchscreen ever respond with a 0xfa "ACK, OK" response to these commands?

Quoted 4 lines

Quoted 3 lines

I also checked my original standalone-driver: Because of this behaviour I always retried the last command 3 times if the responce from the device was 0xfe or 0xfc.

Quoted 2 lines

And did it actually help? Did the touchscreen ever respond with a 0xfa "ACK, OK" response to these commands?

I played around a little bit last weekend. And obviously the touchscreen always responds 0xfe to the 0xe8 0x07 command. Also repeating the command does not really help. After the firxt 0x07 you get back the 0xfe and the next byte you send to the device is ALWAYS answered by a 0xfc!?!?

At the end of this mail you'll find some traces I did.

I also wonder if it is possible at all to probe this device. I think not. IMHO we should go for a module-parameter which enforces the lifebook-protokoll. Something like "force_lb=1". Any Ideas / suggestions?

How does this work out with a second/external mouse?

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

I also checked my original standalone-driver: Because of this behaviour I always retried the last command 3 times if the responce from the device was 0xfe or 0xfc.

Quoted 8 lines

Quoted 2 lines

And did it actually help? Did the touchscreen ever respond with a 0xfa "ACK, OK" response to these commands?

I played around a little bit last weekend. And obviously the touchscreen always responds 0xfe to the 0xe8 0x07 command. Also repeating the command does not really help. After the firxt 0x07 you get back the 0xfe and the next byte you send to the device is ALWAYS answered by a 0xfc!?!?

This looks like it either expects some other data (like a second parameter to the command?) or just wants the 0x07 again (and not the whole command) to make sure you really mean it.

Could you try sending 0xe8 0x07 0x07?

Quoted 6 lines

At the end of this mail you'll find some traces I did.

I also wonder if it is possible at all to probe this device. I think not. IMHO we should go for a module-parameter which enforces the lifebook-protokoll. Something like "force_lb=1". Any Ideas / suggestions?

I'd suggest using psmouse.proto=lifebook

Quoted 1 line

How does this work out with a second/external mouse?

The external mouse has to be in bare PS/2 mode anyway, so we don't need to care.

Quoted 5 lines

This looks like it either expects some other data (like a second parameter to the command?) or just wants the 0x07 again (and not the whole command) to make sure you really mean it.

Could you try sending 0xe8 0x07 0x07?

My old driver did that. But with the same result. It doesn't seem to matter what the first and the second bytes are -- the answers from the device are alway the same.

Quoted 7 lines

Quoted 6 lines

At the end of this mail you'll find some traces I did.

I also wonder if it is possible at all to probe this device. I think not. IMHO we should go for a module-parameter which enforces the lifebook-protokoll. Something like "force_lb=1". Any Ideas / suggestions?

Quoted 1 line

I'd suggest using psmouse.proto=lifebook

The current patch has implemented it that way. But the meaning is a little bit different. With proto=lifebook you ENFORCE the lifebook protocol. As far as I read the meaning of the other ones this does not really enforce these protocols.

Quoted 4 lines

Quoted 1 line

How does this work out with a second/external mouse?

The external mouse has to be in bare PS/2 mode anyway, so we don't need to care.

Why that?

Quoted 5 lines

Quoted 5 lines

This looks like it either expects some other data (like a second parameter to the command?) or just wants the 0x07 again (and not the whole command) to make sure you really mean it.

Quoted 5 lines

Quoted 1 line

Could you try sending 0xe8 0x07 0x07?

My old driver did that. But with the same result. It doesn't seem to matter what the first and the second bytes are -- the answers from the device are alway the same.

So even 0xe8 0x03 returns error?

Maybe we should send a command after this (any command), to make sure the

	psmouse->set_rate(psmouse, psmouse->rate);

call succeeds and is not confused by the 0xfc response.

Quoted 9 lines

Quoted 8 lines

Quoted 6 lines

At the end of this mail you'll find some traces I did.

I also wonder if it is possible at all to probe this device. I think not. IMHO we should go for a module-parameter which enforces the lifebook-protokoll. Something like "force_lb=1". Any Ideas / suggestions?

I'd suggest using psmouse.proto=lifebook

Quoted 4 lines

The current patch has implemented it that way. But the meaning is a little bit different. With proto=lifebook you ENFORCE the lifebook protocol. As far as I read the meaning of the other ones this does not really enforce these protocols.

That's OK. I'd like to keep the DMI probing as well, though, so it's not absolutely necessary to provide the parameter.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

How does this work out with a second/external mouse?

The external mouse has to be in bare PS/2 mode anyway, so we don't need to care.

Why that?

Can you send any commands to the external mouse? How the touchscreen reacts when the mouse starts sending 4-byte responses?

We process the
external mouse packets inside lifebook.c anyway and we don't have any support for the enhanced protocols there.

Quoted 14 lines

Quoted 13 lines

Quoted 8 lines

Quoted 6 lines

At the end of this mail you'll find some traces I did.

I also wonder if it is possible at all to probe this device. I think not. IMHO we should go for a module-parameter which enforces the lifebook-protokoll. Something like "force_lb=1". Any Ideas / suggestions?

I'd suggest using psmouse.proto=lifebook

The current patch has implemented it that way. But the meaning is a little bit different. With proto=lifebook you ENFORCE the lifebook protocol. As far as I read the meaning of the other ones this does not really enforce these protocols.

Quoted 2 lines

That's OK. I'd like to keep the DMI probing as well, though, so it's not absolutely necessary to provide the parameter.

You mean if the device is in the appropriate DMI-database use the lifebook protocol and if the parameter is provided use it also (although it might not be in the DMI database)?

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

How does this work out with a second/external mouse?

The external mouse has to be in bare PS/2 mode anyway, so we don't need to care.

Why that?

Can you send any commands to the external mouse? How the touchscreen reacts when the mouse starts sending 4-byte responses?

No idea yet -- I will test this.

Quoted 2 lines

We process the external mouse packets inside lifebook.c anyway and we don't have any support for the enhanced protocols there.

Ah OK.

I personally never used an external mouse. But last weekend I played around a little bit and recognized that there are some BIOS-settings which control the behavior of the touchscreen, quickpoint-device and external mouse. I have to play around with those a little bit more. But as far as I can see you can never have all three at the same time.

Here is a new version of the patch:
- minimal changes
- reintroduced DMI-probing

I had a look at the synaptic-sources to see how the pass-through-mode is implemented. We'll see if something similar to this also works with the lifebook.

I received a request from a user who has a Panasonic CF-29. It also seems to have the same Touchscreen hardware like the lifebook. But it doesn't seem to work as expected. Can someone get hold of a CF-29 and test the psmouse-patch with it?

Quoted 4 lines · Kenan Esau

Here is a new version of the patch:
- minimal changes
- reintroduced DMI-probing

Quoted 3 lines

I had a look at the synaptic-sources to see how the pass-through-mode is implemented. We'll see if something similar to this also works with the lifebook.

Thanks, I applied this version of the patch to my tree. It'll appear in next -mm, and in 2.6.13.

Quoted 9 lines · Kenan Esau

Quoted 7 lines

Here is a new version of the patch:
- minimal changes
- reintroduced DMI-probing

I had a look at the synaptic-sources to see how the pass-through-mode is implemented. We'll see if something similar to this also works with the lifebook.

Quoted 3 lines

Thanks, I applied this version of the patch to my tree. It'll appear in next -mm, and in 2.6.13.

There are couple of things that I an concerned with:

1. I don't like that it overrides meaning of max_proto parameter to be exactly the protocol specified.

However, if you take my psmouse
protocol switching through sysfs patch we can drop that change and require that non auto-detectable protocols be activated through sysfs after loading the driver.

2. It looks like it bypasses rate and resolution setting in psmouse_initialize. What was the reason for it? Does setting rate or resolution disturbs lifebook mode? If so the driver has to implement it's own set_rate and set_resolution handlers so when one tries to change rate from userspace (through sysfs) the request would be ignored.

Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov:

Quoted 10 lines · Vojtech Pavlik

Quoted 9 lines · Kenan Esau

Quoted 7 lines

Here is a new version of the patch:
- minimal changes
- reintroduced DMI-probing

I had a look at the synaptic-sources to see how the pass-through-mode is implemented. We'll see if something similar to this also works with the lifebook.

Quoted 8 lines

Quoted 3 lines

Thanks, I applied this version of the patch to my tree. It'll appear in next -mm, and in 2.6.13.

There are couple of things that I an concerned with:

1. I don't like that it overrides meaning of max_proto parameter to be exactly the protocol specified.

Yeah -- I agree. I also don't like that double-meaning. That was the reason why I originally proposed the use of a new parameter...

Quoted 4 lines

However, if you take my psmouse
protocol switching through sysfs patch we can drop that change and require that non auto-detectable protocols be activated through sysfs after loading the driver.

I think that would also be a good solution.

Quoted 6 lines

2. It looks like it bypasses rate and resolution setting in psmouse_initialize. What was the reason for it? Does setting rate or resolution disturbs lifebook mode? If so the driver has to implement it's own set_rate and set_resolution handlers so when one tries to change rate from userspace (through sysfs) the request would be ignored.

IMHO it does not make sense to call psmouse_initialize() although it does not disturb lifebook-mode. But setting resolution is already done during lifebook_initialize(). And there psmouse->set_resolution() and psmouse->set_rate() are used so setting resolution and rate should also work via sysfs.

Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov:

Quoted 5 lines

There are couple of things that I an concerned with:

1. I don't like that it overrides meaning of max_proto parameter to be exactly the protocol specified.

Yeah -- I agree. I also don't like that double-meaning. That was the reason why I originally proposed the use of a new parameter...

Patches 1-3 are fine.

Protocol switching via sysfs works too but if I switch from LBPS/2 to PS/2 the device name changes from "/dev/event1" to "/dev/event2" -- is this intended?

If I do "echo -n 50 > resolution" "0xe8 0x01" is sent. I don't know if this is correct for "usual" PS/2-devices but for the lifebook it's wrong.

For the lifebook the parameters are as following:

50cpi <=> 0x00
100cpi <=> 0x01
200cpi <=> 0x02
400cpi <=> 0x03

Hi Kenan,

Quoted 11 lines

If I do "echo -n 50 > resolution" "0xe8 0x01" is sent. I don't know if this is correct for "usual" PS/2-devices but for the lifebook it's wrong.

For the lifebook the parameters are as following:

50cpi <=> 0x00
100cpi <=> 0x01
200cpi <=> 0x02
400cpi <=> 0x03

"Classic" PS/2 protocol specifies available resolutions of 1, 2, 4 and 8 units per mm which gives you 25, 50, 100 and 200 cpi respectively. I am surprised that Lifebook simply doubles the rates, but if it does I guess the patch below will suffice.

===================================================================

Input: lifebook - DMI facility is only available on i386, do not
attempt to compile on anything else.

Quoted 4 lines · Dmitry Torokhov

===================================================================

Input: lifebook - DMI facility is only available on i386, do not
attempt to compile on anything else.

Why would you want to build a driver for an x86 laptop on anything
but x86 ? Ie, why not just add a dependancy in the Kconfig
so you don't have to add ifdefs to the code ?

===================================================================

Input: lifebook - DMI facility is only available on i386, do not
attempt to compile on anything else.

Quoted 10 lines · Kenan Esau

Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov:

Quoted 5 lines

There are couple of things that I an concerned with:

1. I don't like that it overrides meaning of max_proto parameter to be exactly the protocol specified.

Yeah -- I agree. I also don't like that double-meaning. That was the reason why I originally proposed the use of a new parameter...

Ok, I have some patches to lifebook that I would like to included (if they work):

1. lifebook-dmi-x86-only - do not compile in DMI detection on anything but x86.

Quoted 12 lines · Dmitry Torokhov

Quoted 10 lines · Kenan Esau

Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov:

Quoted 5 lines

There are couple of things that I an concerned with:

1. I don't like that it overrides meaning of max_proto parameter to be exactly the protocol specified.

Yeah -- I agree. I also don't like that double-meaning. That was the reason why I originally proposed the use of a new parameter...

Quoted 5 lines

Ok, I have some patches to lifebook that I would like to included (if they work):

1. lifebook-dmi-x86-only - do not compile in DMI detection on anything but x86.

On !x86 machines DMI functions will be optimized away and so you'll save only few bytes in .init.data section. IMHO it's not worth additional ugly #ifdef's.