2:59 a.m.
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
2:59 a.m.
New subject: [PATCH v2 1/4] Input: serio - add firmware_id sysfs attribute
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(a)redhat.com>
Acked-by: Peter Hutterer <peter.hutterer(a)who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)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;
--
1.9.0
2:59 a.m.
New subject: [PATCH v2 2/4] Input: i8042 - add firmware_id support
Fill in the new serio firmware_id sysfs attribute for pnp instantiated
8042 serio ports.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Acked-by: Peter Hutterer <peter.hutterer(a)who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)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);
--
1.9.0
2:59 a.m.
New subject: [PATCH v2 3/4] Input: Add INPUT_PROP_TOPBUTTONPAD device property
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(a)redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)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)
--
1.9.0
2:59 a.m.
New subject: [PATCH v2 4/4] Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property
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(a)redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)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
--
1.9.0
6:26 a.m.
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
6:39 a.m.
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.
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.
Ok, I'll just wait for them to go into Fedora through the stable series
then.
Regards,
Hans
6:52 a.m.
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.
>
> 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.
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
3639
days inactive
3639
days old
kernel@lists.fedoraproject.org
7 comments
2 participants
participants (2)
-
Hans de Goede -
Josh Boyer