Hi, On 11/10/22 19:09, Maxim Mikityanskiy wrote: > On Thu, 10 Nov 2022 at 19:54, Maxim Mikityanskiy <maxtram95@xxxxxxxxx> wrote: >> >> On Thu, 10 Nov 2022 at 18:42, Eray Orçunus <erayorcunus@xxxxxxxxx> wrote: >>> >>> Hi Hans, >>> >>> On 10 Nov 2022 at 15:37, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>>> On 11/10/22 13:00, Eray Orçunus wrote: >>>>> While I agree with your findings(and thanks for your effort, I also tried >>>>> to solve this but later gave up), they doesn't apply to one type of >>>>> IdeaPads (like my 520-15IKB), so I'm sure this patch won't work on me. >>>>> This is because my IdeaPad has this features: >>>>> >>>>> - i8042.noaux doesn't affect touchpad, and it's connected over i2c >>>>> - There is no touchpad LED, and touchpad hotkey only sends "key pressed" >>>>> ACPI event, doesn't do anything else >>>>> - VPCCMD_W_TOUCHPAD does nothing (also confirmed on Windows) >>>>> - Sending 1 to VPCCMD_W_TOUCHPAD on boot is not needed >>>>> - VPCCMD_R_TOUCHPAD always returns 1 (this is interesting) >>>> >>>> So if i8042.noaux does not do anything, then why do you want to add >>>> "SYNA2B33" to the list of ACPI HIDs for which we set: >>>> >>>> features.touchpad_ctrl_via_ec=0; >>>> >>>> ? >>>> >>>> IOW what bad effects / behavior are you seeing with touchpad_ctrl_via_ec=1? >>>> >>>> Or are you seeing bad behavior on some other modes? If yes, then what >>>> is the bad behavior you are seeing on other models ? >>> >>> It was just because I didn't want to have a not working "touchpad" >>> attribute :) I used/still using several GNOME extensions and they show >>> me "Touchpad" toggle just because I have "touchpad" attribute exposed >>> there, which is doing nothing, and misleading. >>> >>> But I would understand if you don't want to touch it at that stage, and >>> you would rather prefer not working "touchpad" attributes to not >>> exposed "touchpad" attributes that would have been perfectly working. >>> >>>> I'm guessing that this part: >>>> >>>> unsigned char param; >>>> /* >>>> * Some IdeaPads don't really turn off touchpad - they only >>>> * switch the LED state. We (de)activate KBC AUX port to turn >>>> * touchpad off and on. We send KEY_TOUCHPAD_OFF and >>>> * KEY_TOUCHPAD_ON to not to get out of sync with LED >>>> */ >>>> i8042_command(¶m, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE); >>>> >>>> May cause issues on some models. It definitely feels fishy and >>>> I would like to disable this except on models where: >>>> >>>> 1. There is a LED controlled by some touchpad on/off hotkey; and >>>> 2. The EC fails to disable the touchpad itself >>>> >>>> Which would currently mean only enable this bit on Maxim's Z570 >>>> using a DMI based allow list. >> >> A small note on the DMI allow-list: I don't think Z570 is the only >> laptop where EC fails to disable the touchpad. While I would like this >> hack to affect as few laptops as possible, I would expect that other >> similar models produced in the same time period suffer from the same >> issue, and I don't think we have the full list of them. > > And another idea: i8042_command(I8042_CMD_AUX_DISABLE) can be replaced > with installing a i8042_platform_filter that will filter out all > I8042_STR_AUXDATA when the touchpad should be disabled. It's > definitely less fishy, we don't touch the KBC, but simply filter out > events in software. That can still cause issues for dual-mode (i2c + ps2) touchpads which initially get probed in ps2 mode and then switched over to i2c mode later. Often this switching over needs to be redone at resume time too, so for this to work we really need the ps2 aux port to fully work. I do agree using a platform filter would be somewhat cleaner, but what we have now has been in use for a long time now without issues, so I'm in favor of an if it aint broken don't fix approach here. That is on devices where we need to actually do something to disable ps2 aux traffic, lets keep the current approach. While try to just not mess with the i8042 controller *at all* on other devices. Regards, Hans
