| Message ID | 41de7f92-8d98-3266-5d28-28ba48c5da38@pa-w.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On May 19, 2017 11:46:16 AM PDT, Pascal Wichmann <pascal.wichmann@pa-w.de> wrote: >Hello, > >using the latest 4.12-rc1 kernel, the trackpoint and touchpad of my >Thinkpad X250 are not recognized. > >This is caused by commit >e839ffa Input: synaptics - add support for Intertouch devices > > >The specific problem seems to be the detection of whether to use >synaptics_intertouch for the psmouse module or not. That parameter >is set to -1 by default, in which case synaptics_intertouch is >enabled on my device. > >When I explicitly set that parameter to 0, the trackpoint and touchpad >are recognized and work as expected. > >Removing my device from smbus_pnp_ids in 4.12 rc1 fixes the issue >without need to manually disable synaptics_intertouch in the psmouse >module: > >diff -ruN a/drivers/input/mouse/synaptics.c >b/drivers/input/mouse/synaptics.c >--- a/drivers/input/mouse/synaptics.c 2017-05-19 19:31:48.930734395 >+0200 >+++ b/drivers/input/mouse/synaptics.c 2017-05-19 19:32:00.490782484 >+0200 >@@ -170,7 +170,6 @@ > static const char * const smbus_pnp_ids[] = { > /* all of the topbuttonpad_pnp_ids are valid, we just add some extras >*/ > "LEN0048", /* X1 Carbon 3 */ >- "LEN0046", /* X250 */ > "LEN004a", /* W541 */ > "LEN200f", /* T450s */ > NULL > > >Is the ThinkPad X250 not supporting intertouch or is there another >problem causing the input devices not to work with it enabled? > Do you have i801_smbus driver enabled and loaded? Thanks.
> Do you have i801_smbus driver enabled and loaded? I have the following line in my kernel configuration: > CONFIG_I2C_I801=m Following i2c/smbus-related modules are loaded: > lsmod | grep i2c :( > i2c_smbus 16384 0 > i2c_i801 24576 0 > i2c_algo_bit 16384 1 i915 lshw has the following output specifying i801_smbus as driver: > *-serial > description: SMBus > product: Wildcat Point-LP SMBus Controller > vendor: Intel Corporation > physical id: 1f.3 > bus info: pci@0000:00:1f.3 > version: 03 > width: 64 bits > clock: 33MHz > configuration: driver=i801_smbus latency=0 > resources: irq:18 memory:f1238000-f12380ff ioport:efa0(size=32) Thanks, Pascal
On Fri, May 19, 2017 at 09:37:32PM +0200, Pascal Wichmann wrote: > > Do you have i801_smbus driver enabled and loaded? > > I have the following line in my kernel configuration: > > > CONFIG_I2C_I801=m > > Following i2c/smbus-related modules are loaded: > > > lsmod | grep i2c > :( > > i2c_smbus 16384 0 > > i2c_i801 24576 0 > > i2c_algo_bit 16384 1 i915 > > lshw has the following output specifying i801_smbus as driver: > > > *-serial > > description: SMBus > > product: Wildcat Point-LP SMBus Controller > > vendor: Intel Corporation > > physical id: 1f.3 > > bus info: pci@0000:00:1f.3 > > version: 03 > > width: 64 bits > > clock: 33MHz > > configuration: driver=i801_smbus latency=0 > > resources: irq:18 memory:f1238000-f12380ff ioport:efa0(size=32) Hmm, what about rmi_core and rmi_smbus? It might be quicker if you send your dmesg, .config and lsmod... Thanks.
On Fri, May 19, 2017 at 10:35:59PM +0200, Pascal Wichmann wrote: > > Hmm, what about rmi_core and rmi_smbus? It might be quicker if you send > > your dmesg, .config and lsmod... > > dmesg: > ... > > [ 12.944519] psmouse serio1: synaptics: queried max coordinates: x [..5712], y [..4780] > > [ 12.975692] psmouse serio1: synaptics: queried min coordinates: x [1232..], y [1074..] > > [ 13.036464] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xf002a3/0x943300/0x12e800/0x10000, board id: 3075, fw id: 2560 > > [ 13.036480] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 > > [ 13.075182] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input13 > > [ 13.078710] mousedev: PS/2 mouse device common for all mice Looks like you running your patched kernel? ... > > CONFIG_RMI4_CORE=m > > CONFIG_RMI4_I2C=m > > CONFIG_RMI4_SPI=m > > # CONFIG_RMI4_SMB is not set This is your issue I believe. > > CONFIG_RMI4_F03=y > > CONFIG_RMI4_F03_SERIO=m > > CONFIG_RMI4_2D_SENSOR=y > > CONFIG_RMI4_F11=y > > CONFIG_RMI4_F12=y > > CONFIG_RMI4_F30=y > > # CONFIG_RMI4_F34 is not set > > CONFIG_RMI4_F54=y > > CONFIG_RMI4_F55=y Thanks.
> Looks like you running your patched kernel? That's right. >>> CONFIG_RMI4_CORE=m >>> CONFIG_RMI4_I2C=m >>> CONFIG_RMI4_SPI=m >>> # CONFIG_RMI4_SMB is not set > > This is your issue I believe. Indeed, enabling that configuration solves that issue. However, I think it is quite unintuitive that a module (psmouse) chooses a default mode which requires another driver which is not necessarily included; though it would probably be not a very clean solution to explicitly check that as well. Is this behaviour, that one module requires another without communicating that clearly, wanted? Thanks, Pascal
Hi, On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > Looks like you running your patched kernel? > That's right. > > > >>> CONFIG_RMI4_CORE=m > >>> CONFIG_RMI4_I2C=m > >>> CONFIG_RMI4_SPI=m > >>> # CONFIG_RMI4_SMB is not set > > > > This is your issue I believe. > > Indeed, enabling that configuration solves that issue. > > However, I think it is quite unintuitive that a module (psmouse) chooses > a default mode which requires another driver which is not necessarily > included; though it would probably be not a very clean solution to > explicitly check that as well. > > Is this behaviour, that one module requires another without > communicating that clearly, wanted? > I can see 3 solutions: 1. Have PS2_SMBUS depending on RMI_SMBUS (and ELAN_I2C, and others when required) 2. Have PS2_SMBUS selecting RMI_SMBUS (and the others when time comes) 3. Changing the default value of synaptics_intertouch to SYNAPTICS_INTERTOUCH_OFF when RMI_SMBUS is not set Solution 3. might be interesting because it doesn't prevent users to compile the module on the side and is Synaptics only. Dmitry, any comments? Cheers, Benjamin > Thanks, > Pascal > > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, May 20, 2017 at 11:59:50AM +0200, Benjamin Tissoires wrote: > Hi, > > On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > > Looks like you running your patched kernel? > > That's right. > > > > > > >>> CONFIG_RMI4_CORE=m > > >>> CONFIG_RMI4_I2C=m > > >>> CONFIG_RMI4_SPI=m > > >>> # CONFIG_RMI4_SMB is not set > > > > > > This is your issue I believe. > > > > Indeed, enabling that configuration solves that issue. > > > > However, I think it is quite unintuitive that a module (psmouse) chooses > > a default mode which requires another driver which is not necessarily > > included; though it would probably be not a very clean solution to > > explicitly check that as well. > > > > Is this behaviour, that one module requires another without > > communicating that clearly, wanted? > > > > I can see 3 solutions: > 1. Have PS2_SMBUS depending on RMI_SMBUS (and ELAN_I2C, and others when > required) > 2. Have PS2_SMBUS selecting RMI_SMBUS (and the others when time comes) > 3. Changing the default value of synaptics_intertouch to > SYNAPTICS_INTERTOUCH_OFF when RMI_SMBUS is not set > > Solution 3. might be interesting because it doesn't prevent users to > compile the module on the side and is Synaptics only. > > Dmitry, any comments? I like #3. We might also want to stick a warning into synaptics.c when we see a device that has intertouch, but RMI_SMBUS is disabled, so we could nudge users to switch over to RMI. Thanks.
On May 20 2017 or thereabouts, Dmitry Torokhov wrote: > On Sat, May 20, 2017 at 11:59:50AM +0200, Benjamin Tissoires wrote: > > Hi, > > > > On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > > > Looks like you running your patched kernel? > > > That's right. > > > > > > > > > >>> CONFIG_RMI4_CORE=m > > > >>> CONFIG_RMI4_I2C=m > > > >>> CONFIG_RMI4_SPI=m > > > >>> # CONFIG_RMI4_SMB is not set > > > > > > > > This is your issue I believe. > > > > > > Indeed, enabling that configuration solves that issue. > > > > > > However, I think it is quite unintuitive that a module (psmouse) chooses > > > a default mode which requires another driver which is not necessarily > > > included; though it would probably be not a very clean solution to > > > explicitly check that as well. > > > > > > Is this behaviour, that one module requires another without > > > communicating that clearly, wanted? > > > > > > > I can see 3 solutions: > > 1. Have PS2_SMBUS depending on RMI_SMBUS (and ELAN_I2C, and others when > > required) > > 2. Have PS2_SMBUS selecting RMI_SMBUS (and the others when time comes) > > 3. Changing the default value of synaptics_intertouch to > > SYNAPTICS_INTERTOUCH_OFF when RMI_SMBUS is not set > > > > Solution 3. might be interesting because it doesn't prevent users to > > compile the module on the side and is Synaptics only. > > > > Dmitry, any comments? > > I like #3. We might also want to stick a warning into synaptics.c when > we see a device that has intertouch, but RMI_SMBUS is disabled, so we > could nudge users to switch over to RMI. > OK, thanks. See the following series that should have all of this. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -ruN a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c --- a/drivers/input/mouse/synaptics.c 2017-05-19 19:31:48.930734395 +0200 +++ b/drivers/input/mouse/synaptics.c 2017-05-19 19:32:00.490782484 +0200 @@ -170,7 +170,6 @@ static const char * const smbus_pnp_ids[] = { /* all of the topbuttonpad_pnp_ids are valid, we just add some extras */ "LEN0048", /* X1 Carbon 3 */ - "LEN0046", /* X250 */ "LEN004a", /* W541 */ "LEN200f", /* T450s */ NULL