Hi, On 11/7/22 11:52, Benjamin Tissoires wrote: > Hi Hans, > > On Mon, Nov 7, 2022 at 11:10 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> Hi Benjamin, et. al., >> >> I have just merged a patch which adds a couple of DMI quirks to disable >> the touchpad on/off functionality of the ideapad-laptop module on some models, >> because it is causing issues there. >> >> Patch: https://lore.kernel.org/platform-driver-x86/20221018095323.14591-1-limanyi@xxxxxxxxxxxxx/ >> Discussion: https://lore.kernel.org/platform-driver-x86/fdceb6d2-c38c-e8ff-4c19-b01521ca46c0@xxxxxxxxxx/ >> >> Rather then using DMI quirks I would prefer to just disable it everywhere >> where a i2c-attached touchpad is used. Be it either one only attached to >> i2c, or one of the synaptics intertouch thingies. I'm still trying to >> figure out why the ideapad-laptop module's touchpad control (which >> uses the EC + enabling/disabling the i8042 aux-port) matters for >> i2c-attached touchpads at all, so I suspect that intertouch might be >> a part of it. >> >> So now I'm wondering if there is some nice way for the ideapad-laptop >> code to check if the touchpad is intertouch and/or if it is i2c-attached >> only ... >> >> Any ideas? > > TL;DR: it's a complete mess. > > For mostly UEFI/BIOS compatibility, all touchpads on modern laptops > have a PS/2 interface. > > But then, most of the touchpads (and of course not all) can also use > I2C or SMBus to communicate. > > And this is where things are bad: > > - when using i2c-hid, there is a DT entry that enumerates the > touchpad, but sometimes the manufacturers like to reuse the same DT > and just enable/disable devices in it, so it's not easy to do. > In the i2c-hid case, the PS/2 node has no idea it is not used anymore, > and thus is kept up forever > > - for touchpads using SMBus (on Intel platforms only currently), the > enumeration is done at the PS/2 level: there is a byte that says that > the touchpad supports another bus or not. > This is valid for both Synaptics, and Elan, as you figured out. > > But in the SMBus case there are many cases where it is not working: if > the SMBus doesn't support Host Notify (AMD platforms), or if the > enumeration is not working because the touchpad is not happy, etc... > > So again, in SMBus, we can not disable the PS/2 nodes, because there > is a high chance the touchpad will not work. Not to mention that the > specific bit to enable the touchpad might also be required when coming > back from suspend (not entirely sure though). > > However, in the Synaptics SMbus case, we took a safer approach > (because the SMBus driver is not standard and sometimes breaks on new > hardware), so we are using the PnP ID to selectively enable the > devices (see smbus_pnp_ids[] in drivers/input/mouse/synaptics.c) > > In the Elan case, if the touchpad exports the magic bit, we forward it > to SMBus as the driver is behaving better with new devices. > > As a result, from user space, it's easier to know if the device uses > smbus/i2c, simply because you can enumerate all devices. > But from the kernel, either you have to look for the ACPI tables, and > hope that the I2C bus is correctly supported in the system, or you > have to talk over PS/2 and hope that the platform supports > HostNotify... > >> >> Regards, >> >> Hans >> >> p.s. >> >> Is it possible that Elan touchpads use something similar to intertouch, >> or is that a synaptics thing only (under Linux) ? >> > > Yep, see above. If the touchpad says it can be driven through SMBus, > we forward it. Ok, thank you for the long answer. I will try to find some generic solution on the ideapad-laptop driver side. First of all we need to root cause which call in that driver is exactly causing the touchpad to not work. Regards, hans
