Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

On May 20 2017 or thereabouts, Dmitry Torokhov wrote: > On Sat, May 20, 2017 at 11:59:50AM +0200, Benjamin Tissoires wrote: > > Hi, > > > > On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > > > Looks like you running your p

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

On May 20 2017 or thereabouts, Dmitry Torokhov wrote: > On Sat, May 20, 2017 at 11:59:50AM +0200, Benjamin Tissoires wrote: > > Hi, > > > > On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > > > Looks like you running your p

Re: [PATCH 1/1] hid: i2c-hid: move header file out of I2C realm

On May 21 2017 or thereabouts, Wolfram Sang wrote: > include/linux/i2c is not for client devices. Move the header file to a > more appropriate location. > > Signed-off-by: Wolfram Sang <w...@the-dreams.de> > --- Acked-by: Benjamin Tissoires <benjamin.tissoi...@redha

Re: [PATCH 1/1] hid: i2c-hid: move header file out of I2C realm

On May 21 2017 or thereabouts, Wolfram Sang wrote: > include/linux/i2c is not for client devices. Move the header file to a > more appropriate location. > > Signed-off-by: Wolfram Sang > --- Acked-by: Benjamin Tissoires Cheers, Benjamin > drivers/hid/i2c-hid/i2c-hid.c

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

Hi, On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > Looks like you running your patched kernel? > That's right. > > > >>> CONFIG_RMI4_CORE=m > >>> CONFIG_RMI4_I2C=m > >>> CONFIG_RMI4_SPI=m > >>> # CONFIG_RMI4_SMB is not set > > > > This is your issue I believe. > > Indeed, enabling

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

Hi, On May 20 2017 or thereabouts, Pascal Wichmann wrote: > > Looks like you running your patched kernel? > That's right. > > > >>> CONFIG_RMI4_CORE=m > >>> CONFIG_RMI4_I2C=m > >>> CONFIG_RMI4_SPI=m > >>> # CONFIG_RMI4_SMB is not set > > > > This is your issue I believe. > > Indeed, enabling

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi Lv, [thank you Peter for jumping in the thread] Just a few precisions regarding questions you asked: On May 17 2017 or thereabouts, Zheng, Lv wrote: [stripped] > > [User space tools] *are* correct. > > They are following the exported ACPI documentation > > I doubt. In ACPI world, Windows is

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi Lv, [thank you Peter for jumping in the thread] Just a few precisions regarding questions you asked: On May 17 2017 or thereabouts, Zheng, Lv wrote: [stripped] > > [User space tools] *are* correct. > > They are following the exported ACPI documentation > > I doubt. In ACPI world, Windows is

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 16 2017 or thereabouts, Zheng, Lv wrote: > Hi, Benjamin > > > > > > > >> >> > > > > For example, such a hwdb entry is: > > > > > > >> >> > > > > libinput:name:*Lid > > > > > > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > > > >> >> > > > >

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 16 2017 or thereabouts, Zheng, Lv wrote: > Hi, Benjamin > > > > > > > >> >> > > > > For example, such a hwdb entry is: > > > > > > >> >> > > > > libinput:name:*Lid > > > > > > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > > > >> >> > > > >

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

t; lid_init_state=open" > > > > Hi, Guys > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior > > > to lid_init_state=open" > &g

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

t; lid_init_state=open" > > > > Hi, Guys > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior > > > to lid_init_state=open" > &g

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires > <benjamin.tissoi...@redhat.com> wrote: > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tiss

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires > wrote: > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires > >> wrote: > >> &g

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires > <benjamin.tissoi...@redhat.com> wrote: > > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > >> On Friday, May 12, 2017 02:36:20 AM

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires > wrote: > > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > >> > Hi, > &g

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > > Hi, > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change def

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > > Hi, > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change def

Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

. If a user buys a new machine and the LID switch doesn't work as expected, it's not a regression, it's a bug. Regression is something we absolutely need to avoid, and switching to button.lid_init_state=open introduced far too many regressions on systems. > > > From: Benjamin Tissoires [mailto:b

Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

. If a user buys a new machine and the LID switch doesn't work as expected, it's not a regression, it's a bug. Regression is something we absolutely need to avoid, and switching to button.lid_init_state=open introduced far too many regressions on systems. > > > From: Benjamin Tissoires [mailto:b

Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

On May 12 2017 or thereabouts, Zheng, Lv wrote: > Hi, > > > From: linux-acpi-ow...@vger.kernel.org > > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin > > Tissoires > > Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove > > lid_i

Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

On May 12 2017 or thereabouts, Zheng, Lv wrote: > Hi, > > > From: linux-acpi-ow...@vger.kernel.org > > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin > > Tissoires > > Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove > > lid_i

Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

state=method mode" > > > > Hi, Benjiamin > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Sent: Thursday, May 11, 2017 12:13 AM > > > To: Rafael J . Wysocki <r...@rjwysocki.net>; Zheng, Lv > > > <

Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

state=method mode" > > > > Hi, Benjiamin > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > > Sent: Thursday, May 11, 2017 12:13 AM > > > To: Rafael J . Wysocki ; Zheng, Lv > > > > > > Cc: Jiri Eischm

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 11 2017 or thereabouts, Zheng, Lv wrote: > Hi, > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > > lid_init_state=open" > > > > This reverts c

Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On May 11 2017 or thereabouts, Zheng, Lv wrote: > Hi, > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > > lid_init_state=open" > > > > This reverts c

Re: [PATCH 0/2] acpi/button: revert v4.10 behavior

Hi Rafael, On May 11 2017 or thereabouts, Rafael J. Wysocki wrote: > On Wed, May 10, 2017 at 6:12 PM, Benjamin Tissoires > <benjamin.tissoi...@redhat.com> wrote: > > The new default 'open' behavior for acpi_lid_initialize_state() is just > > wrong. It breaks professiona

Re: [PATCH 0/2] acpi/button: revert v4.10 behavior

Hi Rafael, On May 11 2017 or thereabouts, Rafael J. Wysocki wrote: > On Wed, May 10, 2017 at 6:12 PM, Benjamin Tissoires > wrote: > > The new default 'open' behavior for acpi_lid_initialize_state() is just > > wrong. It breaks professional laptops with a docking station [1

[PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

deprecated, which is terrible in term of distribution handling. The new default "open" is plain wrong and we don't even have the chance to keep the current default option because it's not there anymore. Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoi.

[PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

deprecated, which is terrible in term of distribution handling. The new default "open" is plain wrong and we don't even have the chance to keep the current default option because it's not there anymore. Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires --- Documentation

[PATCH 0/2] acpi/button: revert v4.10 behavior

-space solution as described in 2/2 if you really don't want to add quirks in the kernel. Cheers, Benjamin [1] https://bugzilla.gnome.org/show_bug.cgi?id=782380 Benjamin Tissoires (2): Revert "ACPI / button: Remove lid_init_state=method mode" Revert "ACPI / button: Change d

[PATCH 0/2] acpi/button: revert v4.10 behavior

-space solution as described in 2/2 if you really don't want to add quirks in the kernel. Cheers, Benjamin [1] https://bugzilla.gnome.org/show_bug.cgi?id=782380 Benjamin Tissoires (2): Revert "ACPI / button: Remove lid_init_state=method mode" Revert "ACPI / button: Change d

[PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

pnSurface3:* LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open Link: https://bugzilla.gnome.org/show_bug.cgi?id=782380 Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- drivers/acpi/button.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --gi

[PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

pnSurface3:* LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open Link: https://bugzilla.gnome.org/show_bug.cgi?id=782380 Cc: sta...@vger.kernel.org Signed-off-by: Benjamin Tissoires --- drivers/acpi/button.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/button.c b/drivers/acp

Re: [PATCH v1] ACPI: Switch to use generic UUID API

: Borislav Petkov <b...@suse.de> > Cc: Dan Williams <dan.j.willi...@intel.com> > Cc: Amir Goldstein <amir7...@gmail.com> > Cc: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: Ben Skeggs <

Re: [PATCH v1] ACPI: Switch to use generic UUID API

gt; Cc: Jarkko Sakkinen > Cc: Jani Nikula > Cc: Ben Skeggs > Cc: Benjamin Tissoires > Cc: Joerg Roedel > Cc: Adrian Hunter > Cc: Yisen Zhuang > Cc: Bjorn Helgaas > Cc: Zhang Rui > Cc: Felipe Balbi > Cc: Mathias Nyman > Cc: Heikki Krogerus > Cc: L

Re: [PATCH 1/2] Alps HID I2C T4 device support

Hi, I have this review in my inbox for a while, but couldn't find the time to finish it earlier. Sorry about that. On Mar 30 2017 or thereabouts, Masaki Ota wrote: > From Masaki Ota > > -Support Alps HID I2C T4 Touchpad device. > -Laptop names that use this Touchpad:HP

Re: [PATCH 1/2] Alps HID I2C T4 device support

Hi, I have this review in my inbox for a while, but couldn't find the time to finish it earlier. Sorry about that. On Mar 30 2017 or thereabouts, Masaki Ota wrote: > From Masaki Ota > > -Support Alps HID I2C T4 Touchpad device. > -Laptop names that use this Touchpad:HP Zbook Studio, Elitebook

Re: [PATCH] Revert "HID: rmi: Handle all Synaptics touchpads using hid-rmi"

m> > Reported-by: Gabriele Mazzotta <gabriele@gmail.com> > Reported-by: Lorenzo J. Lucchini <ljl...@tiscali.it> > Reported-by: Thorsten Leemhuis <li...@leemhuis.info> > Signed-off-by: Jiri Kosina <jkos...@suse.cz> > --- Acked-by: Benjamin Tissoires <ben

Re: [PATCH] Revert "HID: rmi: Handle all Synaptics touchpads using hid-rmi"

ported-by: Lorenzo J. Lucchini > Reported-by: Thorsten Leemhuis > Signed-off-by: Jiri Kosina > --- Acked-by: Benjamin Tissoires Cheers, Benjamin > drivers/hid/hid-core.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/hid/hid-core.c b/d

Re: [PATCH v3] HID: asus: support backlight on USB keyboards

; + GFP_KERNEL); > + if (!drvdata->kbd_backlight) > + return -ENOMEM; > + > + drvdata->kbd_backlight->removed = false; > + drvdata->kbd_backlight->brightness = 0; > + drvdata->kbd_backlight->h

Re: [PATCH v3] HID: asus: support backlight on USB keyboards

; + if (!drvdata->kbd_backlight) > + return -ENOMEM; > + > + drvdata->kbd_backlight->removed = false; > + drvdata->kbd_backlight->brightness = 0; > + drvdata->kbd_backlight->hdev = hdev; > + drvdata->kbd_backlight->cdev.n

Re: [PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery

On Apr 06 2017 or thereabouts, Jiri Kosina wrote: > On Mon, 27 Mar 2017, Benjamin Tissoires wrote: > > > From: Bastien Nocera <had...@hadess.net> > > > > Without a scope defined, UPower assumes that the battery provides > > power to the computer it's connecte

Re: [PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery

On Apr 06 2017 or thereabouts, Jiri Kosina wrote: > On Mon, 27 Mar 2017, Benjamin Tissoires wrote: > > > From: Bastien Nocera > > > > Without a scope defined, UPower assumes that the battery provides > > power to the computer it's connected to, like a laptop bat

Re: [PATCH v2] HID: asus: support backlight on USB keyboards

Hi Carlo, On Apr 05 2017 or thereabouts, Carlo Caione wrote: > From: Carlo Caione > > The latest USB keyboards shipped on several ASUS laptop models > (including ROG laptop models such as GL702VMK) have the keyboards > backlight controlled by the keyboard firmware. > > The

Re: [PATCH v2] HID: asus: support backlight on USB keyboards

Hi Carlo, On Apr 05 2017 or thereabouts, Carlo Caione wrote: > From: Carlo Caione > > The latest USB keyboards shipped on several ASUS laptop models > (including ROG laptop models such as GL702VMK) have the keyboards > backlight controlled by the keyboard firmware. > > The firmware implements

Re: [PATCH] HID: asus: support backlight on USB keyboards

On Apr 05 2017 or thereabouts, Carlo Caione wrote: > On Wed, Apr 5, 2017 at 11:41 AM, Benjamin Tissoires > <benjamin.tissoi...@redhat.com> wrote: > > Hi Carlo, > > [cut] > >> With this patch we create the usual 'asus::kbd_backlight' sysfs entry > > &g

Re: [PATCH] HID: asus: support backlight on USB keyboards

On Apr 05 2017 or thereabouts, Carlo Caione wrote: > On Wed, Apr 5, 2017 at 11:41 AM, Benjamin Tissoires > wrote: > > Hi Carlo, > > [cut] > >> With this patch we create the usual 'asus::kbd_backlight' sysfs entry > > > > Please change 'sysfs' with

Re: [PATCH] HID: asus: support backlight on USB keyboards

Hi Carlo, On Apr 04 2017 or thereabouts, Carlo Caione wrote: > From: Carlo Caione > > The latest USB keyboards shipped on several ASUS laptop models > (including ROG laptop models such as GL702VMK) have the keyboards > backlight controlled by the keyboard firmware. > > The

Re: [PATCH] HID: asus: support backlight on USB keyboards

Hi Carlo, On Apr 04 2017 or thereabouts, Carlo Caione wrote: > From: Carlo Caione > > The latest USB keyboards shipped on several ASUS laptop models > (including ROG laptop models such as GL702VMK) have the keyboards > backlight controlled by the keyboard firmware. > > The firmware implements

Re: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

Hi Dmitry, On Apr 03 2017 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Mon, Apr 03, 2017 at 06:18:21PM +0200, Benjamin Tissoires wrote: > > The IRQ from rmi4 may interfere with the one we currently use on i2c-hid. > > Given that there is already a need for

Re: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

Hi Dmitry, On Apr 03 2017 or thereabouts, Dmitry Torokhov wrote: > Hi Benjamin, > > On Mon, Apr 03, 2017 at 06:18:21PM +0200, Benjamin Tissoires wrote: > > The IRQ from rmi4 may interfere with the one we currently use on i2c-hid. > > Given that there is already a need for

[PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

man...@gmail.com> Reported-by: Thorsten Leemhuis <li...@leemhuis.info> Reported-by: Jason Ekstrand <ja...@jlekstrand.net> Tested-by: Andrew Duggan <adug...@synaptics.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- Hi Dmitry, Jiri, This is a re

[PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

-by: Thorsten Leemhuis Reported-by: Jason Ekstrand Tested-by: Andrew Duggan Signed-off-by: Benjamin Tissoires --- Hi Dmitry, Jiri, This is a regression introduced by my code in v4.11. I do not think it is worth splitting between HID and input, there hasn't been any development in hid-rmi since

Re: [PATCH] Input: psmouse - fix cleaning up SMBus companions

"Input: psmouse - add support for SMBus companions") > Reported-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> > Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com> > --- Thanks for the fix! Tested-by: Benjamin Tissoires <benjamin.tissoi...@redh

Re: [PATCH] Input: psmouse - fix cleaning up SMBus companions

"Input: psmouse - add support for SMBus companions") > Reported-by: Benjamin Tissoires > Signed-off-by: Dmitry Torokhov > --- Thanks for the fix! Tested-by: Benjamin Tissoires Cheers, Benjamin > drivers/input/mouse/psmouse-smbus.c | 30 +++--- &g

Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

On Apr 01 2017 or thereabouts, Dmitry Torokhov wrote: > On Fri, Mar 31, 2017 at 11:37:05AM +0200, Benjamin Tissoires wrote: > > Hi Dmitry, > > > > On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > > > From: Benjamin Tissoires <benjamin.tissoi...@redhat.com

Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

On Apr 01 2017 or thereabouts, Dmitry Torokhov wrote: > On Fri, Mar 31, 2017 at 11:37:05AM +0200, Benjamin Tissoires wrote: > > Hi Dmitry, > > > > On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > > > From: Benjamin Tissoires > > > > &

Re: [PATCH 4/4] Input: synaptics - use u8 instead of unsigned char

> --- The series looks good to me: Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Cheers, Benjamin > drivers/input/mouse/synaptics.c | 60 > - > drivers/input/mouse/synaptics.h | 22 --- > 2 files changed

Re: [PATCH 4/4] Input: synaptics - use u8 instead of unsigned char

good to me: Reviewed-by: Benjamin Tissoires Cheers, Benjamin > drivers/input/mouse/synaptics.c | 60 > - > drivers/input/mouse/synaptics.h | 22 --- > 2 files changed, 42 insertions(+), 40 deletions(-) > > diff --git a/drivers/input/

Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

Hi Dmitry, On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > From: Benjamin Tissoires <benjamin.tissoi...@redhat.com> > > This provides glue between PS/2 devices that enumerate the RMI4 devices > and Elan touchpads to the RMI4 (or Elan) SMBus driver. > > The SMBus

Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

Hi Dmitry, On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > From: Benjamin Tissoires > > This provides glue between PS/2 devices that enumerate the RMI4 devices > and Elan touchpads to the RMI4 (or Elan) SMBus driver. > > The SMBus devices keep their PS/

Re: [PATCH 4/4] Input: synaptics-rmi4 - when registering sensors do not call them "drivers"

r codes. > > Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com> > --- Looks good to me: Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Cheers, Benjamin > drivers/input/rmi4/rmi_i2c.c | 51 > +++

Re: [PATCH 4/4] Input: synaptics-rmi4 - when registering sensors do not call them "drivers"

r codes. > > Signed-off-by: Dmitry Torokhov > --- Looks good to me: Reviewed-by: Benjamin Tissoires Cheers, Benjamin > drivers/input/rmi4/rmi_i2c.c | 51 > +- > drivers/input/rmi4/rmi_smbus.c | 43 +

Re: [PATCH 3/4] Input: synaptics-rmi4 - cleanup SMbus mapping handling

was just plain wrong because rmiaddr was tagged as __le16. This fixes the storing issue. This one (and the previous then): Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Cheers, Benjamin > drivers/input/rmi4/rmi_smbus.c | 43 > ++-

Re: [PATCH 3/4] Input: synaptics-rmi4 - cleanup SMbus mapping handling

addr was tagged as __le16. This fixes the storing issue. This one (and the previous then): Reviewed-by: Benjamin Tissoires Cheers, Benjamin > drivers/input/rmi4/rmi_smbus.c | 43 > ++ > 1 file changed, 18 insertions(+), 25 deletions(-) > > d

Re: [PATCH 1/4] Input: synaptics-rmi4 - fix handling failures from rmi_enable_sensor

On Mar 24 2017 or thereabouts, Dmitry Torokhov wrote: > If rmi_enable_sensor() fails in rmi_driver_probe(), we should not return > immediately, but disable IRQs and tear down function list. > > Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com> > --- Reviewed-b

Re: [PATCH 1/4] Input: synaptics-rmi4 - fix handling failures from rmi_enable_sensor

On Mar 24 2017 or thereabouts, Dmitry Torokhov wrote: > If rmi_enable_sensor() fails in rmi_driver_probe(), we should not return > immediately, but disable IRQs and tear down function list. > > Signed-off-by: Dmitry Torokhov > --- Reviewed-by: Benjamin Tissoires Cheers, Benja

Re: [PATCH 2/4] Input: synaptics-rmi4 - fix endianness issue in SMBus transport

On Mar 24 2017 or thereabouts, Dmitry Torokhov wrote: > The mapping table holds address in LE form, so we should convert it > to CPU when comparing it. Are you sure about that? >From what I can read: rmiaddr is set by rmi_smb_get_command_code(), and it's forwarded directly from the caller to the

Re: [PATCH 2/4] Input: synaptics-rmi4 - fix endianness issue in SMBus transport

On Mar 24 2017 or thereabouts, Dmitry Torokhov wrote: > The mapping table holds address in LE form, so we should convert it > to CPU when comparing it. Are you sure about that? >From what I can read: rmiaddr is set by rmi_smb_get_command_code(), and it's forwarded directly from the caller to the

Re: [PATCH] HID: sony: remove redundant check for -ve err

65 ("Logically dead code") > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> > --- Indeed. Not sure if it will conflict with Roderick's series, but still: Reviewed-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Cheers, Benjamin > drivers/hid/hid-

Re: [PATCH] HID: sony: remove redundant check for -ve err

;) > > Signed-off-by: Colin Ian King > --- Indeed. Not sure if it will conflict with Roderick's series, but still: Reviewed-by: Benjamin Tissoires Cheers, Benjamin > drivers/hid/hid-sony.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/hid/hid-son

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On Mar 29 2017 or thereabouts, Andrew Duggan wrote: > > > On 03/29/2017 01:50 AM, Benjamin Tissoires wrote: > > On Mar 28 2017 or thereabouts, Andrew Duggan wrote: > > > On 03/19/2017 10:00 PM, Peter Hutterer wrote: > > > > On Fri, Mar 17, 2017 at 1

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On Mar 29 2017 or thereabouts, Andrew Duggan wrote: > > > On 03/29/2017 01:50 AM, Benjamin Tissoires wrote: > > On Mar 28 2017 or thereabouts, Andrew Duggan wrote: > > > On 03/19/2017 10:00 PM, Peter Hutterer wrote: > > > > On Fri, Mar 17, 2017 at 1

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On Mar 28 2017 or thereabouts, Andrew Duggan wrote: > On 03/19/2017 10:00 PM, Peter Hutterer wrote: > > On Fri, Mar 17, 2017 at 12:23:36PM -0700, Andrew Duggan wrote: > > > On 03/17/2017 09:57 AM, Benjamin Tissoires wrote: > > > > On Wed, Mar 15, 2017 a

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On Mar 28 2017 or thereabouts, Andrew Duggan wrote: > On 03/19/2017 10:00 PM, Peter Hutterer wrote: > > On Fri, Mar 17, 2017 at 12:23:36PM -0700, Andrew Duggan wrote: > > > On 03/17/2017 09:57 AM, Benjamin Tissoires wrote: > > > > On Wed, Mar 15, 2017 at 2:19 AM,

[PATCH v3 07/19] HID: logitech-hidpp: retrieve the HID++ device name when available

hidpp->name can't be null. Only HID++ 2.0 and above device supports the query. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - moved up in the series new in v2 --- drivers/hid/hid-logitech-hidpp.c | 14 +++--- 1 file changed, 7 inserti

[PATCH v3 12/19] HID: logitech-hidpp: return an error if the queried feature is not present

Or the device just answers a valid feature '0'. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - moved up in the series no changes in v2 --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-lo

[PATCH v3 07/19] HID: logitech-hidpp: retrieve the HID++ device name when available

hidpp->name can't be null. Only HID++ 2.0 and above device supports the query. Signed-off-by: Benjamin Tissoires --- changes in v3: - moved up in the series new in v2 --- drivers/hid/hid-logitech-hidpp.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --

[PATCH v3 12/19] HID: logitech-hidpp: return an error if the queried feature is not present

Or the device just answers a valid feature '0'. Signed-off-by: Benjamin Tissoires --- changes in v3: - moved up in the series no changes in v2 --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid

[PATCH v3 14/19] HID: logitech-hidpp: battery: provide ONLINE property

When ONLINE isn't set, upower should ignore the battery capacity, so there is no need to overload it with some random values. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- completely reworked in v3: - store a online field in hidpp->battery to be able to fin

[PATCH v3 16/19] HID: logitech-hidpp: battery: provide CAPACITY_LEVEL

%, which might confuse users. With this change the battery will either report "Full" or "Critical". Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- new in v3 --- drivers/hid/hid-logitech-hidpp.c | 104 +++ 1 file cha

[PATCH v3 14/19] HID: logitech-hidpp: battery: provide ONLINE property

When ONLINE isn't set, upower should ignore the battery capacity, so there is no need to overload it with some random values. Signed-off-by: Benjamin Tissoires --- completely reworked in v3: - store a online field in hidpp->battery to be able to fine control the value - prov

[PATCH v3 16/19] HID: logitech-hidpp: battery: provide CAPACITY_LEVEL

%, which might confuse users. With this change the battery will either report "Full" or "Critical". Signed-off-by: Benjamin Tissoires --- new in v3 --- drivers/hid/hid-logitech-hidpp.c | 104 +++ 1 file changed, 94 insertions(+), 10 dele

[PATCH v3 15/19] HID: logitech-hidpp: rename battery level into capacity

The power_supply term for the percentage is capacity. Capacity level can be given when non accurate mileage is provided by the device, so better stick to the terms used in power_supply. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- new in v3 --- drivers/hid/hid-lo

[PATCH v3 11/19] HID: logitech-hidpp: create the battery for all types of HID++ devices

The creation of the power_supply should not be in a HID++ 2.0 specific function. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - moved up in the series no changes in v2 --- drivers/hid/hid-logitech-hidpp.c | 94 ++---

[PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery

net> Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- no changes in v3 changes in v2: * fixed typo in commit message --- drivers/hid/hid-logitech-hidpp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logite

[PATCH v3 11/19] HID: logitech-hidpp: create the battery for all types of HID++ devices

The creation of the power_supply should not be in a HID++ 2.0 specific function. Signed-off-by: Benjamin Tissoires --- changes in v3: - moved up in the series no changes in v2 --- drivers/hid/hid-logitech-hidpp.c | 94 ++-- 1 file changed, 43 insertions

[PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery

From: Bastien Nocera Without a scope defined, UPower assumes that the battery provides power to the computer it's connected to, like a laptop battery or a UPS. Tested-by: Peter Hutterer Signed-off-by: Bastien Nocera Signed-off-by: Benjamin Tissoires --- no changes in v3 changes in v2

[PATCH v3 15/19] HID: logitech-hidpp: rename battery level into capacity

The power_supply term for the percentage is capacity. Capacity level can be given when non accurate mileage is provided by the device, so better stick to the terms used in power_supply. Signed-off-by: Benjamin Tissoires --- new in v3 --- drivers/hid/hid-logitech-hidpp.c | 55

[PATCH v3 03/19] HID: logitech-hidpp: make sure we only register one battery per device

Simple check to add, huge improvement :) Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- no changes in v3 no changes in v2 --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/h

[PATCH v3 03/19] HID: logitech-hidpp: make sure we only register one battery per device

Simple check to add, huge improvement :) Signed-off-by: Benjamin Tissoires --- no changes in v3 no changes in v2 --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 4aaf237

[PATCH v3 18/19] HID: logitech-hidpp: enable HID++ 1.0 battery reporting

Also enable battery reporting for HID++ 1.0 devices through 2 registers: 0x07: battery status -> reports only 4 levels (critical, low, good, full) 0x0D: battery mileage -> reports true pourcentage Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- c

[PATCH v3 13/19] HID: logitech-hidpp: notify battery on connect

When a device reconnects, there is a high chance its power supply has been changed (for a battery replacement for instance). Just forward the battery state here. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - moved up in the series no changes

[PATCH v3 13/19] HID: logitech-hidpp: notify battery on connect

When a device reconnects, there is a high chance its power supply has been changed (for a battery replacement for instance). Just forward the battery state here. Signed-off-by: Benjamin Tissoires --- changes in v3: - moved up in the series no changes in v2 --- drivers/hid/hid-logitech

[PATCH v3 18/19] HID: logitech-hidpp: enable HID++ 1.0 battery reporting

Also enable battery reporting for HID++ 1.0 devices through 2 registers: 0x07: battery status -> reports only 4 levels (critical, low, good, full) 0x0D: battery mileage -> reports true pourcentage Signed-off-by: Benjamin Tissoires --- changes in v3: - differentiate between level and m

[PATCH v3 17/19] HID: logitech-hidpp: add support for battery status for the K750

The Solar Keyboard uses a different feature to report the battery level. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - fixed online status changes in v2: * update state according to lux information * do not update Lux if the event does not conta

[PATCH v3 10/19] HID: logitech-hidpp: forward device info in power_supply

Better forwarding the device name, manufacturer and serial to upower. Note that serial is still empty, it will be filled in a later patch in this series. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- changes in v3: - moved up in the series changes in v2: *

[PATCH v3 05/19] HID: logitech-hidpp: create a capabilities bits field

Do not pollute the quirks bits field which is public API with elements that are queried from the device. Move the 2 battery capabilities into the new field. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> --- new in v3 --- drivers/hid/hid-logitech-hidpp.c | 10 ++-

[PATCH v3 09/19] HID: logitech-hidpp: handle battery events in hidpp_raw_hidpp_event()

Battery events are reported through HID++, so we need to be sure the report ID is the HID++ one. Without this, we might receive keyboard events that looks just like battery events with wrong data and which will confuse user space. Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.

<    6   7   8   9   10   11   12   13   14   15   >