Re: [PATCH 4/4] psmouse: dynamic protocol switching via sysfs

2005-04-04 Thread Kenan Esau
Am Montag, den 04.04.2005, 00:45 -0500 schrieb Dmitry Torokhov:
> Hi Kenan,
> 

[..]

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

Yes -- exactly. That was what I was thinking about. I was just not shure
whether it is lifebook specific or not.

I haven't tested the patch yet. But by inspecting the code it looks
good ;-)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/4] psmouse: dynamic protocol switching via sysfs

2005-04-04 Thread Kenan Esau
Am Montag, den 04.04.2005, 00:45 -0500 schrieb Dmitry Torokhov:
 Hi Kenan,
 

[..]

  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. 

Yes -- exactly. That was what I was thinking about. I was just not shure
whether it is lifebook specific or not.

I haven't tested the patch yet. But by inspecting the code it looks
good ;-)




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/4] psmouse: dynamic protocol switching via sysfs

2005-04-03 Thread Kenan Esau
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/4] psmouse: dynamic protocol switching via sysfs

2005-04-03 Thread Kenan Esau
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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-21 Thread Kenan Esau
Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov:
> On Mon, 21 Mar 2005 13:44:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Tue, Mar 15, 2005 at 02:25:42PM +0100, Kenan Esau wrote:
> > > 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.
> > 
> > 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...

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

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

My stomach feels strange when I call lifebook_initialize() and after
that call an xy_initialize() for some other protocol although it might
not disturb the lifebook-mode.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-21 Thread Kenan Esau
Am Montag, den 21.03.2005, 09:52 -0500 schrieb Dmitry Torokhov:
 On Mon, 21 Mar 2005 13:44:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
  On Tue, Mar 15, 2005 at 02:25:42PM +0100, Kenan Esau wrote:
   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.
  
  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...

 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.

 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.

My stomach feels strange when I call lifebook_initialize() and after
that call an xy_initialize() for some other protocol although it might
not disturb the lifebook-mode.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-15 Thread Kenan Esau
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?
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.c linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c
--- linux-2.6.11.3/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c	2005-03-15 10:04:34.0 +0100
@@ -0,0 +1,126 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+
+#include "psmouse.h"
+#include "lifebook.h"
+
+static int max_y = 1024;
+
+
+static struct dmi_system_id lifebook_dmi_table[] = {
+   {
+   .ident = "Fujitsu Siemens Lifebook B-Sereis",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
+   },
+   },
+   { }
+};
+
+
+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	unsigned char *packet = psmouse->packet;
+	struct input_dev *dev = >dev;
+
+	if ( psmouse->pktcnt != 3 )
+		return PSMOUSE_GOOD_DATA;
+
+	input_regs(dev, regs);
+
+	/* calculate X and Y */
+	if ((packet[0] & 0x08) == 0x00) {
+		input_report_abs(dev, ABS_X,
+ (packet[1] | ((packet[0] & 0x30) << 4)));
+		input_report_abs(dev, ABS_Y,
+ max_y - (packet[2] | ((packet[0] & 0xC0) << 2)));
+	} else {
+		input_report_rel(dev, REL_X, 
+((packet[0] & 0x10) ? packet[1]-256 : packet[1]));
+		input_report_rel(dev, REL_Y, 
+(- (int)((packet[0] & 0x20) ? packet[2]-256 : packet[2])));
+	}
+
+	input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+	input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
+	input_report_key(dev, BTN_TOUCH, packet[0] & 0x04);
+
+	input_sync(dev);
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = >ps2dev;
+	unsigned char param;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+	/* 
+	   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, , PSMOUSE_CMD_SETRES);
+
+	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, unsigned int max_proto, 
+int set_properties)
+{
+if (!dmi_check_system(lifebook_dmi_table) && 
+(max_proto != PSMOUSE_LIFEBOOK) )
+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(>dev, ABS_X, 0, 1024, 0, 0);
+		input_set_abs_params(>dev, ABS_Y, 0, 1024, 0, 0);
+
+		psmouse->protocol_handler = lifebook_process_byte;
+		psmouse->disconnect = lifebook_disconnect;
+		psmouse->reconnect  = lifebook_initialize;
+		psmouse->pktsize = 3;
+	}
+
+return lifebook_initialize(psmouse);
+}
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.h linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h
--- linux-2.6.11.3/drivers/input/mouse/lifebook.h	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h	2005-03-14 10:01:57.0 +0100
@@ -0,0 +1,17 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik
+ *
+ * This program is free software; you can

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-15 Thread Kenan Esau
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?
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.c linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c
--- linux-2.6.11.3/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c	2005-03-15 10:04:34.0 +0100
@@ -0,0 +1,126 @@
+/*
+ * 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
+
+static int max_y = 1024;
+
+
+static struct dmi_system_id lifebook_dmi_table[] = {
+   {
+   .ident = Fujitsu Siemens Lifebook B-Sereis,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, LIFEBOOK B Series),
+   },
+   },
+   { }
+};
+
+
+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;
+
+	if ( psmouse-pktcnt != 3 )
+		return PSMOUSE_GOOD_DATA;
+
+	input_regs(dev, regs);
+
+	/* calculate X and Y */
+	if ((packet[0]  0x08) == 0x00) {
+		input_report_abs(dev, ABS_X,
+ (packet[1] | ((packet[0]  0x30)  4)));
+		input_report_abs(dev, ABS_Y,
+ max_y - (packet[2] | ((packet[0]  0xC0)  2)));
+	} else {
+		input_report_rel(dev, REL_X, 
+((packet[0]  0x10) ? packet[1]-256 : packet[1]));
+		input_report_rel(dev, REL_Y, 
+(- (int)((packet[0]  0x20) ? packet[2]-256 : packet[2])));
+	}
+
+	input_report_key(dev, BTN_LEFT, packet[0]  0x01);
+	input_report_key(dev, BTN_RIGHT, packet[0]  0x02);
+	input_report_key(dev, BTN_TOUCH, packet[0]  0x04);
+
+	input_sync(dev);
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = psmouse-ps2dev;
+	unsigned char param;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+	/* 
+	   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);
+
+	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, unsigned int max_proto, 
+int set_properties)
+{
+if (!dmi_check_system(lifebook_dmi_table)  
+(max_proto != PSMOUSE_LIFEBOOK) )
+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, 0, 1024, 0, 0);
+		input_set_abs_params(psmouse-dev, ABS_Y, 0, 1024, 0, 0);
+
+		psmouse-protocol_handler = lifebook_process_byte;
+		psmouse-disconnect = lifebook_disconnect;
+		psmouse-reconnect  = lifebook_initialize;
+		psmouse-pktsize = 3;
+	}
+
+return lifebook_initialize(psmouse);
+}
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.h linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h
--- linux-2.6.11.3/drivers/input/mouse/lifebook.h	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h	2005-03-14 10:01:57.0 +0100
@@ -0,0 +1,17 @@
+/*
+ * 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

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-06 Thread Kenan Esau
Sorry for the late response.

Am Dienstag, den 01.03.2005, 13:08 +0100 schrieb Vojtech Pavlik:
> On Tue, Mar 01, 2005 at 09:11:49AM +0100, Kenan Esau wrote:
>   
> > > 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.
> 
> So even 0xe8 0x03 returns error?

No -- I meant only 0xe8 0x07 and 0xe8 0x06 . For those it doesn't matter
if you repeat the parameter or send something else. The answers from the
device for those command/parameters are always the same.

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

OK -- I will send the command after 0xe8 0x07 twice.

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

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

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-06 Thread Kenan Esau
Sorry for the late response.

Am Dienstag, den 01.03.2005, 13:08 +0100 schrieb Vojtech Pavlik:
 On Tue, Mar 01, 2005 at 09:11:49AM +0100, Kenan Esau wrote:
   
   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.
 
 So even 0xe8 0x03 returns error?

No -- I meant only 0xe8 0x07 and 0xe8 0x06 . For those it doesn't matter
if you repeat the parameter or send something else. The answers from the
device for those command/parameters are always the same.

 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.

OK -- I will send the command after 0xe8 0x07 twice.

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

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.

 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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-01 Thread Kenan Esau
Am Donnerstag, den 24.02.2005, 10:03 +0100 schrieb Vojtech Pavlik: 
> On Mon, Feb 21, 2005 at 09:06:55AM +0100, Kenan Esau wrote:
> 
> > > > 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?
> > 
> > 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?

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.

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

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

I have attached the newest version of the patch.
diff -uprN -X dontdiff linux-2.6.11-rc5/drivers/input/mouse/lifebook.c linux-2.6.11-rc5-kenan/drivers/input/mouse/lifebook.c
--- linux-2.6.11-rc5/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc5-kenan/drivers/input/mouse/lifebook.c	2005-02-28 16:56:37.0 +0100
@@ -0,0 +1,109 @@
+/*
+ * 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 
+#include 
+#include 
+
+#include "psmouse.h"
+#include "lifebook.h"
+
+static int max_y = 1024;
+
+
+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	unsigned char *packet = psmouse->packet;
+	struct input_dev *dev = >dev;
+
+	if ( psmouse->pktcnt != 3 )
+		return PSMOUSE_GOOD_DATA;
+
+	input_regs(dev, regs);
+
+	/* calculate X and Y */
+	if ((packet[0] & 0x08) == 0x00) {
+		input_report_abs(dev, ABS_X,
+ (packet[1] | ((packet[0] & 0x30) << 4)));
+		input_report_abs(dev, ABS_Y,
+ max_y - (packet[2] | ((packet[0] & 0xC0) << 2)));
+	} else {
+		input_report_rel(dev, REL_X, 
+((packet[0] & 0x10) ? packet[1]-256 : packet[1]));
+		input_report_rel(dev, REL_Y, 
+(- (int)((packet[0] & 0x20) ? packet[2]-256 : packet[2])));
+	}
+
+	input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+	input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
+	input_report_key(dev, BTN_TOUCH, packet[0] & 0x04);
+
+	input_sync(dev);
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = >ps2dev;
+	unsigned char param;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+	/* 
+	   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, , PSMOUSE_CMD_SETRES);
+
+	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 (set_properties) {
+		psmouse->vendor = "Fujits

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-01 Thread Kenan Esau
Am Donnerstag, den 24.02.2005, 10:03 +0100 schrieb Vojtech Pavlik: 
 On Mon, Feb 21, 2005 at 09:06:55AM +0100, Kenan Esau wrote:
 
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?
  
  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?

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.

  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.

  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?

I have attached the newest version of the patch.
diff -uprN -X dontdiff linux-2.6.11-rc5/drivers/input/mouse/lifebook.c linux-2.6.11-rc5-kenan/drivers/input/mouse/lifebook.c
--- linux-2.6.11-rc5/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc5-kenan/drivers/input/mouse/lifebook.c	2005-02-28 16:56:37.0 +0100
@@ -0,0 +1,109 @@
+/*
+ * 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 psmouse.h
+#include lifebook.h
+
+static int max_y = 1024;
+
+
+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;
+
+	if ( psmouse-pktcnt != 3 )
+		return PSMOUSE_GOOD_DATA;
+
+	input_regs(dev, regs);
+
+	/* calculate X and Y */
+	if ((packet[0]  0x08) == 0x00) {
+		input_report_abs(dev, ABS_X,
+ (packet[1] | ((packet[0]  0x30)  4)));
+		input_report_abs(dev, ABS_Y,
+ max_y - (packet[2] | ((packet[0]  0xC0)  2)));
+	} else {
+		input_report_rel(dev, REL_X, 
+((packet[0]  0x10) ? packet[1]-256 : packet[1]));
+		input_report_rel(dev, REL_Y, 
+(- (int)((packet[0]  0x20) ? packet[2]-256 : packet[2])));
+	}
+
+	input_report_key(dev, BTN_LEFT, packet[0]  0x01);
+	input_report_key(dev, BTN_RIGHT, packet[0]  0x02);
+	input_report_key(dev, BTN_TOUCH, packet[0]  0x04);
+
+	input_sync(dev);
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = psmouse-ps2dev;
+	unsigned char param;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+	/* 
+	   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);
+
+	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 (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

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-21 Thread Kenan Esau
Am Samstag, den 19.02.2005, 14:16 +0100 schrieb Vojtech Pavlik:

[...]

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

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?

##

Without e8 07
input: LBPS/2 Fujitsu Lifebook TouchScreen on isa0060/serio1
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082637]
drivers/input/serio/i8042.c: f5 -> i8042 (parameter) [195082637]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082645]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082804]
drivers/input/serio/i8042.c: ff -> i8042 (parameter) [195082804]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082807]
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, aux, 12)[195082869]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12)[195082871]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082871]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [195082871]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082874]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082874]
drivers/input/serio/i8042.c: 64 -> i8042 (parameter) [195082874]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082878]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082879]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [195082879]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082884]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082884]
drivers/input/serio/i8042.c: 03 -> i8042 (parameter) [195082884]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082888]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082889]
drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [195082889]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082894]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195082894]
drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [195082894]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195082899]

Repeating: e8 07 e8 07
input: LBPS/2 Fujitsu Lifebook TouchScreen on isa0060/serio1
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781502]
drivers/input/serio/i8042.c: f5 -> i8042 (parameter) [195781502]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781506]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781506]
drivers/input/serio/i8042.c: ff -> i8042 (parameter) [195781506]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781511]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [195781569]
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, aux, 12)[195781575]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12)[195781577]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781595]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [195781595]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781601]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781602]
drivers/input/serio/i8042.c: 07 -> i8042 (parameter) [195781602]
drivers/input/serio/i8042.c: fe <- i8042 (interrupt, aux, 12)[195781606]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781607]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [195781607]
drivers/input/serio/i8042.c: fc <- i8042 (interrupt, aux, 12)[195781611]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781809]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [195781809]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781813]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781813]
drivers/input/serio/i8042.c: 64 -> i8042 (parameter) [195781813]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781817]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781818]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [195781818]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781822]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [195781823]
drivers/input/serio/i8042.c: 03 -> i8042 (parameter) [195781823]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12)[195781827]
drivers/input/serio/i8042.c: d4 

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-19 Thread Kenan Esau
Am Donnerstag, den 17.02.2005, 20:42 +0100 schrieb Vojtech Pavlik:
> On Thu, Feb 17, 2005 at 04:04:55PM +0100, Vojtech Pavlik wrote:
> 
> > > 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.
> > 
> > > 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.
> 
> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-19 Thread Kenan Esau
Am Donnerstag, den 17.02.2005, 20:42 +0100 schrieb Vojtech Pavlik:
 On Thu, Feb 17, 2005 at 04:04:55PM +0100, Vojtech Pavlik wrote:
 
   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.
  
   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.
 
 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.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-17 Thread Kenan Esau
Am Mittwoch, den 16.02.2005, 22:35 +0100 schrieb Vojtech Pavlik:
> On Wed, Feb 16, 2005 at 07:34:52PM +0100, Kenan Esau wrote:
> 
> > > > +
> > > > +/* 
> > > > +   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, , 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.
> > 
> > Yes the answer is 0xfe. 
> 
> 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]
drivers/input/serio/i8042.c: 20 <- i8042 (interrupt, kbd, 1) [78494505]
drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, kbd, 1) [78494603]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [78494680]
...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-17 Thread Kenan Esau
Am Mittwoch, den 16.02.2005, 22:35 +0100 schrieb Vojtech Pavlik:
 On Wed, Feb 16, 2005 at 07:34:52PM +0100, Kenan Esau wrote:
 
+
+/* 
+   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.
  
  Yes the answer is 0xfe. 
 
 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]
drivers/input/serio/i8042.c: 20 - i8042 (interrupt, kbd, 1) [78494505]
drivers/input/serio/i8042.c: a0 - i8042 (interrupt, kbd, 1) [78494603]
drivers/input/serio/i8042.c: 32 - i8042 (interrupt, kbd, 1) [78494680]
...


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-16 Thread Kenan Esau
Am Dienstag, den 15.02.2005, 14:43 +0100 schrieb Vojtech Pavlik:
> On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
> > Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

[...]

> > +
> > +/* 
> > +   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, , 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.

Yes the answer is 0xfe. 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-16 Thread Kenan Esau
Am Dienstag, den 15.02.2005, 14:43 +0100 schrieb Vojtech Pavlik:
 On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
  Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:

[...]

  +
  +/* 
  +   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.

Yes the answer is 0xfe. 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-15 Thread Kenan Esau
Am Dienstag, den 15.02.2005, 14:43 +0100 schrieb Vojtech Pavlik:
> On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
> > 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
> > --- linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.c 1970-01-01 
> > 01:00:00.0 +0100
> > +++ linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.c   2005-02-14 
> > 19:09:37.0 +0100
> > @@ -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 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "psmouse.h"
> > +#include "lifebook.h"
> > +
> > +#define LBTOUCH_TOUCHED 0x04
> > +#define LBTOUCH_X_HIGH  0x30
> > +#define LBTOUCH_Y_HIGH  0xC0
> > +#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.

Since the input_event-structure takes signed values that does not really
matter. But you are right it looks a little bit strange and I will
change it to 1024. It's 937 at the moment since this is the "ideal"
value for my touchscreen where y_max=937. ;-)

> > +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?
> 
> > +static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct 
> > pt_regs *regs)
> > +{
> > +   unsigned char *packet = psmouse->packet;
> > +   struct input_dev *dev = >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.

I put the constants there since I think it is more readable but if you
don't like them I'll throw em out.

> Also, input_regs() is missing here.
> 
> > +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 ));
> > +   } 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!

I will check this.

> 
> > +   

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-15 Thread Kenan Esau
Am Dienstag, den 15.02.2005, 09:43 -0500 schrieb Dmitry Torokhov:
> On Tue, 15 Feb 2005 14:43:08 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
> > > +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?
> > 
> 
> 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?

> > > +static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, 
> > > struct pt_regs *regs)
> > > +{
> > > + unsigned char *packet = psmouse->packet;
> > > + struct input_dev *dev = >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. 
> 
> > > +
> > > +psmouse->protocol_handler = lifebook_process_byte;
> > > +psmouse->disconnect = lifebook_disconnect;
> > > +psmouse->reconnect  = lifebook_initialize;
> > > +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.

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-15 Thread Kenan Esau
Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:
> 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.

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
--- linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.c	2005-02-14 19:09:37.0 +0100
@@ -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 
+#include 
+#include 
+#include 
+
+#include "psmouse.h"
+#include "lifebook.h"
+
+#define LBTOUCH_TOUCHED 0x04
+#define LBTOUCH_X_HIGH  0x30
+#define LBTOUCH_Y_HIGH  0xC0
+#define LBTOUCH_LB  0x01
+#define LBTOUCH_RB  0x02
+
+static int max_y = 937;
+
+static struct dmi_system_id lifebook_dmi_table[] = {
+	{
+		.ident = "Fujitsu Siemens Lifebook B-Sereis",
+		.matches = {
+			DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
+		},
+	},
+	{ }
+};
+
+
+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	unsigned char *packet = psmouse->packet;
+	struct input_dev *dev = >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;
+
+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 ));
+	} else {
+		x = ((packet[0] & 0x10) ? packet[1]-256 : packet[1]);
+		y = - ((packet[0] & 0x20) ? packet[2]-256 : packet[2]);
+	}
+
+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 */
+	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);
+}
+
+	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 = >ps2dev;
+unsigned char param;
+
+if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+/* 
+   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, , PSMOUSE_CMD_SETRES);
+
+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

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-15 Thread Kenan Esau
Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:
 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.

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
--- linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.c	2005-02-14 19:09:37.0 +0100
@@ -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
+#define LBTOUCH_LB  0x01
+#define LBTOUCH_RB  0x02
+
+static int max_y = 937;
+
+static struct dmi_system_id lifebook_dmi_table[] = {
+	{
+		.ident = Fujitsu Siemens Lifebook B-Sereis,
+		.matches = {
+			DMI_MATCH(DMI_PRODUCT_NAME, LIFEBOOK B Series),
+		},
+	},
+	{ }
+};
+
+
+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;
+
+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 ));
+	} else {
+		x = ((packet[0]  0x10) ? packet[1]-256 : packet[1]);
+		y = - ((packet[0]  0x20) ? packet[2]-256 : packet[2]);
+	}
+
+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 */
+	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);
+}
+
+	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;
+
+if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+/* 
+   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);
+
+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

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-15 Thread Kenan Esau
Am Dienstag, den 15.02.2005, 09:43 -0500 schrieb Dmitry Torokhov:
 On Tue, 15 Feb 2005 14:43:08 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
  On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
   +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?
  
 
 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?

   +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. 
 
   +
   +psmouse-protocol_handler = lifebook_process_byte;
   +psmouse-disconnect = lifebook_disconnect;
   +psmouse-reconnect  = lifebook_initialize;
   +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.

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.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-15 Thread Kenan Esau
Am Dienstag, den 15.02.2005, 14:43 +0100 schrieb Vojtech Pavlik:
 On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
  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
  --- linux-2.6.11-rc3-vanilla/drivers/input/mouse/lifebook.c 1970-01-01 
  01:00:00.0 +0100
  +++ linux-2.6.11-rc3-kenan/drivers/input/mouse/lifebook.c   2005-02-14 
  19:09:37.0 +0100
  @@ -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
  +#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.

Since the input_event-structure takes signed values that does not really
matter. But you are right it looks a little bit strange and I will
change it to 1024. It's 937 at the moment since this is the ideal
value for my touchscreen where y_max=937. ;-)

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

I put the constants there since I think it is more readable but if you
don't like them I'll throw em out.

 Also, input_regs() is missing here.
 
  +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 ));
  +   } 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!

I will check this.

 
  +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 */
  +   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

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-13 Thread Kenan Esau
Am Sonntag, den 13.02.2005, 13:01 +0100 schrieb Vojtech Pavlik: 
> On Sun, Feb 13, 2005 at 11:05:00AM +0100, Kenan Esau wrote:
>  
> > > > 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
> 
> 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... 

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

[...]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-13 Thread Kenan Esau
Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:
> On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:
> 
> > 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.
> 
> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-13 Thread Kenan Esau
Am Samstag, den 12.02.2005, 19:34 +0100 schrieb Vojtech Pavlik:
> On Sat, Feb 12, 2005 at 06:01:19PM +0100, Kenan Esau wrote:
> > Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik: 
> > > Hi!

[...]

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

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

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.

I think this was the kick in the ass I needed ;-)

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

Yeah -- OK. PS2...

[...]


Greetings 


Kenan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-13 Thread Kenan Esau
Am Samstag, den 12.02.2005, 19:34 +0100 schrieb Vojtech Pavlik:
 On Sat, Feb 12, 2005 at 06:01:19PM +0100, Kenan Esau wrote:
  Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik: 
   Hi!

[...]

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

  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.

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.

I think this was the kick in the ass I needed ;-)

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

Yeah -- OK. PS2...

[...]


Greetings 


Kenan

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-13 Thread Kenan Esau
Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:
 On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:
 
  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.
 
 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.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-13 Thread Kenan Esau
Am Sonntag, den 13.02.2005, 13:01 +0100 schrieb Vojtech Pavlik: 
 On Sun, Feb 13, 2005 at 11:05:00AM +0100, Kenan Esau wrote:
  
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
 
 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... 

 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.

[...]

  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.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-12 Thread Kenan Esau
Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik: 
> 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.

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


Greetings 


Kenan
diff -uprN -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/Kconfig linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/Kconfig
--- linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/Kconfig	2004-12-24 22:34:45.0 +0100
+++ linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/Kconfig	2005-02-12 16:52:27.0 +0100
@@ -35,3 +35,10 @@ config TOUCHSCREEN_GUNZE
 	  To compile this driver as a module, choose M here: the
 	  module will be called gunze.
 
+
+config TOUCHSCREEN_LBTOUCH
+	tristate "Lifebook touchscreen"
+	depends on INPUT && INPUT_TOUCHSCREEN && SERIO
+	help
+	  Say Y here if you have got a Fujitsu-Siemens Lifebook
+	  B-Series and want to be able to use its touchscreen.
diff -uprN -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/lbtouch.c linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/lbtouch.c
--- linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/lbtouch.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/lbtouch.c	2005-02-12 16:52:26.0 +0100
@@ -0,0 +1,603 @@
+/*
+ * $Id: lbtouch.c,v 1.3 2004/05/17 17:50:00 conan Exp $
+ *
+ *  Copyright (c) 2000-2004 Kenan Esau
+ */
+
+/*
+ * 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;

Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-12 Thread Kenan Esau
Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik: 
 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.

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


Greetings 


Kenan
diff -uprN -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/Kconfig linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/Kconfig
--- linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/Kconfig	2004-12-24 22:34:45.0 +0100
+++ linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/Kconfig	2005-02-12 16:52:27.0 +0100
@@ -35,3 +35,10 @@ config TOUCHSCREEN_GUNZE
 	  To compile this driver as a module, choose M here: the
 	  module will be called gunze.
 
+
+config TOUCHSCREEN_LBTOUCH
+	tristate Lifebook touchscreen
+	depends on INPUT  INPUT_TOUCHSCREEN  SERIO
+	help
+	  Say Y here if you have got a Fujitsu-Siemens Lifebook
+	  B-Series and want to be able to use its touchscreen.
diff -uprN -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/lbtouch.c linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/lbtouch.c
--- linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/lbtouch.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/lbtouch.c	2005-02-12 16:52:26.0 +0100
@@ -0,0 +1,603 @@
+/*
+ * $Id: lbtouch.c,v 1.3 2004/05/17 17:50:00 conan Exp $
+ *
+ *  Copyright (c) 2000-2004 Kenan Esau
+ */
+
+/*
+ * 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