My current patches
Subsystems (3)
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
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
@@ -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; }
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
@@ -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);
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
@@ -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 ;
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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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;
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
@@ -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);
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
@@ -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
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
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_TOUCHevent to detect whether the pad is touched orABS_PRESSURE? IfABS_PRESSUREthenBTN_TOUCHis 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_TOUCHas 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
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
@@ -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 2static 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
@@ -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
@@ -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
@@ -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
@@ -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 */
_
Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.
In reply to Vojtech PavlikQuoted 8 lines · Vojtech Pavlik
Quoted 3 lines · Dmitry Torokhov
- Introducing
BTN_TOUCHas 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
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_TOUCHas 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 exampleABS_PRESSUREin 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
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
Re: [PATCH 8/8] Add BTN_TOUCH to Synaptics driver. Update mousedev.
In reply to Vojtech PavlikHi!
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?]
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
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?]
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
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?]
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
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
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
Re: [PATCH 6/8] Extend KD?BENT to handle > 256 keycodes.
In reply to Vojtech PavlikQuoted 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
@@ -77,7 +77,7 @@ asmlinkage long sys_ioperm(unsigned longstatic 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;
_
Vojtech Pavlik
AppliedRe: [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-fixdrivers/char/vt_ioctl.cdrivers/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 longstatic 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
Re: [PATCH 6/8] Extend KD?BENT to handle > 256 keycodes.
In reply to Vojtech PavlikQuoted 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
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
Re: [PATCH 5/8] Rely less on sanity of AT keyboards.
In reply to Vojtech PavlikQuoted 13 lines · Vojtech Pavlik
diff -Nru
a/drivers/input/mouse/psmouse-base.cb/drivers/input/mouse/psmouse-base.cdrivers/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
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