This is a weird device; it is missing almost all DMI info so there's
not much to match against to figure out when to enable this quirk, but
hopefully the fact that (almost) everything is set to "Default string"
is in itself enough to distinguish it.
This device has one of the broken SIPODEV touchpads that does not
respond to requests for HID descriptors and reports. The kernel has an
existing quirk for this where it just injects hardcoded values copied
from Windows. (I ran through the complicated steps to get the values
from Windows to make sure the IOXO values match up with the existing
ones in i2c-hid-dmi-quirks.c, and other than a slight variation in
the reported size of the touchpad, they do.)
Unlike other known devices with this touchpad, this one pretends to be
an Alps touchpad instead of a Synaptic touchpad, so the existing quirk
doesn't quite work. Worked around this by adding an extra test: if the
DMI info looks like it's the IOXO device, check the i2c name against
"ALPS0001:01" instead of "SYNA3602:00".
I deduplicated the checks in i2c_hid_get_dmi_i2c_hid_desc_override
and i2c_hid_get_dmi_hid_report_desc_override to make this hack a
little easier to follow.
This is a weird device; it is missing almost all DMI info so there's not much to match against to figure out when to enable this quirk, but hopefully the fact that (almost) everything is set to "Default string" is in itself enough to distinguish it.
This device has one of the broken SIPODEV touchpads that does not respond to requests for HID descriptors and reports. The kernel has an existing quirk for this where it just injects hardcoded values copied from Windows. (I ran through the complicated steps to get the values from Windows to make sure the IOXO values match up with the existing ones in
i2c-hid-dmi-quirks.c, and other than a slight variation in the reported size of the touchpad, they do.)Unlike other known devices with this touchpad, this one pretends to be an Alps touchpad instead of a Synaptic touchpad, so the existing quirk doesn't quite work. Worked around this by adding an extra test: if the DMI info looks like it's the IOXO device, check the i2c name against "ALPS0001:01" instead of "SYNA3602:00".
I deduplicated the checks in
i2c_hid_get_dmi_i2c_hid_desc_overrideandi2c_hid_get_dmi_hid_report_desc_overrideto make this hack a little easier to follow.cherry-picked from: https://github.com/neverware/kernel/commit/6aacf354b806cf3e27fe9a695ebe43b13be885fd
Signed-off-by: Matt DeVillier matt.devillier@gmail.com