Skip to contentSkip to conversation

My current patches

PATCH In review Vojtech Pavlik 8 participants 29 messages Sep 25, 2003 – Oct 5, 2003

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

Hi!

I'm sending you my current set of patches for review and testing. Please forward to whoever can test them. If no problems are found, I'll be sending them to Linus for inclusion in 2.6 tomorrow or so.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#1 lore raw

PATCH 1/8 Revert synaptics->pktcnt change.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:17:45+02:00, [email protected]
input: Revert synaptics->pktcnt change. New synaptics driver actually
uses the variable.

 psmouse-base.c |    1 -
 1 files changed, 1 deletion(-)

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

drivers/input/mouse/psmouse-base.c +0 -1
diff -Nru a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
@@ -173,7 +173,6 @@
 		 * so it needs to receive all bytes one at a time.
 		 */
 		synaptics_process_byte(psmouse, regs);
-		psmouse->pktcnt = 0;
 		goto out;
 	}
 
#2 lore raw

PATCH 2/8 Fix multibutton handling in synaptics.c.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:18:59+02:00, [email protected]
input: Fix multibutton handling in Synaptics.c (nExtBtn > 8 case)

 synaptics.c |   21 +++++++++++++++++----
 1 files changed, 17 insertions(+), 4 deletions(-)

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

drivers/input/mouse/synaptics.c +17 -4
diff -Nru a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
@@ -164,7 +164,8 @@
 
 	if (SYN_CAP_EXTENDED(priv->capabilities)) {
 		printk(KERN_INFO " Touchpad has extended capability bits\n");
-		if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap))
+		if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
+		    SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) <= 8)
 			printk(KERN_INFO " -> %d multi-buttons, i.e. besides standard buttons\n",
 			       (int)(SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap)));
 		else if (SYN_CAP_FOUR_BUTTON(priv->capabilities))
@@ -352,7 +353,11 @@
 	if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap))
 		switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
 		default:
-			printk(KERN_ERR "This touchpad reports more than 8 multi-buttons, don't know how to handle.\n");
+			/*
+			 * if nExtBtn is greater than 8 it should be considered
+			 * invalid and treated as 0
+			 */
+			break;
 		case 8:
 			set_bit(BTN_7, psmouse->dev.keybit);
 			set_bit(BTN_6, psmouse->dev.keybit);
@@ -437,7 +442,11 @@
 		    ((buf[3] & 2) ? !hw->right : hw->right)) {
 			switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
 			default:
-				; /* we did comment while initialising... */
+				/*
+				 * if nExtBtn is greater than 8 it should be
+				 * considered invalid and treated as 0
+				 */
+				break;
 			case 8:
 				hw->b7 = ((buf[5] & 0x08)) ? 1 : 0;
 				hw->b6 = ((buf[4] & 0x08)) ? 1 : 0;
@@ -516,7 +525,11 @@
 	if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap))
 		switch(SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
 		default:
-			; /* we did comment while initialising... */
+			/*
+			 * if nExtBtn is greater than 8 it should be considered
+			 * invalid and treated as 0
+			 */
+			break;
 		case 8:
 			input_report_key(dev, BTN_7,       hw.b7);
 			input_report_key(dev, BTN_6,       hw.b6);
#3 lore raw

PATCH 3/8 Synaptics code cleanups.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:19:41+02:00, [email protected]
input: Synaptics code cleanups.

 synaptics.c |  161 +++++++++++++++++++++++++++++++-----------------------------
 1 files changed, 85 insertions(+), 76 deletions(-)

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

drivers/input/mouse/synaptics.c +85 -76
diff -Nru a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
@@ -36,7 +36,7 @@
  * Use the Synaptics extended ps/2 syntax to write a special command byte.
  * special command: 0xE8 rr 0xE8 ss 0xE8 tt 0xE8 uu where (rr*64)+(ss*16)+(tt*4)+uu
  *                  is the command. A 0xF3 or 0xE9 must follow (see synaptics_send_cmd
- *                  and synaptics_set_mode)
+ *                  and synaptics_mode_cmd)
  */
 static int synaptics_special_cmd(struct psmouse *psmouse, unsigned char command)
 {
@@ -69,7 +69,7 @@
 /*
  * Set the synaptics touchpad mode byte by special commands
  */
-static int synaptics_set_mode(struct psmouse *psmouse, unsigned char mode)
+static int synaptics_mode_cmd(struct psmouse *psmouse, unsigned char mode)
 {
 	unsigned char param[1];
 
@@ -96,13 +96,14 @@
  * Read the model-id bytes from the touchpad
  * see also SYN_MODEL_* macros
  */
-static int synaptics_model_id(struct psmouse *psmouse, unsigned long int *model_id)
+static int synaptics_model_id(struct psmouse *psmouse)
 {
+	struct synaptics_data *priv = psmouse->private;
 	unsigned char mi[3];
 
 	if (synaptics_send_cmd(psmouse, SYN_QUE_MODEL, mi))
 		return -1;
-	*model_id = (mi[0]<<16) | (mi[1]<<8) | mi[2];
+	priv->model_id = (mi[0]<<16) | (mi[1]<<8) | mi[2];
 	return 0;
 }
 
@@ -110,23 +111,24 @@
  * Read the capability-bits from the touchpad
  * see also the SYN_CAP_* macros
  */
-static int synaptics_capability(struct psmouse *psmouse, unsigned long int *capability, unsigned long int *ext_cap)
+static int synaptics_capability(struct psmouse *psmouse)
 {
+	struct synaptics_data *priv = psmouse->private;
 	unsigned char cap[3];
 
 	if (synaptics_send_cmd(psmouse, SYN_QUE_CAPABILITIES, cap))
 		return -1;
-	*capability = (cap[0]<<16) | (cap[1]<<8) | cap[2];
-	*ext_cap = 0;
-	if (!SYN_CAP_VALID(*capability))
+	priv->capabilities = (cap[0]<<16) | (cap[1]<<8) | cap[2];
+	priv->ext_cap = 0;
+	if (!SYN_CAP_VALID(priv->capabilities))
 		return -1;
 
-	if (SYN_EXT_CAP_REQUESTS(*capability)) {
+	if (SYN_EXT_CAP_REQUESTS(priv->capabilities)) {
 		if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_CAPAB, cap)) {
 			printk(KERN_ERR "Synaptics claims to have extended capabilities,"
 			       " but I'm not able to read them.");
 		} else
-			*ext_cap = (cap[0]<<16) | (cap[1]<<8) | cap[2];
+			priv->ext_cap = (cap[0]<<16) | (cap[1]<<8) | cap[2];
 	}
 	return 0;
 }
@@ -135,14 +137,15 @@
  * Identify Touchpad
  * See also the SYN_ID_* macros
  */
-static int synaptics_identify(struct psmouse *psmouse, unsigned long int *ident)
+static int synaptics_identify(struct psmouse *psmouse)
 {
+	struct synaptics_data *priv = psmouse->private;
 	unsigned char id[3];
 
 	if (synaptics_send_cmd(psmouse, SYN_QUE_IDENTIFY, id))
 		return -1;
-	*ident = (id[0]<<16) | (id[1]<<8) | id[2];
-	if (SYN_ID_IS_SYNAPTICS(*ident))
+	priv->identity = (id[0]<<16) | (id[1]<<8) | id[2];
+	if (SYN_ID_IS_SYNAPTICS(priv->identity))
 		return 0;
 	return -1;
 }
@@ -179,7 +182,7 @@
 	}
 }
 
-static int query_hardware(struct psmouse *psmouse)
+static int synaptics_query_hardware(struct psmouse *psmouse)
 {
 	struct synaptics_data *priv = psmouse->private;
 	int retries = 0;
@@ -188,11 +191,11 @@
 	while ((retries++ < 3) && synaptics_reset(psmouse))
 		printk(KERN_ERR "synaptics reset failed\n");
 
-	if (synaptics_identify(psmouse, &priv->identity))
+	if (synaptics_identify(psmouse))
 		return -1;
-	if (synaptics_model_id(psmouse, &priv->model_id))
+	if (synaptics_model_id(psmouse))
 		return -1;
-	if (synaptics_capability(psmouse, &priv->capabilities, &priv->ext_cap))
+	if (synaptics_capability(psmouse))
 		return -1;
 
 	mode = SYN_BIT_ABSOLUTE_MODE | SYN_BIT_HIGH_RATE;
@@ -200,7 +203,7 @@
 		mode |= SYN_BIT_DISABLE_GESTURE;
 	if (SYN_CAP_EXTENDED(priv->capabilities))
 		mode |= SYN_BIT_W_MODE;
-	if (synaptics_set_mode(psmouse, mode))
+	if (synaptics_mode_cmd(psmouse, mode))
 		return -1;
 
 	return 0;
@@ -286,7 +289,7 @@
 	/* adjust the touchpad to child's choice of protocol */
 	child = port->private;
 	if (child && child->type >= PSMOUSE_GENPS) {
-		if (synaptics_set_mode(psmouse, (SYN_BIT_ABSOLUTE_MODE |
+		if (synaptics_mode_cmd(psmouse, (SYN_BIT_ABSOLUTE_MODE |
 					 	 SYN_BIT_HIGH_RATE |
 					 	 SYN_BIT_DISABLE_GESTURE |
 						 SYN_BIT_FOUR_BYTE_CLIENT |
@@ -311,46 +314,27 @@
 	set_bit(axis, dev->absbit);
 }
 
-int synaptics_init(struct psmouse *psmouse)
+static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
 {
-	struct synaptics_data *priv;
-
-#ifndef CONFIG_MOUSE_PS2_SYNAPTICS
-	return -1;
-#endif
-	psmouse->private = priv = kmalloc(sizeof(struct synaptics_data), GFP_KERNEL);
-	if (!priv)
-		return -1;
-	memset(priv, 0, sizeof(struct synaptics_data));
-
-	priv->out_of_sync = 0;
-
-	if (query_hardware(psmouse)) {
-		printk(KERN_ERR "Unable to query/initialize Synaptics hardware.\n");
-		goto init_fail;
-	}
-
-	print_ident(priv);
-
 	/*
 	 * The x/y limits are taken from the Synaptics TouchPad interfacing Guide,
 	 * which says that they should be valid regardless of the actual size of
 	 * the sensor.
 	 */
-	set_bit(EV_ABS, psmouse->dev.evbit);
-	set_abs_params(&psmouse->dev, ABS_X, 1472, 5472, 0, 0);
-	set_abs_params(&psmouse->dev, ABS_Y, 1408, 4448, 0, 0);
-	set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 255, 0, 0);
-
-	set_bit(EV_MSC, psmouse->dev.evbit);
-	set_bit(MSC_GESTURE, psmouse->dev.mscbit);
-
-	set_bit(EV_KEY, psmouse->dev.evbit);
-	set_bit(BTN_LEFT, psmouse->dev.keybit);
-	set_bit(BTN_RIGHT, psmouse->dev.keybit);
-	set_bit(BTN_FORWARD, psmouse->dev.keybit);
-	set_bit(BTN_BACK, psmouse->dev.keybit);
-	if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap))
+	set_bit(EV_ABS, dev->evbit);
+	set_abs_params(dev, ABS_X, 1472, 5472, 0, 0);
+	set_abs_params(dev, ABS_Y, 1408, 4448, 0, 0);
+	set_abs_params(dev, ABS_PRESSURE, 0, 255, 0, 0);
+
+	set_bit(EV_MSC, dev->evbit);
+	set_bit(MSC_GESTURE, dev->mscbit);
+
+	set_bit(EV_KEY, dev->evbit);
+	set_bit(BTN_LEFT, dev->keybit);
+	set_bit(BTN_RIGHT, dev->keybit);
+	set_bit(BTN_FORWARD, dev->keybit);
+	set_bit(BTN_BACK, dev->keybit);
+	if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap)) {
 		switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
 		default:
 			/*
@@ -359,22 +343,46 @@
 			 */
 			break;
 		case 8:
-			set_bit(BTN_7, psmouse->dev.keybit);
-			set_bit(BTN_6, psmouse->dev.keybit);
+			set_bit(BTN_7, dev->keybit);
+			set_bit(BTN_6, dev->keybit);
 		case 6:
-			set_bit(BTN_5, psmouse->dev.keybit);
-			set_bit(BTN_4, psmouse->dev.keybit);
+			set_bit(BTN_5, dev->keybit);
+			set_bit(BTN_4, dev->keybit);
 		case 4:
-			set_bit(BTN_3, psmouse->dev.keybit);
-			set_bit(BTN_2, psmouse->dev.keybit);
+			set_bit(BTN_3, dev->keybit);
+			set_bit(BTN_2, dev->keybit);
 		case 2:
-			set_bit(BTN_1, psmouse->dev.keybit);
-			set_bit(BTN_0, psmouse->dev.keybit);
+			set_bit(BTN_1, dev->keybit);
+			set_bit(BTN_0, dev->keybit);
 			break;
 		}
-	clear_bit(EV_REL, psmouse->dev.evbit);
-	clear_bit(REL_X, psmouse->dev.relbit);
-	clear_bit(REL_Y, psmouse->dev.relbit);
+	}
+
+	clear_bit(EV_REL, dev->evbit);
+	clear_bit(REL_X, dev->relbit);
+	clear_bit(REL_Y, dev->relbit);
+}
+
+int synaptics_init(struct psmouse *psmouse)
+{
+	struct synaptics_data *priv;
+
+#ifndef CONFIG_MOUSE_PS2_SYNAPTICS
+	return -1;
+#endif
+
+	psmouse->private = priv = kmalloc(sizeof(struct synaptics_data), GFP_KERNEL);
+	if (!priv)
+		return -1;
+	memset(priv, 0, sizeof(struct synaptics_data));
+
+	if (synaptics_query_hardware(psmouse)) {
+		printk(KERN_ERR "Unable to query/initialize Synaptics hardware.\n");
+		goto init_fail;
+	}
+
+	print_ident(priv);
+	set_input_params(&psmouse->dev, priv);
 
 	return 0;
 
@@ -388,7 +396,7 @@
 	struct synaptics_data *priv = psmouse->private;
 
 	if (psmouse->type == PSMOUSE_SYNAPTICS && priv) {
-		synaptics_set_mode(psmouse, 0);
+		synaptics_mode_cmd(psmouse, 0);
 		if (priv->ptport) {
 			serio_unregister_slave_port(priv->ptport);
 			kfree(priv->ptport);
@@ -582,19 +590,20 @@
 		}
 		break;
 	default:
-		if (psmouse->pktcnt >= 6) { /* Full packet received */
-			if (priv->out_of_sync) {
-				priv->out_of_sync = 0;
-				printk(KERN_NOTICE "Synaptics driver resynced.\n");
-			}
+		if (psmouse->pktcnt < 6)
+			break;		    /* Wait for full packet */
 
-			if (priv->ptport && synaptics_is_pt_packet(psmouse->packet))
-				synaptics_pass_pt_packet(priv->ptport, psmouse->packet);
-			else
-				synaptics_process_packet(psmouse);
-
-			psmouse->pktcnt = 0;
+		if (priv->out_of_sync) {
+			priv->out_of_sync = 0;
+			printk(KERN_NOTICE "Synaptics driver resynced.\n");
 		}
+
+		if (priv->ptport && synaptics_is_pt_packet(psmouse->packet))
+			synaptics_pass_pt_packet(priv->ptport, psmouse->packet);
+		else
+			synaptics_process_packet(psmouse);
+
+		psmouse->pktcnt = 0;
 		break;
 	}
 	return;
#4 lore raw

PATCH 4/8 Add touchpad support to mousedev.c.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:22:01+02:00, [email protected]
input: Tidy up events reported by a Synaptics pad, add touchpad
support to mousedev.

 drivers/input/mouse/synaptics.c |   68 ++++++++++++++++-----------
 drivers/input/mousedev.c        |  100 +++++++++++++++++++++++++++++-----------
 include/linux/input.h           |    3 +
 3 files changed, 118 insertions(+), 53 deletions(-)

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

drivers/input/mouse/synaptics.c +41 -27
diff -Nru a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
@@ -28,6 +28,16 @@
 #include "psmouse.h"
 #include "synaptics.h"
 
+/*
+ * The x/y limits are taken from the Synaptics TouchPad interfacing Guide,
+ * section 2.3.2, which says that they should be valid regardless of the
+ * actual size of the sensor.
+ */
+#define XMIN_NOMINAL 1472
+#define XMAX_NOMINAL 5472
+#define YMIN_NOMINAL 1408
+#define YMAX_NOMINAL 4448
+
 /*****************************************************************************
  *	Synaptics communications functions
  ****************************************************************************/
@@ -316,20 +326,17 @@
 
 static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
 {
-	/*
-	 * The x/y limits are taken from the Synaptics TouchPad interfacing Guide,
-	 * which says that they should be valid regardless of the actual size of
-	 * the sensor.
-	 */
 	set_bit(EV_ABS, dev->evbit);
-	set_abs_params(dev, ABS_X, 1472, 5472, 0, 0);
-	set_abs_params(dev, ABS_Y, 1408, 4448, 0, 0);
+	set_abs_params(dev, ABS_X, XMIN_NOMINAL, XMAX_NOMINAL, 0, 0);
+	set_abs_params(dev, ABS_Y, YMIN_NOMINAL, YMAX_NOMINAL, 0, 0);
 	set_abs_params(dev, ABS_PRESSURE, 0, 255, 0, 0);
-
-	set_bit(EV_MSC, dev->evbit);
-	set_bit(MSC_GESTURE, dev->mscbit);
+	set_bit(ABS_TOOL_WIDTH, dev->absbit);
 
 	set_bit(EV_KEY, dev->evbit);
+	set_bit(BTN_TOOL_FINGER, dev->keybit);
+	set_bit(BTN_TOOL_DOUBLETAP, dev->keybit);
+	set_bit(BTN_TOOL_TRIPLETAP, dev->keybit);
+
 	set_bit(BTN_LEFT, dev->keybit);
 	set_bit(BTN_RIGHT, dev->keybit);
 	set_bit(BTN_FORWARD, dev->keybit);
@@ -489,42 +496,49 @@
 	struct input_dev *dev = &psmouse->dev;
 	struct synaptics_data *priv = psmouse->private;
 	struct synaptics_hw_state hw;
+	int num_fingers;
+	int finger_width;
 
 	synaptics_parse_hw_state(psmouse->packet, priv, &hw);
 
 	if (hw.z > 0) {
-		int w_ok = 0;
-		/*
-		 * Use capability bits to decide if the w value is valid.
-		 * If not, set it to 5, which corresponds to a finger of
-		 * normal width.
-		 */
+		num_fingers = 1;
+		finger_width = 5;
 		if (SYN_CAP_EXTENDED(priv->capabilities)) {
 			switch (hw.w) {
 			case 0 ... 1:
-				w_ok = SYN_CAP_MULTIFINGER(priv->capabilities);
+				if (SYN_CAP_MULTIFINGER(priv->capabilities))
+					num_fingers = hw.w + 2;
 				break;
 			case 2:
-				w_ok = SYN_MODEL_PEN(priv->model_id);
+				if (SYN_MODEL_PEN(priv->model_id))
+					;   /* Nothing, treat a pen as a single finger */
 				break;
 			case 4 ... 15:
-				w_ok = SYN_CAP_PALMDETECT(priv->capabilities);
+				if (SYN_CAP_PALMDETECT(priv->capabilities))
+					finger_width = hw.w;
 				break;
 			}
 		}
-		if (!w_ok)
-			hw.w = 5;
+	} else {
+		num_fingers = 0;
+		finger_width = 0;
 	}
 
 	/* Post events */
-	input_report_abs(dev, ABS_X,        hw.x);
-	input_report_abs(dev, ABS_Y,        hw.y);
+	if (hw.z > 0) {
+		input_report_abs(dev, ABS_X, hw.x);
+		if (SYN_MODEL_ROT180(priv->model_id))
+			input_report_abs(dev, ABS_Y, YMAX_NOMINAL + YMIN_NOMINAL - hw.y);
+		else
+			input_report_abs(dev, ABS_Y, hw.y);
+	}
 	input_report_abs(dev, ABS_PRESSURE, hw.z);
 
-	if (hw.w != priv->old_w) {
-		input_event(dev, EV_MSC, MSC_GESTURE, hw.w);
-		priv->old_w = hw.w;
-	}
+	input_report_abs(dev, ABS_TOOL_WIDTH, finger_width);
+	input_report_key(dev, BTN_TOOL_FINGER, num_fingers == 1);
+	input_report_key(dev, BTN_TOOL_DOUBLETAP, num_fingers == 2);
+	input_report_key(dev, BTN_TOOL_TRIPLETAP, num_fingers == 3);
 
 	input_report_key(dev, BTN_LEFT,    hw.left);
 	input_report_key(dev, BTN_RIGHT,   hw.right);
drivers/input/mousedev.c +74 -26

129 lines not on this page · raw message

include/linux/input.h +3 -0
diff -Nru a/include/linux/input.h b/include/linux/input.h
@@ -404,6 +404,8 @@
 #define BTN_TOUCH		0x14a
 #define BTN_STYLUS		0x14b
 #define BTN_STYLUS2		0x14c
+#define BTN_TOOL_DOUBLETAP	0x14d
+#define BTN_TOOL_TRIPLETAP	0x14e
 
 #define BTN_WHEEL		0x150
 #define BTN_GEAR_DOWN		0x150
@@ -521,6 +523,7 @@
 #define ABS_DISTANCE		0x19
 #define ABS_TILT_X		0x1a
 #define ABS_TILT_Y		0x1b
+#define ABS_TOOL_WIDTH		0x1c
 #define ABS_VOLUME		0x20
 #define ABS_MISC		0x28
 #define ABS_MAX			0x3f
#5 lore raw

PATCH 5/8 Rely less on sanity of AT keyboards.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:26:39+02:00, [email protected]
input: Change AT keyboard to use hardware autorepeat and move
untranslating to the AT keyboard driver as well. Lower PS/2 mouse default report rate. Fix repeat rate adjustment ioctls accordingly, and update other files to reflect the changes. This should fix most known keyboard problems in 2.6.

 drivers/char/keyboard.c            |   14 --
 drivers/input/evdev.c              |   10 -
 drivers/input/input.c              |   32 ++++--
 drivers/input/keyboard/atkbd.c     |  194 +++++++++++++++++++++++++++----------
 drivers/input/mouse/psmouse-base.c |   25 +++-
 drivers/input/serio/i8042.c        |   51 ---------
 include/linux/input.h              |    2 
 include/linux/serio.h              |    1 
 8 files changed, 193 insertions(+), 136 deletions(-)

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

drivers/char/keyboard.c +4 -10
diff -Nru a/drivers/char/keyboard.c b/drivers/char/keyboard.c
@@ -264,12 +264,6 @@
 /*
  * Setting the keyboard rate.
  */
-static inline unsigned int ms_to_jiffies(unsigned int ms) {
-	unsigned int j;
-
-	j = (ms * HZ + 500) / 1000;
-	return (j > 0) ? j : 1;
-}
 
 int kbd_rate(struct kbd_repeat *rep)
 {
@@ -283,11 +277,11 @@
 
 		if (test_bit(EV_REP, dev->evbit)) {
 			if (rep->delay > 0)
-				dev->rep[REP_DELAY] = ms_to_jiffies(rep->delay);
+				input_event(dev, EV_REP, REP_DELAY, rep->delay);
 			if (rep->period > 0)
-				dev->rep[REP_PERIOD] = ms_to_jiffies(rep->period);
-			d = dev->rep[REP_DELAY]  * 1000 / HZ;
-			p = dev->rep[REP_PERIOD] * 1000 / HZ;
+				input_event(dev, EV_REP, REP_PERIOD, rep->period);
+			d = dev->rep[REP_DELAY];
+			p = dev->rep[REP_PERIOD];
 		}
 	}
 	rep->delay  = d;
drivers/input/evdev.c +0 -10
diff -Nru a/drivers/input/evdev.c b/drivers/input/evdev.c
@@ -220,16 +220,6 @@
 		case EVIOCGID:
 			return copy_to_user((void *) arg, &dev->id, sizeof(struct input_id)) ? -EFAULT : 0;
 		
-		case EVIOCGREP:
-			if (put_user(dev->rep[0], ((int *) arg) + 0)) return -EFAULT;
-			if (put_user(dev->rep[1], ((int *) arg) + 1)) return -EFAULT;
-			return 0;
-
-		case EVIOCSREP:
-			if (get_user(dev->rep[0], ((int *) arg) + 0)) return -EFAULT;
-			if (get_user(dev->rep[1], ((int *) arg) + 1)) return -EFAULT;
-			return 0;
-
 		case EVIOCGKEYCODE:
 			if (get_user(t, ((int *) arg) + 0)) return -EFAULT;
 			if (t < 0 || t > dev->keycodemax || !dev->keycodesize) return -EINVAL;
drivers/input/input.c +22 -10
diff -Nru a/drivers/input/input.c b/drivers/input/input.c
@@ -55,6 +55,13 @@
 static int input_devices_state;
 #endif
 
+static inline unsigned int ms_to_jiffies(unsigned int ms)
+{
+        unsigned int j;
+        j = (ms * HZ + 500) / 1000;
+        return (j > 0) ? j : 1;
+}
+
 
 void input_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
 {
@@ -93,9 +100,9 @@
 
 			change_bit(code, dev->key);
 
-			if (test_bit(EV_REP, dev->evbit) && dev->rep[REP_PERIOD] && value) {
+			if (test_bit(EV_REP, dev->evbit) && dev->rep[REP_PERIOD] && dev->timer.data && value) {
 				dev->repeat_key = code;
-				mod_timer(&dev->timer, jiffies + dev->rep[REP_DELAY]);
+				mod_timer(&dev->timer, jiffies + ms_to_jiffies(dev->rep[REP_DELAY]));
 			}
 
 			break;
@@ -162,7 +169,7 @@
 
 		case EV_REP:
 
-			if (code > REP_MAX || dev->rep[code] == value) return;
+			if (code > REP_MAX || value < 0 || dev->rep[code] == value) return;
 
 			dev->rep[code] = value;
 			if (dev->event) dev->event(dev, type, code, value);
@@ -195,7 +202,7 @@
 	input_event(dev, EV_KEY, dev->repeat_key, 2);
 	input_sync(dev);
 
-	mod_timer(&dev->timer, jiffies + dev->rep[REP_PERIOD]);
+	mod_timer(&dev->timer, jiffies + ms_to_jiffies(dev->rep[REP_PERIOD]));
 }
 
 int input_accept_process(struct input_handle *handle, struct file *file)
@@ -423,13 +430,18 @@
 
 	set_bit(EV_SYN, dev->evbit);
 
+	/*
+	 * If delay and period are pre-set by the driver, then autorepeating
+	 * is handled by the driver itself and we don't do it in input.c.
+	 */
+
 	init_timer(&dev->timer);
-	dev->timer.data = (long) dev;
-	dev->timer.function = input_repeat_key;
-	if (!dev->rep[REP_DELAY])
-		dev->rep[REP_DELAY] = HZ/4;
-	if (!dev->rep[REP_PERIOD])
-		dev->rep[REP_PERIOD] = HZ/33;
+	if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
+		dev->timer.data = (long) dev;
+		dev->timer.function = input_repeat_key;
+		dev->rep[REP_DELAY] = 250;
+		dev->rep[REP_PERIOD] = 33;
+	}
 
 	INIT_LIST_HEAD(&dev->h_list);
 	list_add_tail(&dev->node, &input_dev_list);
drivers/input/keyboard/atkbd.c +142 -52

354 lines not on this page · raw message

drivers/input/mouse/psmouse-base.c +19 -6
diff -Nru a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
@@ -28,6 +28,8 @@
 MODULE_PARM_DESC(psmouse_noext, "Disable any protocol extensions. Useful for KVM switches.");
 MODULE_PARM(psmouse_resolution, "i");
 MODULE_PARM_DESC(psmouse_resolution, "Resolution, in dpi.");
+MODULE_PARM(psmouse_rate, "i");
+MODULE_PARM_DESC(psmouse_rate, "Report rate, in reports per second.");
 MODULE_PARM(psmouse_smartscroll, "i");
 MODULE_PARM_DESC(psmouse_smartscroll, "Logitech Smartscroll autorepeat, 1 = enabled (default), 0 = disabled.");
 MODULE_PARM(psmouse_resetafter, "i");
@@ -38,6 +40,7 @@
 
 static int psmouse_noext;
 int psmouse_resolution;
+unsigned int psmouse_rate = 60;
 int psmouse_smartscroll = PSMOUSE_LOGITECH_SMARTSCROLL;
 unsigned int psmouse_resetafter;
 
@@ -443,22 +446,32 @@
 }
 
 /*
+ * Here we set the mouse report rate.
+ */
+
+static void psmouse_set_rate(struct psmouse *psmouse)
+{
+	unsigned char rates[] = { 200, 100, 80, 60, 40, 20, 10, 0 };
+	int i = 0;
+
+	while (rates[i] > psmouse_rate) i++;
+	psmouse_command(psmouse, rates + i, PSMOUSE_CMD_SETRATE);
+}
+
+/*
  * psmouse_initialize() initializes the mouse to a sane state.
  */
 
 static void psmouse_initialize(struct psmouse *psmouse)
 {
 	unsigned char param[2];
+	
 
 /*
- * We set the mouse report rate to a highest possible value.
- * We try 100 first in case mouse fails to set 200.
+ * We set the mouse report rate.
  */
-	param[0] = 100;
-	psmouse_command(psmouse, param, PSMOUSE_CMD_SETRATE);
 
-	param[0] = 200;
-	psmouse_command(psmouse, param, PSMOUSE_CMD_SETRATE);
+	psmouse_set_rate(psmouse);
 
 /*
  * We also set the resolution and scaling.
drivers/input/serio/i8042.c +5 -46

85 lines not on this page · raw message

include/linux/input.h +0 -2
diff -Nru a/include/linux/input.h b/include/linux/input.h
@@ -56,8 +56,6 @@
 
 #define EVIOCGVERSION		_IOR('E', 0x01, int)			/* get driver version */
 #define EVIOCGID		_IOR('E', 0x02, struct input_id)	/* get device ID */
-#define EVIOCGREP		_IOR('E', 0x03, int[2])			/* get repeat settings */
-#define EVIOCSREP		_IOW('E', 0x03, int[2])			/* get repeat settings */
 #define EVIOCGKEYCODE		_IOR('E', 0x04, int[2])			/* get keycode */
 #define EVIOCSKEYCODE		_IOW('E', 0x04, int[2])			/* set keycode */
 
include/linux/serio.h +1 -0
diff -Nru a/include/linux/serio.h b/include/linux/serio.h
@@ -107,6 +107,7 @@
 #define SERIO_HIL_MLC	0x03000000UL
 #define SERIO_PC9800	0x04000000UL
 #define SERIO_PS_PSTHRU	0x05000000UL
+#define SERIO_8042_XL	0x06000000UL
 
 #define SERIO_PROTO	0xFFUL
 #define SERIO_MSC	0x01
#6 lore raw

PATCH 6/8 Extend KD?BENT to handle > 256 keycodes.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:28:12+02:00, [email protected]
input: Create new KD?BENT ioctls with a bigger key range (int), so that
it's posible to recompile kbdutils on 2.6 and load keymaps for keys beyond 128. kbdutils compiled on 2.4 will keep working on 2.6, unfortunately not vice versa, without changing kbdutils.

 arch/mips/kernel/ioctl32.c   |    2 +
 drivers/char/vt_ioctl.c      |   51 +++++++++++++++++++++++++++++--------------
 include/linux/compat_ioctl.h |    2 +
 include/linux/kd.h           |   14 +++++++++--
 4 files changed, 50 insertions(+), 19 deletions(-)

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

arch/mips/kernel/ioctl32.c +2 -0
diff -Nru a/arch/mips/kernel/ioctl32.c b/arch/mips/kernel/ioctl32.c
@@ -884,6 +884,8 @@
 COMPATIBLE_IOCTL(KDGKBMODE)
 COMPATIBLE_IOCTL(KDSKBMETA)
 COMPATIBLE_IOCTL(KDGKBMETA)
+COMPATIBLE_IOCTL(KDGKBENT_OLD)
+COMPATIBLE_IOCTL(KDSKBENT_OLD)
 COMPATIBLE_IOCTL(KDGKBENT)
 COMPATIBLE_IOCTL(KDSKBENT)
 COMPATIBLE_IOCTL(KDGKBSENT)
drivers/char/vt_ioctl.c +35 -16

88 lines not on this page · raw message

include/linux/compat_ioctl.h +2 -0
diff -Nru a/include/linux/compat_ioctl.h b/include/linux/compat_ioctl.h
@@ -161,6 +161,8 @@
 COMPATIBLE_IOCTL(KDGKBMODE)
 COMPATIBLE_IOCTL(KDSKBMETA)
 COMPATIBLE_IOCTL(KDGKBMETA)
+COMPATIBLE_IOCTL(KDGKBENT_OLD)
+COMPATIBLE_IOCTL(KDSKBENT_OLD)
 COMPATIBLE_IOCTL(KDGKBENT)
 COMPATIBLE_IOCTL(KDSKBENT)
 COMPATIBLE_IOCTL(KDGKBSENT)
include/linux/kd.h +11 -3
diff -Nru a/include/linux/kd.h b/include/linux/kd.h
@@ -94,18 +94,26 @@
 #define	KDGKBLED	0x4B64	/* get led flags (not lights) */
 #define	KDSKBLED	0x4B65	/* set led flags (not lights) */
 
-struct kbentry {
+struct kbentry_old {
 	unsigned char kb_table;
 	unsigned char kb_index;
 	unsigned short kb_value;
 };
+#define KDGKBENT_OLD	0x4B46	/* gets one entry in translation table (old) */
+#define KDSKBENT_OLD	0x4B47	/* sets one entry in translation table (old) */
+
+struct kbentry {
+	unsigned int kb_table;
+	unsigned int kb_index;
+	unsigned short kb_value;
+};
 #define		K_NORMTAB	0x00
 #define		K_SHIFTTAB	0x01
 #define		K_ALTTAB	0x02
 #define		K_ALTSHIFTTAB	0x03
 
-#define KDGKBENT	0x4B46	/* gets one entry in translation table */
-#define KDSKBENT	0x4B47	/* sets one entry in translation table */
+#define KDGKBENT	0x4B73	/* gets one entry in translation table */
+#define KDSKBENT	0x4B74	/* sets one entry in translation table */
 
 struct kbsentry {
 	unsigned char kb_func;
#7 lore raw

PATCH 7/8 Fix handling of rotated Synaptics touchpads.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:29:15+02:00, [email protected]
input: Fix broken handling of rotated Synaptics touchpads.
The infoRot180 and infoPortrait bits are for information only. The touchpad uses the same X/Y coordinate system regardless of the orientation, so the software shouldn't care about these bits.

 synaptics.c |    5 +----
 1 files changed, 1 insertion(+), 4 deletions(-)

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

drivers/input/mouse/synaptics.c +1 -4
diff -Nru a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
@@ -528,10 +528,7 @@
 	/* Post events */
 	if (hw.z > 0) {
 		input_report_abs(dev, ABS_X, hw.x);
-		if (SYN_MODEL_ROT180(priv->model_id))
-			input_report_abs(dev, ABS_Y, YMAX_NOMINAL + YMIN_NOMINAL - hw.y);
-		else
-			input_report_abs(dev, ABS_Y, hw.y);
+		input_report_abs(dev, ABS_Y, YMAX_NOMINAL + YMIN_NOMINAL - hw.y);
 	}
 	input_report_abs(dev, ABS_PRESSURE, hw.z);
 
#8 lore raw

PATCH 8/8 Add BTN_TOUCH to Synaptics driver. Update mousedev.

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/input

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

[email protected], 2003-09-25 18:32:35+02:00, [email protected]
input: Add BTN_TOUCH to Synaptics pad driver. This fixes the joydev
grabbing of the pads, as well as simplifies the mousedev driver.

 mouse/synaptics.c |    4 ++
 mousedev.c        |   77 ++++++++++++++++++++++--------------------------------
 2 files changed, 36 insertions(+), 45 deletions(-)

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

drivers/input/mouse/synaptics.c +4 -0
diff -Nru a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
@@ -333,6 +333,7 @@
 	set_bit(ABS_TOOL_WIDTH, dev->absbit);
 
 	set_bit(EV_KEY, dev->evbit);
+	set_bit(BTN_TOUCH, dev->keybit);
 	set_bit(BTN_TOOL_FINGER, dev->keybit);
 	set_bit(BTN_TOOL_DOUBLETAP, dev->keybit);
 	set_bit(BTN_TOOL_TRIPLETAP, dev->keybit);
@@ -531,6 +532,9 @@
 		input_report_abs(dev, ABS_Y, YMAX_NOMINAL + YMIN_NOMINAL - hw.y);
 	}
 	input_report_abs(dev, ABS_PRESSURE, hw.z);
+
+	if (hw.z > 30) input_report_key(dev, BTN_TOUCH, 1);
+	if (hw.z < 25) input_report_key(dev, BTN_TOUCH, 0);
 
 	input_report_abs(dev, ABS_TOOL_WIDTH, finger_width);
 	input_report_key(dev, BTN_TOOL_FINGER, num_fingers == 1);
drivers/input/mousedev.c +32 -45

112 lines not on this page · raw message

#9 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

drivers/input/mouse/synaptics.c line 537

Quoted 4 lines · Vojtech Pavlik
drivers/input/mouse/synaptics.c +3 -0
+
+	if (hw.z > 30) input_report_key(dev, BTN_TOUCH, 1);
+	if (hw.z < 25) input_report_key(dev, BTN_TOUCH, 0);

Couple of questions:

- Why does it use hard-coded values? Different people prefer different settings.

- Are userspace drivers supposed to use BTN_TOUCH event to detect whether the pad is touched or ABS_PRESSURE? If ABS_PRESSURE then BTN_TOUCH is unneeded; otherwise it's not configurable.

- Introducing BTN_TOUCH as far as I can seen does nothing to prevent joydev grabbing either Synaptics or touchscreens... Is there a patch missing? Anyway, I still thing that joydev claims are too broad. Next time you add a non-joystick device you will need to re-examine joydev and it should be other way around - if you add a joystick you need to make sure that joydev grabs it. This way you will catch most problems right away.

BTW, any chance on including pass-through patches? Do you want me to re-diff them?

Dmitry

#10 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 10 lines · Dmitry Torokhov

drivers/input/mouse/synaptics.c line 537

Quoted 4 lines · Vojtech Pavlik
drivers/input/mouse/synaptics.c +3 -0
+
+	if (hw.z > 30) input_report_key(dev, BTN_TOUCH, 1);
+	if (hw.z < 25) input_report_key(dev, BTN_TOUCH, 0);

Couple of questions:

- Why does it use hard-coded values? Different people prefer different settings.

I just moved them from mousedev.c.

Quoted 3 lines

- Are userspace drivers supposed to use BTN_TOUCH event to detect whether the pad is touched or ABS_PRESSURE? If ABS_PRESSURE then BTN_TOUCH is unneeded; otherwise it's not configurable.

A simple userspace program or kernel handler can use BTN_TOUCH, and it'll trade off configurability for simplicity. BTN_TOUCH will most likely be present on all touchpads, touchscreens and tablets, too, so it can be relied on as a generic feature. An advanced one can be configurable to use ABS_PRESSURE with user defined thresholds.

Another of the reasons is that ABS_PRESSURE is hardware-dependent. Different device types will need very different thresholds. With the driver providing the thresholded value, a generic handler (like mousedev) can work without external configuration.

Quoted 2 lines

- Introducing BTN_TOUCH as far as I can seen does nothing to prevent joydev grabbing either Synaptics or touchscreens... Is there a patch missing?

No. It's a statement you're missing near the beginning of joydev_connect().

Quoted 4 lines

Anyway, I still thing that joydev claims are too broad. Next time you add a non-joystick device you will need to re-examine joydev and it should be other way around - if you add a joystick you need to make sure that joydev grabs it. This way you will catch most problems right away.

It is possible. Maybe it's time now to define what event types each type of device is supposed to have so that problems like this don't appear.

Quoted 2 lines

BTW, any chance on including pass-through patches? Do you want me to re-diff them?

Hmm, I thought I've merged them in already, but obviously I did not. Please resend them (rediffed if possible). Thanks.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#11 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 7 lines · Vojtech Pavlik
Quoted 2 lines · Dmitry Torokhov

BTW, any chance on including pass-through patches? Do you want me to re-diff them?

Hmm, I thought I've merged them in already, but obviously I did not. Please resend them (rediffed if possible). Thanks.

If these patches are the same as the "reconnect" patches I have in my tree, I already have them rediffed (attached).

Signature · 2 lines
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340

The patch below introduces a new serio_dev method "reconnect". It's purpose is to re-initialize attached hardware while keeping the same input device.

Reconnect can be used for example during resume or with somewhat broken hardware like my laptop/docking station which resets the touchpad back in relative mode without telling anyone whenever I dock or un-dock. The regular disconnect/connect solution is not working because clients (like XFree) like to keep the original input device open so after connecting the touchpad it will create a brand new input device. With reconnect the driver has an option to re-initialize hardware but keep the same input device (given that hardware didn't change).

If reconnect fails serio automatically fall back to disconnect/reconnect scheme.

What you think?

Dmitry

P.S. I have a new patch for Synaptics touchpad that makes use of this new functionality that I will sent to the LKML shortly

 linux-petero/drivers/input/serio/serio.c |   31 ++++++++++++++++++++++++-------
 linux-petero/include/linux/serio.h       |    2 ++
 2 files changed, 26 insertions(+), 7 deletions(-)
drivers/input/serio/serio.c renamed from drivers/input/serio/serio.c~serio-reconnect +24 -7
diff -puN drivers/input/serio/serio.c~serio-reconnect drivers/input/serio/serio.c
@@ -57,6 +57,7 @@ EXPORT_SYMBOL(serio_unregister_device);
 EXPORT_SYMBOL(serio_open);
 EXPORT_SYMBOL(serio_close);
 EXPORT_SYMBOL(serio_rescan);
+EXPORT_SYMBOL(serio_reconnect);
 
 struct serio_event {
 	int type;
@@ -83,6 +84,7 @@ static void serio_find_dev(struct serio 
 }
 
 #define SERIO_RESCAN	1
+#define SERIO_RECONNECT	2
 
 static DECLARE_WAIT_QUEUE_HEAD(serio_wait);
 static DECLARE_COMPLETION(serio_exited);
@@ -96,6 +98,12 @@ void serio_handle_events(void)
 		event = container_of(node, struct serio_event, node);	
 
 		switch (event->type) {
+			case SERIO_RECONNECT :
+				if (event->serio->dev && event->serio->dev->reconnect)
+					if (event->serio->dev->reconnect(event->serio) == 0)
+						break;
+				/* reconnect failed - fall through to rescan */
+
 			case SERIO_RESCAN :
 				down(&serio_sem);
 				if (event->serio->dev && event->serio->dev->disconnect)
@@ -130,18 +138,27 @@ static int serio_thread(void *nothing)
 	complete_and_exit(&serio_exited, 0);
 }
 
-void serio_rescan(struct serio *serio)
+static void serio_queue_event(struct serio *serio, int event_type)
 {
 	struct serio_event *event;
 
-	if (!(event = kmalloc(sizeof(struct serio_event), GFP_ATOMIC)))
-		return;
+	if ((event = kmalloc(sizeof(struct serio_event), GFP_ATOMIC))) {
+		event->type = event_type;
+		event->serio = serio;
 
-	event->type = SERIO_RESCAN;
-	event->serio = serio;
+		list_add_tail(&event->node, &serio_event_list);
+		wake_up(&serio_wait);
+	}
+}
 
-	list_add_tail(&event->node, &serio_event_list);
-	wake_up(&serio_wait);
+void serio_rescan(struct serio *serio)
+{
+	serio_queue_event(serio, SERIO_RESCAN);
+}
+
+void serio_reconnect(struct serio *serio)
+{
+	serio_queue_event(serio, SERIO_RECONNECT);
 }
 
 irqreturn_t serio_interrupt(struct serio *serio,
include/linux/serio.h renamed from include/linux/serio.h~serio-reconnect +2 -0
diff -puN include/linux/serio.h~serio-reconnect include/linux/serio.h
@@ -53,6 +53,7 @@ struct serio_dev {
 	irqreturn_t (*interrupt)(struct serio *, unsigned char,
 			unsigned int, struct pt_regs *);
 	void (*connect)(struct serio *, struct serio_dev *dev);
+	int  (*reconnect)(struct serio *);
 	void (*disconnect)(struct serio *);
 	void (*cleanup)(struct serio *);
 
@@ -62,6 +63,7 @@ struct serio_dev {
 int serio_open(struct serio *serio, struct serio_dev *dev);
 void serio_close(struct serio *serio);
 void serio_rescan(struct serio *serio);
+void serio_reconnect(struct serio *serio);
 irqreturn_t serio_interrupt(struct serio *serio, unsigned char data, unsigned int flags, struct pt_regs *regs);
 
 void serio_register_port(struct serio *serio);

_

Here is the update to the Synaptics touchpad driver.

The changes are:
1. Support for pass-through port moved from Synaptics driver to psmouse itself, it is cleaner and should allow using it in other drivers if needed.
2. The driver makes use of new reconnect functionality in serio. It will try to keep the same input device after resume or when it resets itself.
3. If mouse is disconnected or other mouse plugged in while sleeping the driver should correctly recognize that and create a new serio/input device.

Dmitry

 linux-petero/drivers/input/mouse/logips2pp.c    |    1 
 linux-petero/drivers/input/mouse/psmouse-base.c |   94 +++++++++++---
 linux-petero/drivers/input/mouse/psmouse.h      |   13 ++
 linux-petero/drivers/input/mouse/synaptics.c    |  153 +++++++++++++++---------
 linux-petero/drivers/input/mouse/synaptics.h    |    4 
 5 files changed, 186 insertions(+), 79 deletions(-)
drivers/input/mouse/logips2pp.c renamed from drivers/input/mouse/logips2pp.c~synaptics-reconnect +1 -0
diff -puN drivers/input/mouse/logips2pp.c~synaptics-reconnect drivers/input/mouse/logips2pp.c
@@ -10,6 +10,7 @@
  */
 
 #include <linux/input.h>
+#include <linux/serio.h>
 #include "psmouse.h"
 #include "logips2pp.h"
 
drivers/input/mouse/psmouse-base.c renamed from drivers/input/mouse/psmouse-base.c~synaptics-reconnect +75 -19

132 lines not on this page · raw message

drivers/input/mouse/psmouse.h renamed from drivers/input/mouse/psmouse.h~synaptics-reconnect +13 -0
diff -puN drivers/input/mouse/psmouse.h~synaptics-reconnect drivers/input/mouse/psmouse.h
@@ -22,10 +22,20 @@
 #define PSMOUSE_ACTIVATED	1
 #define PSMOUSE_IGNORE		2
 
+struct psmouse;
+
+struct psmouse_ptport {
+	struct serio serio;
+
+	void (*activate)(struct psmouse *parent);
+	void (*deactivate)(struct psmouse *parent);
+};
+
 struct psmouse {
 	void *private;
 	struct input_dev dev;
 	struct serio *serio;
+	struct psmouse_ptport *ptport;
 	char *vendor;
 	char *name;
 	unsigned char cmdbuf[8];
@@ -41,6 +51,9 @@ struct psmouse {
 	char error;
 	char devname[64];
 	char phys[32];
+
+	int (*reconnect)(struct psmouse *psmouse);
+	void (*disconnect)(struct psmouse *psmouse);
 };
 
 #define PSMOUSE_PS2		1
drivers/input/mouse/synaptics.c renamed from drivers/input/mouse/synaptics.c~synaptics-reconnect +97 -56

217 lines not on this page · raw message

drivers/input/mouse/synaptics.h renamed from drivers/input/mouse/synaptics.h~synaptics-reconnect +0 -4
diff -puN drivers/input/mouse/synaptics.h~synaptics-reconnect drivers/input/mouse/synaptics.h
@@ -12,8 +12,6 @@
 
 extern void synaptics_process_byte(struct psmouse *psmouse, struct pt_regs *regs);
 extern int synaptics_init(struct psmouse *psmouse);
-extern int synaptics_pt_init(struct psmouse *psmouse);
-extern void synaptics_disconnect(struct psmouse *psmouse);
 
 /* synaptics queries */
 #define SYN_QUE_IDENTIFY		0x00
@@ -105,8 +103,6 @@ struct synaptics_data {
 	/* Data for normal processing */
 	unsigned int out_of_sync;		/* # of packets out of sync */
 	int old_w;				/* Previous w value */
-	
-	struct serio *ptport;			/* pass-through port */
 };
 
 #endif /* _SYNAPTICS_H */

_

#12 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

In reply to Vojtech Pavlik
Quoted 8 lines · Vojtech Pavlik
Quoted 3 lines · Dmitry Torokhov

- Introducing BTN_TOUCH as far as I can seen does nothing to prevent joydev grabbing either Synaptics or touchscreens... Is there a patch missing?

No. It's a statement you're missing near the beginning of joydev_connect().

Ok.. I see... and I hate it. We have a mechanism to match input devices to input handler and we violate it. What could be done is adding a black list to the input handler structure similar to the white list we have now. This way all matching conditions will be kept in one place...

...But, unless I am missing something again, with introduction of BTN_TOUCH, tsdev now will happily claim Synaptics touchpads. We could filter it out by checking for example ABS_PRESSURE in tsdev but it would be just a another band aid. I could easily see a touch screen reporting pressure and multiple fingers. As far as capabilities go touchscreens are almost indistinguishable from touch pads, they just operate as true absolute devices.

IMHO we should let input device driver explicitly request which input handler it wishes to bind to (for example by passing a bitmap of desired input handlers when registering input device and everyone binds to evdev). It is not as flexible as capabilities checking solution but much more simple and predictable. I do not thing that there will be that many handlers implemented...

Should I try to cook something along these lines?

Quoted 5 lines
Quoted 2 lines

BTW, any chance on including pass-through patches? Do you want me to re-diff them?

Hmm, I thought I've merged them in already, but obviously I did not. Please resend them (rediffed if possible). Thanks.

I meant reconnect patches that Peter sent in his last mail, sorry for the confusion.

Dmitry

#13 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 6 lines · Dmitry Torokhov
Quoted 5 lines · Vojtech Pavlik
Quoted 3 lines · Dmitry Torokhov

- Introducing BTN_TOUCH as far as I can seen does nothing to prevent joydev grabbing either Synaptics or touchscreens... Is there a patch missing?

Quoted 6 lines
Quoted 3 lines

No. It's a statement you're missing near the beginning of joydev_connect().

Ok.. I see... and I hate it. We have a mechanism to match input devices to input handler and we violate it.

Well, the mechanism is: check the bit table, if doesn't match, go forward to next handler. Then call the connect function, if it fails, go to next handler.

Originally there only was the connect function which was doing all the decisions, but that meant you have to load all the handler modules to check if they will attach to a device. Now the number of modules is limited, because the hotplug agent can check the tables.

But still the tables aren't (and will never be) the only way to decide if a handler will attach to a specific device.

Quoted 10 lines

What could be done is adding a black list
to the input handler structure similar to the white list we have now. This way all matching conditions will be kept in one place...

...But, unless I am missing something again, with introduction of BTN_TOUCH, tsdev now will happily claim Synaptics touchpads. We could filter it out by checking for example ABS_PRESSURE in tsdev but it would be just a another band aid. I could easily see a touch screen reporting pressure and multiple fingers. As far as capabilities go touchscreens are almost indistinguishable from touch pads, they just operate as true absolute devices.

You're right. And it's a problem.

Quoted 6 lines

IMHO we should let input device driver explicitly request which input handler it wishes to bind to (for example by passing a bitmap of desired input handlers when registering input device and everyone binds to evdev). It is not as flexible as capabilities checking solution but much more simple and predictable. I do not thing that there will be that many handlers implemented...

No, it won't work. It assumes that all the handlers are known beforehand. Someone may want to load their own input handler module and it wouldn't bind to any device, because it wouldn't be on the list.

Also, we need to communicate the information not just to kernel handlers, but also to userspace programs/drivers ...

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

Adding a device class field and ioctl would solve the touchpad / touchscreen problem nicely.

Another option is defining a set of features (events) a touchpad must have and which a touchscreen must have and based on this do the decision on the class. But now I think this is just another bandaid.

Quoted 1 line

Should I try to cook something along these lines?

If you do it the device-class way (be it an int or be it a bitmap), I think it's worth trying.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

BTW, any chance on including pass-through patches? Do you want me to re-diff them?

Hmm, I thought I've merged them in already, but obviously I did not. Please resend them (rediffed if possible). Thanks.

I meant reconnect patches that Peter sent in his last mail, sorry for the confusion.

I don't think I'll apply those, sorry. We really should try to go the driver-model way and not invent our own ways how to restore devices hierarchically.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#14 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 8 lines · Vojtech Pavlik
Quoted 7 lines · Dmitry Torokhov
Quoted 5 lines · Vojtech Pavlik
Quoted 2 lines

BTW, any chance on including pass-through patches? Do you want me to re-diff them?

Hmm, I thought I've merged them in already, but obviously I did not. Please resend them (rediffed if possible). Thanks.

Quoted 6 lines
Quoted 2 lines

I meant reconnect patches that Peter sent in his last mail, sorry for the confusion.

I don't think I'll apply those, sorry. We really should try to go the driver-model way and not invent our own ways how to restore devices hierarchically.

Reconnect patches are merely an extension of serio_rescan mechanism - the only difference is that reconnect tries to keep the same input device if the hardware didn't change. It does not care about any hierarchy, it just a way for someone to try to re-initialize driver (probably the driver itself). I for example never suspend, but my docking station resets the touch pad back to relative mode. With reconnect it is possible to dock and undock with X and GPM running and it will not screw your input devices (rescan would create brand new input devices while X and GPM still use old ones).

The pass-through support of all things implements device hierarchy in non driver-model way and you just included it. The entire input subsystem is not based on the driver model at the moment.. Are there plans to change it in 2.6 timeframe? If not for 2.6 then I would ask you to reconsider, reconnect will make life of users much easier. If you have something in works could I have a peek so I could probably adjust my patches.

BTW, is it possible with current driver model to reinitialize an arbitrary device, not entire bus?

Dmitry

#15 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

In reply to Vojtech Pavlik

Hi!

Quoted 11 lines
Quoted 6 lines

IMHO we should let input device driver explicitly request which input handler it wishes to bind to (for example by passing a bitmap of desired input handlers when registering input device and everyone binds to evdev). It is not as flexible as capabilities checking solution but much more simple and predictable. I do not thing that there will be that many handlers implemented...

No, it won't work. It assumes that all the handlers are known beforehand. Someone may want to load their own input handler module and it wouldn't bind to any device, because it wouldn't be on the list.

Quoted 8 lines

Also, we need to communicate the information not just to kernel handlers, but also to userspace programs/drivers ...

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

I believe having "is overlaid over screen" bit gets it right :-).

Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#16 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 16 lines · Pavel Machek

Hi!

Quoted 14 lines
Quoted 6 lines

IMHO we should let input device driver explicitly request which input handler it wishes to bind to (for example by passing a bitmap of desired input handlers when registering input device and everyone binds to evdev). It is not as flexible as capabilities checking solution but much more simple and predictable. I do not thing that there will be that many handlers implemented...

No, it won't work. It assumes that all the handlers are known beforehand. Someone may want to load their own input handler module and it wouldn't bind to any device, because it wouldn't be on the list.

Also, we need to communicate the information not just to kernel handlers, but also to userspace programs/drivers ...

Quoted 7 lines
Quoted 5 lines

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

I believe having "is overlaid over screen" bit gets it right :-).

Tablets aren't. And they're handled the same way as touchscreens.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#17 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Hi!

Quoted 9 lines
Quoted 7 lines
Quoted 5 lines

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

I believe having "is overlaid over screen" bit gets it right :-).

Tablets aren't. And they're handled the same way as touchscreens.

Ouch, so what's the difference between tablet and touchpad? Is it only in a way you are expected to use it? In such case "this is touchpad" bit is probably needed :-(.
Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#18 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 8 lines · Pavel Machek

Hi!

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

I believe having "is overlaid over screen" bit gets it right :-).

Tablets aren't. And they're handled the same way as touchscreens.

Ouch, so what's the difference between tablet and touchpad? Is it only in a way you are expected to use it? In such case "this is touchpad" bit is probably needed :-(.

For a tablet, the cursor follows the pen movement all the time. For a touchpad, if you lift the finger and place it elsewhere, nothing happens. This way you can move the cursor further by repeatedly stroking the pad.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#19 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Hi!

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

I believe having "is overlaid over screen" bit gets it right :-).

Tablets aren't. And they're handled the same way as touchscreens.

Quoted 8 lines
Quoted 3 lines

Ouch, so what's the difference between tablet and touchpad? Is it only in a way you are expected to use it? In such case "this is touchpad" bit is probably needed :-(.

For a tablet, the cursor follows the pen movement all the time. For a touchpad, if you lift the finger and place it elsewhere, nothing happens. This way you can move the cursor further by repeatedly stroking the pad.

But difference is only in software, right? You could use synaptics as a tablet, its just little small. So perhaps "this is touchpad" bit is needed.

Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#20 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 16 lines · Pavel Machek

Hi!

Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines

One thing I tried to avoid is a 'device class' kind of field, that'd tell if a device is a mouse a touchpad, touchscreen, tablet, whatever. I tried to avoid it because there are devices that don't fall into any predefined class and if we make enough classes, someone someday will make a device that won't fit again.

I believe having "is overlaid over screen" bit gets it right :-).

Tablets aren't. And they're handled the same way as touchscreens.

Ouch, so what's the difference between tablet and touchpad? Is it only in a way you are expected to use it? In such case "this is touchpad" bit is probably needed :-(.

Quoted 8 lines
Quoted 4 lines

For a tablet, the cursor follows the pen movement all the time. For a touchpad, if you lift the finger and place it elsewhere, nothing happens. This way you can move the cursor further by repeatedly stroking the pad.

But difference is only in software, right? You could use synaptics as a tablet, its just little small. So perhaps "this is touchpad" bit is needed.

Yes, exactly so. We may have similar problems with differentiation elsewhere (touchpad vs 6dof device), so we'll probably need the 'class' field.

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#21 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 3 lines · Vojtech Pavlik

Yes, exactly so. We may have similar problems with differentiation elsewhere (touchpad vs 6dof device), so we'll probably need the 'class' field.

I don't know if this is relevant, but there are some devices which can work in either relative (like a touchpad) or absolute (like a touchscreen) mode. For example, using a combination of the kernel and the X drivers, at the moment I have my Wacom tablet working in relative mode when I'm using its mouse, but absolute mode when I'm using its pen.

I'm wondering whether we don't so much need a device class, as something to say whether the device works in absolute or relative mode, and that possibly we might have devices where this could be dynamically changed.

M

Signature · 3 lines
"It's the small gaps between the rain that count,
 and learning how to live amongst them."
	      -- Jeff Noon
#22 lore raw

Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.

Quoted 11 lines · Matt Gibson
Quoted 3 lines · Vojtech Pavlik

Yes, exactly so. We may have similar problems with differentiation elsewhere (touchpad vs 6dof device), so we'll probably need the 'class' field.

I don't know if this is relevant, but there are some devices which can work in either relative (like a touchpad) or absolute (like a touchscreen) mode. For example, using a combination of the kernel and the X drivers, at the moment I have my Wacom tablet working in relative mode when I'm using its mouse, but absolute mode when I'm using its pen.

Quoted 3 lines

I'm wondering whether we don't so much need a device class, as something to say whether the device works in absolute or relative mode, and that possibly we might have devices where this could be dynamically changed.

That's a pretty neat idea, actually. Thanks!

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#23 lore raw

Re: [PATCH 6/8] Extend KD?BENT to handle > 256 keycodes.

In reply to Vojtech Pavlik
Quoted 5 lines · Vojtech Pavlik

input: Create new KD?BENT ioctls with a bigger key range (int), so that
it's posible to recompile kbdutils on 2.6 and load keymaps for keys beyond 128. kbdutils compiled on 2.4 will keep working on 2.6, unfortunately not vice versa, without changing kbdutils.

Doesn't compile with older gcc's

drivers/char/vt_ioctl.c renamed from drivers/char/vt_ioctl.c~input-06-extend-entries-fix +1 -1
diff -puN drivers/char/vt_ioctl.c~input-06-extend-entries-fix drivers/char/vt_ioctl.c
@@ -77,7 +77,7 @@ asmlinkage long sys_ioperm(unsigned long
 static inline int
 do_kdsk_ioctl(int cmd, void *user_kbe, int perm, struct kbd_struct *kbd)
 {
-	struct kbentry tmp, *kbe = user_kbe;;
+	struct kbentry tmp, *kbe = user_kbe;
 	struct kbentry_old old, *old_kbe = user_kbe;
 	ushort *key_map, val, ov;
 

_

author Applied
#24 lore raw

Re: [PATCH 6/8] Extend KD?BENT to handle > 256 keycodes.

Quoted 8 lines · Andrew Morton
Quoted 5 lines · Vojtech Pavlik

input: Create new KD?BENT ioctls with a bigger key range (int), so that
it's posible to recompile kbdutils on 2.6 and load keymaps for keys beyond 128. kbdutils compiled on 2.4 will keep working on 2.6, unfortunately not vice versa, without changing kbdutils.

Doesn't compile with older gcc's

Thanks, applied.

Quoted 15 lines

diff -puN drivers/char/vt_ioctl.c~input-06-extend-entries-fix drivers/char/vt_ioctl.c

drivers/char/vt_ioctl.c renamed from drivers/char/vt_ioctl.c~input-06-extend-entries-fix +1 -1
@@ -77,7 +77,7 @@ asmlinkage long sys_ioperm(unsigned long
 static inline int
 do_kdsk_ioctl(int cmd, void *user_kbe, int perm, struct kbd_struct *kbd)
 {
-	struct kbentry tmp, *kbe = user_kbe;;
+	struct kbentry tmp, *kbe = user_kbe;
 	struct kbentry_old old, *old_kbe = user_kbe;
 	ushort *key_map, val, ov;
 

_

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#25 lore raw

Re: [PATCH 6/8] Extend KD?BENT to handle > 256 keycodes.

In reply to Vojtech Pavlik
Quoted 9 lines · Vojtech Pavlik
include/linux/kd.h +4 -1
-struct kbentry {
+struct kbentry_old {
 	unsigned char kb_table;
 	unsigned char kb_index;
 	unsigned short kb_value;
 };
+#define KDGKBENT_OLD	0x4B46	/* gets one entry in translation table (old) */
+#define KDSKBENT_OLD	0x4B47	/* sets one entry in translation table (old) */
+

include/linux/kd.h line 116

Quoted 10 lines
include/linux/kd.h +7 -2
+struct kbentry {
+	unsigned int kb_table;
+	unsigned int kb_index;
+	unsigned short kb_value;
+};
 
-#define KDGKBENT	0x4B46	/* gets one entry in translation table */
-#define KDSKBENT	0x4B47	/* sets one entry in translation table */
+#define KDGKBENT	0x4B73	/* gets one entry in translation table */
+#define KDSKBENT	0x4B74	/* sets one entry in translation table */

Please don't.

As said already, no new ioctls are needed today, but if you add some anyway, please leave old names unchanged and add something new, like KDSKBENT32 or so.

Reusing old ioctl names for new uses is very bad practice.

Andries

#26 lore raw

Re: [PATCH 6/8] Extend KD?BENT to handle > 256 keycodes.

Quoted 17 lines · Andries Brouwer
Quoted 14 lines · Vojtech Pavlik
include/linux/kd.h +9 -1
-struct kbentry {
+struct kbentry_old {
 	unsigned char kb_table;
 	unsigned char kb_index;
 	unsigned short kb_value;
 };
+#define KDGKBENT_OLD	0x4B46	/* gets one entry in translation table (old) */
+#define KDSKBENT_OLD	0x4B47	/* sets one entry in translation table (old) */
+
+struct kbentry {
+	unsigned int kb_table;
+	unsigned int kb_index;
+	unsigned short kb_value;
+};
Quoted 8 lines

include/linux/kd.h line 116

Quoted 4 lines
include/linux/kd.h +2 -2
-#define KDGKBENT	0x4B46	/* gets one entry in translation table */
-#define KDSKBENT	0x4B47	/* sets one entry in translation table */
+#define KDGKBENT	0x4B73	/* gets one entry in translation table */
+#define KDSKBENT	0x4B74	/* sets one entry in translation table */

Please don't.

As said already, no new ioctls are needed today,

Well, as already said, there are two ways to go:

1) Keep NR_KEYS at 512 (or more in the future, iff needed), and have new ioctls.

2) Decrease NR_KEYS to 256 or better 255 or 254, so that for() cycles don't break because of limited range of the iterator, and optimize the KEY_* macros in input.h to fit in that range.

This however means moving some already #defined macros to other values, which hopefully is not too big a problem, as few are using it.

And it's likely we overflow the 254 entries soon, nevertheless, so we will need the new ioctls anyway.

Quoted 4 lines

but if you add some anyway, please leave old names unchanged and add something new, like KDSKBENT32 or so.

Reusing old ioctl names for new uses is very bad practice.

Ok, I'm willing to give approach #2 a chance. But I'll need help from you - as you have the most extensive list of extended keyboards - would you please help me by creating a list of most used (and most standard) keys on those keyboards and scancodes (unxlated set2) associated with those?

I'd then add what USB and Sun and others use and this way we should be able to trim down the amount of defined keys down a bit.

I'm postponing the KD?KBENT patch for the moment ...

Signature · 2 lines
Vojtech Pavlik
SuSE Labs, SuSE CR
#27 lore raw

Re: [PATCH 5/8] Rely less on sanity of AT keyboards.

In reply to Vojtech Pavlik
Quoted 13 lines · Vojtech Pavlik

diff -Nru a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c

drivers/input/mouse/psmouse-base.c +2 -0
@@ -28,6 +28,8 @@
 MODULE_PARM_DESC(psmouse_noext, "Disable any protocol extensions. Useful for KVM switches.");
 MODULE_PARM(psmouse_resolution, "i");
 MODULE_PARM_DESC(psmouse_resolution, "Resolution, in dpi.");
+MODULE_PARM(psmouse_rate, "i");
+MODULE_PARM_DESC(psmouse_rate, "Report rate, in reports per second.");
 MODULE_PARM(psmouse_smartscroll, "i");
 MODULE_PARM_DESC(psmouse_smartscroll, "Logitech Smartscroll autorepeat, 1 = enabled (default), 0 = disabled.");
 MODULE_PARM(psmouse_resetafter, "i");

drivers/input/mouse/psmouse-base.c line 43

Quoted 4 lines
drivers/input/mouse/psmouse-base.c +1 -0
@@ -38,6 +40,7 @@
 
 static int psmouse_noext;
 int psmouse_resolution;
+unsigned int psmouse_rate = 60;

Please change this back to 200. Mousebehaviour is _really_ horrible with
60. There's currently no way to change it for kernels with this driver compiled in.

Here's a patch to change it back to 200 and readd the fallback to a lower rate if the requested failed to be set.

drivers/input/mouse/psmouse-base.c renamed from drivers/input/mouse/psmouse-base.c.orig +6 -1
@@ -40,7 +40,7 @@
 
 static int psmouse_noext;
 int psmouse_resolution;
-unsigned int psmouse_rate = 60;
+unsigned int psmouse_rate = 200;
 int psmouse_smartscroll = PSMOUSE_LOGITECH_SMARTSCROLL;
 unsigned int psmouse_resetafter;
 
@@ -450,6 +450,11 @@
 	int i = 0;
 
 	while (rates[i] > psmouse_rate) i++;
+
+	/* set lower rate in case requested rate fails */
+	if (rates[i])
+		psmouse_command(psmouse, rates + i + 1, PSMOUSE_CMD_SETRATE);
+
 	psmouse_command(psmouse, rates + i, PSMOUSE_CMD_SETRATE);
 }
 
Signature · 1 line
/Martin
#28 lore raw
In reply to Vojtech Pavlik
Quoted 3 lines · Vojtech Pavlik

I'm sending you my current set of patches for review and testing. Please forward to whoever can test them. If no problems are found, I'll be sending them to Linus for inclusion in 2.6 tomorrow or so.

I tried this patch set on my Clevo laptop and the touchpad is working fine. The patch set also fixes keyboard problems that I started seeing a few days ago. (Very slow auto repeat and randomly stuck CTRL key.)

Signature · 2 lines
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340