| Message ID | 1397734903-26088-2-git-send-email-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Hans,
On Thu, Apr 17, 2014 at 01:41:43PM +0200, Hans de Goede wrote:
> We expect that all the Haswell series will need such quirks, sigh.
Given this statement do we really want this to be handled in kernel?
Maybe we simply want udev to fix up the limits with EVIOSABS(),
similarly to how we adjust keymaps for laptops?
Thanks.
Hi, On 04/17/2014 05:35 PM, Dmitry Torokhov wrote: > Hi Hans, > > On Thu, Apr 17, 2014 at 01:41:43PM +0200, Hans de Goede wrote: >> We expect that all the Haswell series will need such quirks, sigh. > > Given this statement do we really want this to be handled in kernel? I know this answer won't make you happy, but short term: Yes, we are getting many many bugreports about this, ie: https://bugzilla.redhat.com/show_bug.cgi?id=1060885 https://bugzilla.redhat.com/show_bug.cgi?id=1068716 https://bugzilla.redhat.com/show_bug.cgi?id=1085582 https://bugzilla.redhat.com/show_bug.cgi?id=1085697 https://bugzilla.redhat.com/show_bug.cgi?id=1086227 And by extending the *already present* quirk table we can get this issue resolved quickly, and also resolve it for people running older kernels through the various stable series. > Maybe we simply want udev to fix up the limits with EVIOSABS(), Ah, I did not know that it is possible to fixup the min/max values from user space, that is good to know. > similarly to how we adjust keymaps for laptops? We're currently looking into various ways to make this less painful, specifically for most laptops the problem seems to be the min value and not the max value. And the troublesome min value is the synaptics driver default, not the one we get from the firmware. The problem is we never ask the firmware because even though it has the "I can report min values" capability bit, its "maximum understood request" number is too low, so one of our 2 checks for getting the min value is failing. If we remove that check some models do give us a proper range (but not all, ie the T440s is still wrong). We're currently trying to figure out if it will be safe for all models to remove the "maximum understood request" number check. That should ie remove the quirk for the x240 and possible others. An other option to make this better is to switch the quirks to using pnp-ids, ie the L440 and L540 share the same pnp-id. Once you've merged the firmware_id patches I can take a shot at simplifying the quirk table that way. Downside is that we then probably need to put the firmware_id patches in the various stable kernels. Note that even if we end up moving this to userspace, then we still need the firmware_id, because I believe any userspace solution should be using pnp-ids too. TL;DR: It is complicated and for now we would like to continue with the quirks as we've done sofar. We are aware that this is undesirable from a maintenance pov and are looking into making this better. Regards, Hans -- 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 Thu, Apr 17, 2014 at 05:53:10PM +0200, Hans de Goede wrote: > Hi, > > On 04/17/2014 05:35 PM, Dmitry Torokhov wrote: > > Hi Hans, > > > > On Thu, Apr 17, 2014 at 01:41:43PM +0200, Hans de Goede wrote: > >> We expect that all the Haswell series will need such quirks, sigh. > > > > Given this statement do we really want this to be handled in kernel? > > I know this answer won't make you happy, but short term: Yes, we are > getting many many bugreports about this, ie: > > https://bugzilla.redhat.com/show_bug.cgi?id=1060885 > https://bugzilla.redhat.com/show_bug.cgi?id=1068716 > https://bugzilla.redhat.com/show_bug.cgi?id=1085582 > https://bugzilla.redhat.com/show_bug.cgi?id=1085697 > https://bugzilla.redhat.com/show_bug.cgi?id=1086227 > > And by extending the *already present* quirk table we can get this > issue resolved quickly, and also resolve it for people running > older kernels through the various stable series. > > > Maybe we simply want udev to fix up the limits with EVIOSABS(), > > Ah, I did not know that it is possible to fixup the min/max values > from user space, that is good to know. > > > similarly to how we adjust keymaps for laptops? > > We're currently looking into various ways to make this less painful, > specifically for most laptops the problem seems to be the min value > and not the max value. And the troublesome min value is the synaptics > driver default, not the one we get from the firmware. The problem is > we never ask the firmware because even though it has the "I can report > min values" capability bit, its "maximum understood request" number > is too low, so one of our 2 checks for getting the min value is > failing. If we remove that check some models do give us a proper > range (but not all, ie the T440s is still wrong). > > We're currently trying to figure out if it will be safe for all models > to remove the "maximum understood request" number check. That should ie > remove the quirk for the x240 and possible others. > > An other option to make this better is to switch the quirks to using > pnp-ids, ie the L440 and L540 share the same pnp-id. Once you've > merged the firmware_id patches I can take a shot at simplifying the > quirk table that way. Downside is that we then probably need to > put the firmware_id patches in the various stable kernels. > > Note that even if we end up moving this to userspace, then we still > need the firmware_id, because I believe any userspace solution should > be using pnp-ids too. > > TL;DR: It is complicated and for now we would like to continue with > the quirks as we've done sofar. We are aware that this is undesirable > from a maintenance pov and are looking into making this better. OK, fair enough. I applied the patch. Thanks.
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index a8b57d7..7c9f509 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -1566,6 +1566,14 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = { .driver_data = (int []){1232, 5710, 1156, 4696}, }, { + /* Lenovo ThinkPad T431s */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T431"), + }, + .driver_data = (int []){1024, 5112, 2024, 4832}, + }, + { /* Lenovo ThinkPad T440s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), @@ -1574,6 +1582,14 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = { .driver_data = (int []){1024, 5112, 2024, 4832}, }, { + /* Lenovo ThinkPad L440 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L440"), + }, + .driver_data = (int []){1024, 5112, 2024, 4832}, + }, + { /* Lenovo ThinkPad T540p */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), @@ -1581,6 +1597,32 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = { }, .driver_data = (int []){1024, 5056, 2058, 4832}, }, + { + /* Lenovo ThinkPad L540 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L540"), + }, + .driver_data = (int []){1024, 5112, 2024, 4832}, + }, + { + /* Lenovo Yoga S1 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, + "ThinkPad S1 Yoga"), + }, + .driver_data = (int []){1232, 5710, 1156, 4696}, + }, + { + /* Lenovo ThinkPad X1 Carbon Haswell (3rd generation) */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, + "ThinkPad X1 Carbon 2nd"), + }, + .driver_data = (int []){1024, 5112, 2024, 4832}, + }, #endif { } };