Hi All,
Now that INPUT_PROP_TOPBUTTONPAD has landed in Linus' tree, upstream xorg-x11-drv-synaptics is relying on it as the one and only way to identify clickpads with top buttons (as found on all new lenovo laptops).
Currently in Fedora we have a set of udev rules, which need to be expanded for each new model, instead of using INPUT_PROP_TOPBUTTONPAD.
Now that yet another Lenovo model has surfaced with this type of touchpad: https://bugzilla.redhat.com/show_bug.cgi?id=1096436
I would like to move Fedora to the solution upstream is using. The first step for this would be to add these 4 patches to the Fedora kernels. I've also send them to stable, and Dmitry Torokhov and Greg KH are both ok with them going into stable. But Greg has a bit of a backlog atm.
For now I'll just extend the udev rules in xorg-x11-drv-synaptics for this one more model, since otherwise things will break for people not using the very latest Fedora kernel. Once these changes have been in Fedora kernels for a while I plan to rebase xorg-x11-drv-synaptics to the latest upstream, making it rely on INPUT_PROP_TOPBUTTONPAD and avoiding the need to update it for each new laptop model with such a touchpad.
Regards,
Hans
serio devices exposed via platform firmware interfaces such as ACPI may provide additional identifying information of use to userspace.
We don't associate the serio devices with the firmware device (we don't set it as parent), so there's no way for userspace to make use of this information.
We cannot change the parent for serio devices instantiated though a firmware interface as that would break suspend / resume ordering.
Therefore this patch adds a new firmware_id sysfs attribute so that userspace can get a string from there with any additional identifying information the firmware interface may provide.
Signed-off-by: Hans de Goede hdegoede@redhat.com Acked-by: Peter Hutterer peter.hutterer@who-t.net Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com --- drivers/input/serio/serio.c | 14 ++++++++++++++ include/linux/serio.h | 1 + 2 files changed, 15 insertions(+)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c index 8f4c4ab..b29134d 100644 --- a/drivers/input/serio/serio.c +++ b/drivers/input/serio/serio.c @@ -451,6 +451,13 @@ static ssize_t serio_set_bind_mode(struct device *dev, struct device_attribute * return retval; }
+static ssize_t firmware_id_show(struct device *dev, struct device_attribute *attr, char *buf) +{ + struct serio *serio = to_serio_port(dev); + + return sprintf(buf, "%s\n", serio->firmware_id); +} + static DEVICE_ATTR_RO(type); static DEVICE_ATTR_RO(proto); static DEVICE_ATTR_RO(id); @@ -473,12 +480,14 @@ static DEVICE_ATTR_RO(modalias); static DEVICE_ATTR_WO(drvctl); static DEVICE_ATTR(description, S_IRUGO, serio_show_description, NULL); static DEVICE_ATTR(bind_mode, S_IWUSR | S_IRUGO, serio_show_bind_mode, serio_set_bind_mode); +static DEVICE_ATTR_RO(firmware_id);
static struct attribute *serio_device_attrs[] = { &dev_attr_modalias.attr, &dev_attr_description.attr, &dev_attr_drvctl.attr, &dev_attr_bind_mode.attr, + &dev_attr_firmware_id.attr, NULL };
@@ -921,9 +930,14 @@ static int serio_uevent(struct device *dev, struct kobj_uevent_env *env) SERIO_ADD_UEVENT_VAR("SERIO_PROTO=%02x", serio->id.proto); SERIO_ADD_UEVENT_VAR("SERIO_ID=%02x", serio->id.id); SERIO_ADD_UEVENT_VAR("SERIO_EXTRA=%02x", serio->id.extra); + SERIO_ADD_UEVENT_VAR("MODALIAS=serio:ty%02Xpr%02Xid%02Xex%02X", serio->id.type, serio->id.proto, serio->id.id, serio->id.extra);
+ if (serio->firmware_id[0]) + SERIO_ADD_UEVENT_VAR("SERIO_FIRMWARE_ID=%s", + serio->firmware_id); + return 0; } #undef SERIO_ADD_UEVENT_VAR diff --git a/include/linux/serio.h b/include/linux/serio.h index 36aac73..9f779c7 100644 --- a/include/linux/serio.h +++ b/include/linux/serio.h @@ -23,6 +23,7 @@ struct serio {
char name[32]; char phys[32]; + char firmware_id[128];
bool manual_bind;
Fill in the new serio firmware_id sysfs attribute for pnp instantiated 8042 serio ports.
Signed-off-by: Hans de Goede hdegoede@redhat.com Acked-by: Peter Hutterer peter.hutterer@who-t.net Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com --- drivers/input/serio/i8042-x86ia64io.h | 15 +++++++++++++++ drivers/input/serio/i8042.c | 6 ++++++ 2 files changed, 21 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h index 0ec9abb..381b20d 100644 --- a/drivers/input/serio/i8042-x86ia64io.h +++ b/drivers/input/serio/i8042-x86ia64io.h @@ -702,6 +702,17 @@ static int i8042_pnp_aux_irq; static char i8042_pnp_kbd_name[32]; static char i8042_pnp_aux_name[32];
+static void i8042_pnp_id_to_string(struct pnp_id *id, char *dst, int dst_size) +{ + strlcpy(dst, "PNP:", dst_size); + + while (id) { + strlcat(dst, " ", dst_size); + strlcat(dst, id->id, dst_size); + id = id->next; + } +} + static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id *did) { if (pnp_port_valid(dev, 0) && pnp_port_len(dev, 0) == 1) @@ -718,6 +729,8 @@ static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id * strlcat(i8042_pnp_kbd_name, ":", sizeof(i8042_pnp_kbd_name)); strlcat(i8042_pnp_kbd_name, pnp_dev_name(dev), sizeof(i8042_pnp_kbd_name)); } + i8042_pnp_id_to_string(dev->id, i8042_kbd_firmware_id, + sizeof(i8042_kbd_firmware_id));
/* Keyboard ports are always supposed to be wakeup-enabled */ device_set_wakeup_enable(&dev->dev, true); @@ -742,6 +755,8 @@ static int i8042_pnp_aux_probe(struct pnp_dev *dev, const struct pnp_device_id * strlcat(i8042_pnp_aux_name, ":", sizeof(i8042_pnp_aux_name)); strlcat(i8042_pnp_aux_name, pnp_dev_name(dev), sizeof(i8042_pnp_aux_name)); } + i8042_pnp_id_to_string(dev->id, i8042_aux_firmware_id, + sizeof(i8042_aux_firmware_id));
i8042_pnp_aux_devices++; return 0; diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c index 020053f..3807c3e 100644 --- a/drivers/input/serio/i8042.c +++ b/drivers/input/serio/i8042.c @@ -87,6 +87,8 @@ MODULE_PARM_DESC(debug, "Turn i8042 debugging mode on and off"); #endif
static bool i8042_bypass_aux_irq_test; +static char i8042_kbd_firmware_id[128]; +static char i8042_aux_firmware_id[128];
#include "i8042.h"
@@ -1218,6 +1220,8 @@ static int __init i8042_create_kbd_port(void) serio->dev.parent = &i8042_platform_device->dev; strlcpy(serio->name, "i8042 KBD port", sizeof(serio->name)); strlcpy(serio->phys, I8042_KBD_PHYS_DESC, sizeof(serio->phys)); + strlcpy(serio->firmware_id, i8042_kbd_firmware_id, + sizeof(serio->firmware_id));
port->serio = serio; port->irq = I8042_KBD_IRQ; @@ -1244,6 +1248,8 @@ static int __init i8042_create_aux_port(int idx) if (idx < 0) { strlcpy(serio->name, "i8042 AUX port", sizeof(serio->name)); strlcpy(serio->phys, I8042_AUX_PHYS_DESC, sizeof(serio->phys)); + strlcpy(serio->firmware_id, i8042_aux_firmware_id, + sizeof(serio->firmware_id)); serio->close = i8042_port_close; } else { snprintf(serio->name, sizeof(serio->name), "i8042 AUX%d port", idx);
On some newer laptops with a trackpoint the physical buttons for the trackpoint have been removed to allow for a larger touchpad. On these laptops the buttonpad has clearly marked areas on the top which are to be used as trackpad buttons.
Users of the event device-node need to know about this, so that they can properly interpret BTN_LEFT events as being a left / right / middle click depending on where on the button pad the clicking finger is.
This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers for such buttonpads will use to signal to the user that this buttonpad not only has the normal bottom button area, but also a top button area.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com --- include/uapi/linux/input.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index bd24470..f484952 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -164,6 +164,7 @@ struct input_keymap_entry { #define INPUT_PROP_DIRECT 0x01 /* direct input devices */ #define INPUT_PROP_BUTTONPAD 0x02 /* has button(s) under pad */ #define INPUT_PROP_SEMI_MT 0x03 /* touch rectangle only */ +#define INPUT_PROP_TOPBUTTONPAD 0x04 /* softbuttons at top of pad */
#define INPUT_PROP_MAX 0x1f #define INPUT_PROP_CNT (INPUT_PROP_MAX + 1)
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com --- drivers/input/mouse/synaptics.c | 55 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index d8d49d1..9d75410 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -117,6 +117,44 @@ void synaptics_reset(struct psmouse *psmouse) }
#ifdef CONFIG_MOUSE_PS2_SYNAPTICS +/* This list has been kindly provided by Synaptics. */ +static const char * const topbuttonpad_pnp_ids[] = { + "LEN0017", + "LEN0018", + "LEN0019", + "LEN0023", + "LEN002A", + "LEN002B", + "LEN002C", + "LEN002D", + "LEN002E", + "LEN0033", /* Helix */ + "LEN0034", /* T431s, T540, X1 Carbon 2nd */ + "LEN0035", /* X240 */ + "LEN0036", /* T440 */ + "LEN0037", + "LEN0038", + "LEN0041", + "LEN0042", /* Yoga */ + "LEN0045", + "LEN0046", + "LEN0047", + "LEN0048", + "LEN0049", + "LEN2000", + "LEN2001", + "LEN2002", + "LEN2003", + "LEN2004", /* L440 */ + "LEN2005", + "LEN2006", + "LEN2007", + "LEN2008", + "LEN2009", + "LEN200A", + "LEN200B", + NULL +};
/***************************************************************************** * Synaptics communications functions @@ -1255,8 +1293,10 @@ static void set_abs_position_params(struct input_dev *dev, input_abs_set_res(dev, y_code, priv->y_res); }
-static void set_input_params(struct input_dev *dev, struct synaptics_data *priv) +static void set_input_params(struct psmouse *psmouse, + struct synaptics_data *priv) { + struct input_dev *dev = psmouse->dev; int i;
/* Things that apply to both modes */ @@ -1325,6 +1365,17 @@ static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) { __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit); + /* See if this buttonpad has a top button area */ + if (!strncmp(psmouse->ps2dev.serio->firmware_id, "PNP:", 4)) { + for (i = 0; topbuttonpad_pnp_ids[i]; i++) { + if (strstr(psmouse->ps2dev.serio->firmware_id, + topbuttonpad_pnp_ids[i])) { + __set_bit(INPUT_PROP_TOPBUTTONPAD, + dev->propbit); + break; + } + } + } /* Clickpads report only left button */ __clear_bit(BTN_RIGHT, dev->keybit); __clear_bit(BTN_MIDDLE, dev->keybit); @@ -1593,7 +1644,7 @@ static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode) priv->capabilities, priv->ext_cap, priv->ext_cap_0c, priv->board_id, priv->firmware_id);
- set_input_params(psmouse->dev, priv); + set_input_params(psmouse, priv);
/* * Encode touchpad model so that it can be used to set
On Sat, May 10, 2014 at 09:59:29AM +0200, Hans de Goede wrote:
Hi All,
Now that INPUT_PROP_TOPBUTTONPAD has landed in Linus' tree, upstream xorg-x11-drv-synaptics is relying on it as the one and only way to identify clickpads with top buttons (as found on all new lenovo laptops).
Currently in Fedora we have a set of udev rules, which need to be expanded for each new model, instead of using INPUT_PROP_TOPBUTTONPAD.
Now that yet another Lenovo model has surfaced with this type of touchpad: https://bugzilla.redhat.com/show_bug.cgi?id=1096436
I would like to move Fedora to the solution upstream is using. The first step for this would be to add these 4 patches to the Fedora kernels. I've also send them to stable, and Dmitry Torokhov and Greg KH are both ok with them going into stable. But Greg has a bit of a backlog atm.
They're already in rawhide, so I'm guessing you mean F20.
For now I'll just extend the udev rules in xorg-x11-drv-synaptics for this one more model, since otherwise things will break for people not using the very latest Fedora kernel. Once these changes have been in Fedora kernels for a while I plan to rebase xorg-x11-drv-synaptics to the latest upstream, making it rely on INPUT_PROP_TOPBUTTONPAD and avoiding the need to update it for each new laptop model with such a touchpad.
I have no problems with the patches themselves, and I like the overall plan, but adding them as patches right now seems pointless.
1) They're already in rawhide
2) They'll be in 3.14.y in a matter of weeks, if not sooner, which means they'll be in F20 and F19 within that timeframe.
3) You already have to extend the udev rules anyway for the existing bugs.
4) Even if they are added, by the time a kernel that contains them is built and in updates-stable the patches will likely already be in upstream stable. Fedora kernel builds for stable releases are essentially tied to the upstream stable release cycle, barring any major bug or CVE fix. So if these land in 3.14.4 upstream, then that will already be as "fast" as I would expect. If they land in 3.14.5, it's an extra week.
Unless I'm missing something, it seems like extra busy work to add them as patches right now. Waiting for an upstream stable release should accomplish everything you want without too much additional delay. If they don't hit upstream stable at all for some reason, then it might make more sense to add them to 3.14.y in Fedora.
josh
Hi,
On 05/10/2014 01:26 PM, Josh Boyer wrote:
On Sat, May 10, 2014 at 09:59:29AM +0200, Hans de Goede wrote:
Hi All,
Now that INPUT_PROP_TOPBUTTONPAD has landed in Linus' tree, upstream xorg-x11-drv-synaptics is relying on it as the one and only way to identify clickpads with top buttons (as found on all new lenovo laptops).
Currently in Fedora we have a set of udev rules, which need to be expanded for each new model, instead of using INPUT_PROP_TOPBUTTONPAD.
Now that yet another Lenovo model has surfaced with this type of touchpad: https://bugzilla.redhat.com/show_bug.cgi?id=1096436
I would like to move Fedora to the solution upstream is using. The first step for this would be to add these 4 patches to the Fedora kernels. I've also send them to stable, and Dmitry Torokhov and Greg KH are both ok with them going into stable. But Greg has a bit of a backlog atm.
They're already in rawhide, so I'm guessing you mean F20.
Yes.
For now I'll just extend the udev rules in xorg-x11-drv-synaptics for this one more model, since otherwise things will break for people not using the very latest Fedora kernel. Once these changes have been in Fedora kernels for a while I plan to rebase xorg-x11-drv-synaptics to the latest upstream, making it rely on INPUT_PROP_TOPBUTTONPAD and avoiding the need to update it for each new laptop model with such a touchpad.
I have no problems with the patches themselves, and I like the overall plan, but adding them as patches right now seems pointless.
They're already in rawhide
They'll be in 3.14.y in a matter of weeks, if not sooner, which means
they'll be in F20 and F19 within that timeframe.
- You already have to extend the udev rules anyway for the existing
bugs.
- Even if they are added, by the time a kernel that contains them is
built and in updates-stable the patches will likely already be in upstream stable. Fedora kernel builds for stable releases are essentially tied to the upstream stable release cycle, barring any major bug or CVE fix. So if these land in 3.14.4 upstream, then that will already be as "fast" as I would expect. If they land in 3.14.5, it's an extra week.
Unless I'm missing something, it seems like extra busy work to add them as patches right now. Waiting for an upstream stable release should accomplish everything you want without too much additional delay. If they don't hit upstream stable at all for some reason, then it might make more sense to add them to 3.14.y in Fedora.
Ok, I'll just wait for them to go into Fedora through the stable series then.
Regards,
Hans
On Sat, May 10, 2014 at 01:39:24PM +0200, Hans de Goede wrote:
Hi,
On 05/10/2014 01:26 PM, Josh Boyer wrote:
On Sat, May 10, 2014 at 09:59:29AM +0200, Hans de Goede wrote:
Hi All,
Now that INPUT_PROP_TOPBUTTONPAD has landed in Linus' tree, upstream xorg-x11-drv-synaptics is relying on it as the one and only way to identify clickpads with top buttons (as found on all new lenovo laptops).
Currently in Fedora we have a set of udev rules, which need to be expanded for each new model, instead of using INPUT_PROP_TOPBUTTONPAD.
Now that yet another Lenovo model has surfaced with this type of touchpad: https://bugzilla.redhat.com/show_bug.cgi?id=1096436
I would like to move Fedora to the solution upstream is using. The first step for this would be to add these 4 patches to the Fedora kernels. I've also send them to stable, and Dmitry Torokhov and Greg KH are both ok with them going into stable. But Greg has a bit of a backlog atm.
They're already in rawhide, so I'm guessing you mean F20.
Yes.
For now I'll just extend the udev rules in xorg-x11-drv-synaptics for this one more model, since otherwise things will break for people not using the very latest Fedora kernel. Once these changes have been in Fedora kernels for a while I plan to rebase xorg-x11-drv-synaptics to the latest upstream, making it rely on INPUT_PROP_TOPBUTTONPAD and avoiding the need to update it for each new laptop model with such a touchpad.
I have no problems with the patches themselves, and I like the overall plan, but adding them as patches right now seems pointless.
They're already in rawhide
They'll be in 3.14.y in a matter of weeks, if not sooner, which means
they'll be in F20 and F19 within that timeframe.
- You already have to extend the udev rules anyway for the existing
bugs.
- Even if they are added, by the time a kernel that contains them is
built and in updates-stable the patches will likely already be in upstream stable. Fedora kernel builds for stable releases are essentially tied to the upstream stable release cycle, barring any major bug or CVE fix. So if these land in 3.14.4 upstream, then that will already be as "fast" as I would expect. If they land in 3.14.5, it's an extra week.
Unless I'm missing something, it seems like extra busy work to add them as patches right now. Waiting for an upstream stable release should accomplish everything you want without too much additional delay. If they don't hit upstream stable at all for some reason, then it might make more sense to add them to 3.14.y in Fedora.
Ok, I'll just wait for them to go into Fedora through the stable series then.
Ok. I'll keep an eye on upstream stable and if they don't land in the next release or two we can revisit. Thanks for the work on this and the video issues. Much appreciated.
josh
kernel@lists.fedoraproject.org
-
Hans de Goede -
Josh Boyer