[PATCH] HID: Remove Jabra speakerphone devices from ignore list

[PATCH] HID: Remove Jabra speakerphone devices from ignore list

[nolsen]

From: Niels Skou Olsen <nolsen@jabra.com>

Two Jabra speakerphone devices were added to the ignore list in 2013
because, at the time, the device HID interfaces didn't work well with
kernel usbhid driver, and could reportedly cause volume key event
storm.

See the original commit:
Commit 31b9779cb292 ("HID: ignore Jabra speakerphones HID interface")

Testing the devices today reveals no such problems, and the
blacklisting can safely be removed.

Signed-off-by: Niels Skou Olsen <nolsen@jabra.com>
---
 drivers/hid/hid-core.c | 2 --
 drivers/hid/hid-ids.h  | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9bc9116..b49d7c4 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2697,8 +2697,6 @@ static const struct hid_device_id hid_ignore_list[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_1006) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_1007) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_IMATION, USB_DEVICE_ID_DISC_STAKKA) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_410) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_510) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_GN9350E) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_KBGEAR, USB_DEVICE_ID_KBGEAR_JAMSTUDIO) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_KWORLD, USB_DEVICE_ID_KWORLD_RADIO_FM700) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b397a14..12b9179 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -578,8 +578,6 @@
 #define USB_DEVICE_ID_ITE8595		0x8595
 
 #define USB_VENDOR_ID_JABRA		0x0b0e
-#define USB_DEVICE_ID_JABRA_SPEAK_410	0x0412
-#define USB_DEVICE_ID_JABRA_SPEAK_510	0x0420
 #define USB_DEVICE_ID_JABRA_GN9350E	0x9350
 
 #define USB_VENDOR_ID_JESS		0x0c45
-- 
2.7.4

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Jiri Kosina]

On Tue, 5 Sep 2017, nolsen@jabra.com wrote:

> From: Niels Skou Olsen <nolsen@jabra.com>
> 
> Two Jabra speakerphone devices were added to the ignore list in 2013
> because, at the time, the device HID interfaces didn't work well with
> kernel usbhid driver, and could reportedly cause volume key event
> storm.

Also apparently there was an userspace application that made use of these 
keys, and required the usbhid driver to be unbound from them.

How come this is not the case any more?

Adding original quirk entry author (Vincent) to CC (and keeping the rest 
of message below for reference).

> 
> See the original commit:
> Commit 31b9779cb292 ("HID: ignore Jabra speakerphones HID interface")
> 
> Testing the devices today reveals no such problems, and the
> blacklisting can safely be removed.
> 
> Signed-off-by: Niels Skou Olsen <nolsen@jabra.com>
> ---
>  drivers/hid/hid-core.c | 2 --
>  drivers/hid/hid-ids.h  | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9bc9116..b49d7c4 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2697,8 +2697,6 @@ static const struct hid_device_id hid_ignore_list[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_1006) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_1007) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_IMATION, USB_DEVICE_ID_DISC_STAKKA) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_410) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_510) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_GN9350E) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_KBGEAR, USB_DEVICE_ID_KBGEAR_JAMSTUDIO) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_KWORLD, USB_DEVICE_ID_KWORLD_RADIO_FM700) },
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index b397a14..12b9179 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -578,8 +578,6 @@
>  #define USB_DEVICE_ID_ITE8595		0x8595
>  
>  #define USB_VENDOR_ID_JABRA		0x0b0e
> -#define USB_DEVICE_ID_JABRA_SPEAK_410	0x0412
> -#define USB_DEVICE_ID_JABRA_SPEAK_510	0x0420
>  #define USB_DEVICE_ID_JABRA_GN9350E	0x9350
>  
>  #define USB_VENDOR_ID_JESS		0x0c45
> -- 
> 2.7.4
> 

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Vincent Palatin]

Re-sending (seems I forgot the HTML subpart that linux-input doesn't like)

On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
>
>
> > From: Niels Skou Olsen <nolsen@jabra.com>
>
> >
>
> > Two Jabra speakerphone devices were added to the ignore list in 2013
>
> > because, at the time, the device HID interfaces didn't work well with
>
> > kernel usbhid driver, and could reportedly cause volume key event
>
> > storm.
>
>
> Also apparently there was an userspace application that made use of these
>
> keys, and required the usbhid driver to be unbound from them.
>
>
> How come this is not the case any more?



On our side, we are still using a custom userspace for the Jabra
speakers (ie the jabra_vold daemon:
https://chromium.googlesource.com/chromiumos/platform/jabra_vold/+/master
plus some direct USB interfacing in a Chrome app).
while If somebody is using the device another way, we can blacklist it
or detach it on our side in the future,  I'm somewhat surprised that
it's working well through the HID interface with the Jabra
speakerphone 510. Even if there is no longer any basic breakage, in my
experience there are other challenges to overcome with the 510
firmware (at least the one I had on my devices) e.g. for the volume
key to work more than once, you need to do a precise sequence on the
USB audio interface every time one of the volume key is released.
Do you have another kernel driver for this ? a userspace software ?


>>
>>
>> Adding original quirk entry author (Vincent) to CC (and keeping the rest
>> of message below for reference).
>>
>> >
>> > See the original commit:
>> > Commit 31b9779cb292 ("HID: ignore Jabra speakerphones HID interface")
>> >
>> > Testing the devices today reveals no such problems, and the
>> > blacklisting can safely be removed.
>> >
>> > Signed-off-by: Niels Skou Olsen <nolsen@jabra.com>
>> > ---
>> >  drivers/hid/hid-core.c | 2 --
>> >  drivers/hid/hid-ids.h  | 2 --
>> >  2 files changed, 4 deletions(-)
>> >
>> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> > index 9bc9116..b49d7c4 100644
>> > --- a/drivers/hid/hid-core.c
>> > +++ b/drivers/hid/hid-core.c
>> > @@ -2697,8 +2697,6 @@ static const struct hid_device_id hid_ignore_list[] = {
>> >       { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_1006) },
>> >       { HID_USB_DEVICE(USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_1007) },
>> >       { HID_USB_DEVICE(USB_VENDOR_ID_IMATION, USB_DEVICE_ID_DISC_STAKKA) },
>> > -     { HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_410) },
>> > -     { HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_SPEAK_510) },
>> >       { HID_USB_DEVICE(USB_VENDOR_ID_JABRA, USB_DEVICE_ID_JABRA_GN9350E) },
>> >       { HID_USB_DEVICE(USB_VENDOR_ID_KBGEAR, USB_DEVICE_ID_KBGEAR_JAMSTUDIO) },
>> >       { HID_USB_DEVICE(USB_VENDOR_ID_KWORLD, USB_DEVICE_ID_KWORLD_RADIO_FM700) },
>> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>> > index b397a14..12b9179 100644
>> > --- a/drivers/hid/hid-ids.h
>> > +++ b/drivers/hid/hid-ids.h
>> > @@ -578,8 +578,6 @@
>> >  #define USB_DEVICE_ID_ITE8595                0x8595
>> >
>> >  #define USB_VENDOR_ID_JABRA          0x0b0e
>> > -#define USB_DEVICE_ID_JABRA_SPEAK_410        0x0412
>> > -#define USB_DEVICE_ID_JABRA_SPEAK_510        0x0420
>> >  #define USB_DEVICE_ID_JABRA_GN9350E  0x9350
>> >
>> >  #define USB_VENDOR_ID_JESS           0x0c45
>> > --
>> > 2.7.4
>> >
>>
>> --
>> Jiri Kosina
>> SUSE Labs
>>
>

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Fri, 8 Sep 2017, vpalatin@google.com wrote:

> Re-sending (seems I forgot the HTML subpart that linux-input doesn't like)
>
> On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
> >
> > On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
> >
> > > From: Niels Skou Olsen <nolsen@jabra.com>
> > >
> > > Two Jabra speakerphone devices were added to the ignore list in 2013
> > > because, at the time, the device HID interfaces didn't work well
> > > with
> > > kernel usbhid driver, and could reportedly cause volume key event
> > > storm.
> >
> > Also apparently there was an userspace application that made use of
> > these keys, and required the usbhid driver to be unbound from them.
> >
> > How come this is not the case any more?

I can't really tell why, but it could be that our firmware has "improved" since 2013, and maybe also the Linux drivers and user mode stuff like PulseAudio have improved the situation. Anyway, I don't see the volume event storm issue when I test on a Ubuntu desktop with patched 4.4 and 4.13 kernels, and our firmware SPEAK410/1.8.0 and SPEAK510/2.10.0.

> On our side, we are still using a custom userspace for the Jabra speakers (ie the
> jabra_vold daemon:
> https://chromium.googlesource.com/chromiumos/platform/jabra_vold/+/master
> plus some direct USB interfacing in a Chrome app).
> while If somebody is using the device another way, we can blacklist it or detach it on
> our side in the future,  I'm somewhat surprised that it's working well through the HID
> interface with the Jabra speakerphone 510. Even if there is no longer any basic
> breakage, in my experience there are other challenges to overcome with the 510
> firmware (at least the one I had on my devices) e.g. for the volume key to work more
> than once, you need to do a precise sequence on the USB audio interface every time
> one of the volume key is released.
> Do you have another kernel driver for this ? a userspace software ?

Thank you for your input, Vincent. As mentioned above I can't reproduce the volume event storm. I can, however, reproduce the issue you mention, that our device only emits an event for the first volume key press. We have a new firmware fixing that, so that volume keys now behave sanely on Linux. I would be happy to send you the new firmware, if you could find the time to try it out with ChromiumOS. Just let me know.

Could we remove the blacklisting even if the current firmware behaves a bit "weird" with regard to volume button handling? I don't think this quirk is severe enough to warrant the complete blacklisting. As mentioned we have a new firmware coming out now that fixes it. And if ChromiumOS intends to continue with jabra_vold and blacklisting in the future, I guess there is no conflict?

Thanks,
Niels


**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Vincent Palatin]

On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@jabra.com> wrote:
>
> On Fri, 8 Sep 2017, vpalatin@google.com wrote:
>
>> Re-sending (seems I forgot the HTML subpart that linux-input doesn't like)
>>
>> On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
>> >
>> > On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
>> >
>> > > From: Niels Skou Olsen <nolsen@jabra.com>
>> > >
>> > > Two Jabra speakerphone devices were added to the ignore list in 2013
>> > > because, at the time, the device HID interfaces didn't work well
>> > > with
>> > > kernel usbhid driver, and could reportedly cause volume key event
>> > > storm.
>> >
>> > Also apparently there was an userspace application that made use of
>> > these keys, and required the usbhid driver to be unbound from them.
>> >
>> > How come this is not the case any more?
>
> I can't really tell why, but it could be that our firmware has "improved" since 2013, and maybe also the Linux drivers and user mode stuff like PulseAudio have improved the situation. Anyway, I don't see the volume event storm issue when I test on a Ubuntu desktop with patched 4.4 and 4.13 kernels, and our firmware SPEAK410/1.8.0 and SPEAK510/2.10.0.

A related question: How does I read the firmware on Jabra speaker ?
(see below why)
Pick something which looks like a brand new Jabra SPEAK 410 (Model:
PHS001U P/N 7410 - 219  , Ver.: A120314) gives me :
  idVendor           0x0b0e GN Netcom
  idProduct          0x0412
  bcdDevice            1.09
  iManufacturer           0
  iProduct                2 Jabra SPEAK 410 USB
  iSerial                 3 50C971FEF72Dx010900

is the bcdDevice related to hardware version or firmware version ?


>
>> On our side, we are still using a custom userspace for the Jabra speakers (ie the
>> jabra_vold daemon:
>> https://chromium.googlesource.com/chromiumos/platform/jabra_vold/+/master
>> plus some direct USB interfacing in a Chrome app).
>> while If somebody is using the device another way, we can blacklist it or detach it on
>> our side in the future,  I'm somewhat surprised that it's working well through the HID
>> interface with the Jabra speakerphone 510. Even if there is no longer any basic
>> breakage, in my experience there are other challenges to overcome with the 510
>> firmware (at least the one I had on my devices) e.g. for the volume key to work more
>> than once, you need to do a precise sequence on the USB audio interface every time
>> one of the volume key is released.
>> Do you have another kernel driver for this ? a userspace software ?
>
> Thank you for your input, Vincent. As mentioned above I can't reproduce the volume event storm. I can, however, reproduce the issue you mention, that our device only emits an event for the first volume key press. We have a new firmware fixing that, so that volume keys now behave sanely on Linux. I would be happy to send you the new firmware, if you could find the time to try it out with ChromiumOS. Just let me know.

Sure I can test it, if you have a firmware updater for Linux
(ie downloaded firmware from Jabra website gives me a .dfu file I
don't know what I'm supposed to do with)

>
> Could we remove the blacklisting even if the current firmware behaves a bit "weird" with regard to volume button handling?
>  I don't think this quirk is severe enough to warrant the complete blacklisting.

wrt 'the complete blacklisting', not really it's just disabling
instantiating a HID device by default,
the USB device is still there, adventurous people who knows what to do
with it can still ask for the HID device (e.g by passing
'quirks=0x0b0e:0x0412:0x40000000' as usbhid module parameter to avoid
ignoring it)

wrt 'current firmware behaves a bit "weird" with regard to volume
button', that was an example but over the 5 buttons (vol_up, vol_down,
mic_mute, call, hang_up), none of them is behaving properly with just
the regular HID driver:
vol_up/down works only once as mentioned earlier, mute/call/hang never
sends events (due to the state the device is in by default). If I
remember properly getting them to work requires to send HID reports
(SET_REPORT) to the device first, ie basically writing a program to do
so.
So with no working buttons by default, it's not really interesting to
instantiate the driver ...

> As mentioned we have a new firmware coming out now that fixes it.
> And if ChromiumOS intends to continue with jabra_vold and blacklisting in the future, I guess there is no conflict?

Are you planning to provide the new firmware and the updater to the
Linux users ?
If so, we might be able to make the quirk conditional on the firmware
version ? (hence my firmware version reading question above)

ChromiumOS devs will do whatever is necessary to keep the current
devices working and avoiding the current userspace daemon would be one
less maintenance burden, but for other Linux users, there is very
little value in getting an always broken HID device unless they can
update their devices.

-- 
Vincent

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Tue, 12 Sep 2017, vpalatin@google.com wrote:

> On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> >
> > On Fri, 8 Sep 2017, vpalatin@google.com wrote:
> >
> >> Re-sending (seems I forgot the HTML subpart that linux-input doesn't
> >> like)
> >>
> >> On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
> >> >
> >> > On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
> >> >
> >> > > From: Niels Skou Olsen <nolsen@jabra.com>
> >> > >
> >> > > Two Jabra speakerphone devices were added to the ignore list in
> >> > > 2013 because, at the time, the device HID interfaces didn't work
> >> > > well with kernel usbhid driver, and could reportedly cause volume
> >> > > key event storm.
> >> >
> >> > Also apparently there was an userspace application that made use of
> >> > these keys, and required the usbhid driver to be unbound from them.
> >> >
> >> > How come this is not the case any more?
> >
> > I can't really tell why, but it could be that our firmware has "improved" since 2013,
> > and maybe also the Linux drivers and user mode stuff like PulseAudio have improved
> > the situation. Anyway, I don't see the volume event storm issue when I test on a
> > Ubuntu desktop with patched 4.4 and 4.13 kernels, and our firmware
> > SPEAK410/1.8.0 and SPEAK510/2.10.0.
>
> A related question: How does I read the firmware on Jabra speaker ?
> (see below why)
> Pick something which looks like a brand new Jabra SPEAK 410 (Model:
> PHS001U P/N 7410 - 219  , Ver.: A120314) gives me :
>   idVendor           0x0b0e GN Netcom
>   idProduct          0x0412
>   bcdDevice            1.09
>   iManufacturer           0
>   iProduct                2 Jabra SPEAK 410 USB
>   iSerial                 3 50C971FEF72Dx010900
>
> is the bcdDevice related to hardware version or firmware version ?

The bcdDevice is the firmware version. So you are running 1.9.0 (the last level is always 0).

> >> On our side, we are still using a custom userspace for the Jabra
> >> speakers (ie the jabra_vold daemon:
> >> https://chromium.googlesource.com/chromiumos/platform/jabra_vold/+/ma
> >> ster plus some direct USB interfacing in a Chrome app).
> >> while If somebody is using the device another way, we can blacklist
> >> it or detach it on our side in the future,  I'm somewhat surprised
> >> that it's working well through the HID interface with the Jabra
> >> speakerphone 510. Even if there is no longer any basic breakage, in
> >> my experience there are other challenges to overcome with the 510
> >> firmware (at least the one I had on my devices) e.g. for the volume
> >> key to work more than once, you need to do a precise sequence on the USB
> audio interface every time one of the volume key is released.
> >> Do you have another kernel driver for this ? a userspace software ?
> >
> > Thank you for your input, Vincent. As mentioned above I can't reproduce the
> > volume event storm. I can, however, reproduce the issue you mention, that our
> > device only emits an event for the first volume key press. We have a new firmware
> > fixing that, so that volume keys now behave sanely on Linux. I would be happy to
> > send you the new firmware, if you could find the time to try it out with ChromiumOS.
> > Just let me know.
>
> Sure I can test it, if you have a firmware updater for Linux (ie downloaded firmware
> from Jabra website gives me a .dfu file I don't know what I'm supposed to do with)

The .dfu file can be programmed into the device using dfu-util (http://dfu-util.sourceforge.net/). The device needs to be put into DFU mode before running dfu-util. Unfortunately, the only way to enter DFU mode is by sending a command over HID -- there is no way to do it on the device. So, to update, the HID blacklisting needs to be removed. I will send you a shell script that puts the device into DFU mode and invokes dfu-util.

> > Could we remove the blacklisting even if the current firmware behaves a bit "weird"
> > with regard to volume button handling?
> >  I don't think this quirk is severe enough to warrant the complete blacklisting.
>
> wrt 'the complete blacklisting', not really it's just disabling instantiating a HID device
> by default, the USB device is still there, adventurous people who knows what to do
> with it can still ask for the HID device (e.g by passing
> 'quirks=0x0b0e:0x0412:0x40000000' as usbhid module parameter to avoid ignoring
> it)

That's a nice trick, but most end users can't do that.

> wrt 'current firmware behaves a bit "weird" with regard to volume button', that was an
> example but over the 5 buttons (vol_up, vol_down, mic_mute, call, hang_up), none of
> them is behaving properly with just the regular HID driver:
> vol_up/down works only once as mentioned earlier, mute/call/hang never sends
> events (due to the state the device is in by default). If I remember properly getting
> them to work requires to send HID reports
> (SET_REPORT) to the device first, ie basically writing a program to do so.
> So with no working buttons by default, it's not really interesting to instantiate the
> driver ...

Yes, the volume buttons have issues. We are fixing it. The other telephony related buttons need a softphone application to help drive the state machine in the device. For example, when you hit the call button a report is issued. Now a softphone must acknowledge that a call is open. If this does not happen, the device will time out and emit a hangup report. If you press hangup with an active call, a hangup report is emiited. If you press hangup without an active call, no report is emitted. So I don't think it's fair to say 'no buttons working'. And it definitely is interesting for us that the HID driver is instantiated. Without it you can't write applications that does call control, firmware update etc.

> > As mentioned we have a new firmware coming out now that fixes it.
> > And if ChromiumOS intends to continue with jabra_vold and blacklisting in the
> > future, I guess there is no conflict?
>
> Are you planning to provide the new firmware and the updater to the Linux users ?
> If so, we might be able to make the quirk conditional on the firmware version ? (hence
> my firmware version reading question above)

Yes. As mentioned dfu-util can do the update given a tiny shell script wrapper, and the firmware will be available on jabra.com. Also we have a mass deployment tool for corporate Linux based thin client environments.

> ChromiumOS devs will do whatever is necessary to keep the current devices
> working and avoiding the current userspace daemon would be one less maintenance
> burden, but for other Linux users, there is very little value in getting an always broken
> HID device unless they can update their devices.

Agreed. But it is catch-22 here -  the HID blacklisting needs to be lifted in order for firmware update on a Linux system to be possible.

Thanks,
Niels

**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Vincent Palatin]

On Tue, Sep 12, 2017 at 4:22 PM, Niels Skou Olsen <nolsen@jabra.com> wrote:
>
> On Tue, 12 Sep 2017, vpalatin@google.com wrote:
>
> > On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> > >
> > > On Fri, 8 Sep 2017, vpalatin@google.com wrote:
> > >
> > >> Re-sending (seems I forgot the HTML subpart that linux-input doesn't
> > >> like)
> > >>
> > >> On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
> > >> >
> > >> > On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
> > >> >
> > >> > > From: Niels Skou Olsen <nolsen@jabra.com>
> > >> > >
> > >> > > Two Jabra speakerphone devices were added to the ignore list in
> > >> > > 2013 because, at the time, the device HID interfaces didn't work
> > >> > > well with kernel usbhid driver, and could reportedly cause volume
> > >> > > key event storm.
> > >> >
> > >> > Also apparently there was an userspace application that made use of
> > >> > these keys, and required the usbhid driver to be unbound from them.
> > >> >
> > >> > How come this is not the case any more?
> > >
> > > I can't really tell why, but it could be that our firmware has "improved" since 2013,
> > > and maybe also the Linux drivers and user mode stuff like PulseAudio have improved
> > > the situation. Anyway, I don't see the volume event storm issue when I test on a
> > > Ubuntu desktop with patched 4.4 and 4.13 kernels, and our firmware
> > > SPEAK410/1.8.0 and SPEAK510/2.10.0.
> >
> > A related question: How does I read the firmware on Jabra speaker ?
> > (see below why)
> > Pick something which looks like a brand new Jabra SPEAK 410 (Model:
> > PHS001U P/N 7410 - 219  , Ver.: A120314) gives me :
> >   idVendor           0x0b0e GN Netcom
> >   idProduct          0x0412
> >   bcdDevice            1.09
> >   iManufacturer           0
> >   iProduct                2 Jabra SPEAK 410 USB
> >   iSerial                 3 50C971FEF72Dx010900
> >
> > is the bcdDevice related to hardware version or firmware version ?
>
> The bcdDevice is the firmware version. So you are running 1.9.0 (the last level is always 0).
>
> > >> On our side, we are still using a custom userspace for the Jabra
> > >> speakers (ie the jabra_vold daemon:
> > >> https://chromium.googlesource.com/chromiumos/platform/jabra_vold/+/ma
> > >> ster plus some direct USB interfacing in a Chrome app).
> > >> while If somebody is using the device another way, we can blacklist
> > >> it or detach it on our side in the future,  I'm somewhat surprised
> > >> that it's working well through the HID interface with the Jabra
> > >> speakerphone 510. Even if there is no longer any basic breakage, in
> > >> my experience there are other challenges to overcome with the 510
> > >> firmware (at least the one I had on my devices) e.g. for the volume
> > >> key to work more than once, you need to do a precise sequence on the USB
> > audio interface every time one of the volume key is released.
> > >> Do you have another kernel driver for this ? a userspace software ?
> > >
> > > Thank you for your input, Vincent. As mentioned above I can't reproduce the
> > > volume event storm. I can, however, reproduce the issue you mention, that our
> > > device only emits an event for the first volume key press. We have a new firmware
> > > fixing that, so that volume keys now behave sanely on Linux. I would be happy to
> > > send you the new firmware, if you could find the time to try it out with ChromiumOS.
> > > Just let me know.
> >
> > Sure I can test it, if you have a firmware updater for Linux (ie downloaded firmware
> > from Jabra website gives me a .dfu file I don't know what I'm supposed to do with)
>
> The .dfu file can be programmed into the device using dfu-util (http://dfu-util.sourceforge.net/). The device needs to be put into DFU mode before running dfu-util.

Along with the firmware version in bcdDevice, this is great news !
So everybody should have a path to update.

> Unfortunately, the only way to enter DFU mode is by sending a command over HID -- there is no way to do it on the device.
> So, to update, the HID blacklisting needs to be removed.
> I will send you a shell script that puts the device into DFU mode and invokes dfu-util.

maybe ... or to send a single command, you can also send it directly
to the USB device rather than through the HID layer.
It's a bit challenging to write in a shell script (but not
impossible), my own lame Python one-liner makes my Jabra 410 ring :
python -c "from ctypes import * ; so = CDLL('libusb-1.0.so') ;
so.libusb_init(c_void_p()) ;
so.libusb_control_transfer(so.libusb_open_device_with_vid_pid(None,
0x0b0e, 0x0412), 0x21, 0x09, 0x0203, 0x0003, '\x03\x08\0', 3, 5000)"
it would probably put it in DFU mode if I knew the secret command.

>
> > > Could we remove the blacklisting even if the current firmware behaves a bit "weird"
> > > with regard to volume button handling?
> > >  I don't think this quirk is severe enough to warrant the complete blacklisting.
> >
> > wrt 'the complete blacklisting', not really it's just disabling instantiating a HID device
> > by default, the USB device is still there, adventurous people who knows what to do
> > with it can still ask for the HID device (e.g by passing
> > 'quirks=0x0b0e:0x0412:0x40000000' as usbhid module parameter to avoid ignoring
> > it)
>
> That's a nice trick, but most end users can't do that.

most end users cannot use the current firmware either ...
Actually plugging the Jabra SPEAK 410 (firmware 1.9) on my workstation
(running Ubuntu LTS 14.04 with kernel 4.4) has just randomly made my
mouse misbehave to my great dismay. With the old firmware, not all
issues are gone.


> > wrt 'current firmware behaves a bit "weird" with regard to volume button', that was an
> > example but over the 5 buttons (vol_up, vol_down, mic_mute, call, hang_up), none of
> > them is behaving properly with just the regular HID driver:
> > vol_up/down works only once as mentioned earlier, mute/call/hang never sends
> > events (due to the state the device is in by default). If I remember properly getting
> > them to work requires to send HID reports
> > (SET_REPORT) to the device first, ie basically writing a program to do so.
> > So with no working buttons by default, it's not really interesting to instantiate the
> > driver ...
>
> Yes, the volume buttons have issues. We are fixing it. The other telephony related buttons need a softphone application to help drive the state machine in the device. For example, when you hit the call button a report is issued. Now a softphone must acknowledge that a call is open. If this does not happen, the device will time out and emit a hangup report. If you press hangup with an active call, a hangup report is emiited. If you press hangup without an active call, no report is emitted. So I don't think it's fair to say 'no buttons working'. And it definitely is interesting for us that the HID driver is instantiated. Without it you can't write applications that does call control, firmware update etc.

You cannot or you can ... actually with the current firmware issues,
we wrote 2 years chrome.usb application which works well so far.


>
> > > As mentioned we have a new firmware coming out now that fixes it.
> > > And if ChromiumOS intends to continue with jabra_vold and blacklisting in the
> > > future, I guess there is no conflict?
> >
> > Are you planning to provide the new firmware and the updater to the Linux users ?
> > If so, we might be able to make the quirk conditional on the firmware version ? (hence
> > my firmware version reading question above)
>
> Yes. As mentioned dfu-util can do the update given a tiny shell script wrapper, and the firmware will be available on jabra.com. Also we have a mass deployment tool for corporate Linux based thin client environments.
>
> > ChromiumOS devs will do whatever is necessary to keep the current devices
> > working and avoiding the current userspace daemon would be one less maintenance
> > burden, but for other Linux users, there is very little value in getting an always broken
> > HID device unless they can update their devices.
>
> Agreed. But it is catch-22 here -  the HID blacklisting needs to be lifted in order for firmware update on a Linux system to be possible.

I don't think so, as mentioned above.
It would have been nice to ignore it in HID based on the firmware
version/bcdUSB but not my call.

-- 
Vincent

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[benjamin.tissoires]

[adding Richard, the LVFS maintainer]

On Sep 13 2017 or thereabouts, Vincent Palatin wrote:
> On Tue, Sep 12, 2017 at 4:22 PM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> >
> > On Tue, 12 Sep 2017, vpalatin@google.com wrote:
> >
> > > On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> > > >
> > > > On Fri, 8 Sep 2017, vpalatin@google.com wrote:
> > > >
> > > >> Re-sending (seems I forgot the HTML subpart that linux-input doesn't
> > > >> like)
> > > >>
> > > >> On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
> > > >> >
> > > >> > On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
> > > >> >
> > > >> > > From: Niels Skou Olsen <nolsen@jabra.com>
> > > >> > >
> > > >> > > Two Jabra speakerphone devices were added to the ignore list in
> > > >> > > 2013 because, at the time, the device HID interfaces didn't work
> > > >> > > well with kernel usbhid driver, and could reportedly cause volume
> > > >> > > key event storm.
> > > >> >
> > > >> > Also apparently there was an userspace application that made use of
> > > >> > these keys, and required the usbhid driver to be unbound from them.
> > > >> >
> > > >> > How come this is not the case any more?
> > > >
> > > > I can't really tell why, but it could be that our firmware has "improved" since 2013,
> > > > and maybe also the Linux drivers and user mode stuff like PulseAudio have improved
> > > > the situation. Anyway, I don't see the volume event storm issue when I test on a
> > > > Ubuntu desktop with patched 4.4 and 4.13 kernels, and our firmware
> > > > SPEAK410/1.8.0 and SPEAK510/2.10.0.
> > >
> > > A related question: How does I read the firmware on Jabra speaker ?
> > > (see below why)
> > > Pick something which looks like a brand new Jabra SPEAK 410 (Model:
> > > PHS001U P/N 7410 - 219  , Ver.: A120314) gives me :
> > >   idVendor           0x0b0e GN Netcom
> > >   idProduct          0x0412
> > >   bcdDevice            1.09
> > >   iManufacturer           0
> > >   iProduct                2 Jabra SPEAK 410 USB
> > >   iSerial                 3 50C971FEF72Dx010900
> > >
> > > is the bcdDevice related to hardware version or firmware version ?
> >
> > The bcdDevice is the firmware version. So you are running 1.9.0 (the last level is always 0).
> >
> > > >> On our side, we are still using a custom userspace for the Jabra
> > > >> speakers (ie the jabra_vold daemon:
> > > >> https://chromium.googlesource.com/chromiumos/platform/jabra_vold/+/ma
> > > >> ster plus some direct USB interfacing in a Chrome app).
> > > >> while If somebody is using the device another way, we can blacklist
> > > >> it or detach it on our side in the future,  I'm somewhat surprised
> > > >> that it's working well through the HID interface with the Jabra
> > > >> speakerphone 510. Even if there is no longer any basic breakage, in
> > > >> my experience there are other challenges to overcome with the 510
> > > >> firmware (at least the one I had on my devices) e.g. for the volume
> > > >> key to work more than once, you need to do a precise sequence on the USB
> > > audio interface every time one of the volume key is released.
> > > >> Do you have another kernel driver for this ? a userspace software ?
> > > >
> > > > Thank you for your input, Vincent. As mentioned above I can't reproduce the
> > > > volume event storm. I can, however, reproduce the issue you mention, that our
> > > > device only emits an event for the first volume key press. We have a new firmware
> > > > fixing that, so that volume keys now behave sanely on Linux. I would be happy to
> > > > send you the new firmware, if you could find the time to try it out with ChromiumOS.
> > > > Just let me know.
> > >
> > > Sure I can test it, if you have a firmware updater for Linux (ie downloaded firmware
> > > from Jabra website gives me a .dfu file I don't know what I'm supposed to do with)
> >
> > The .dfu file can be programmed into the device using dfu-util (http://dfu-util.sourceforge.net/). The device needs to be put into DFU mode before running dfu-util.
> 
> Along with the firmware version in bcdDevice, this is great news !
> So everybody should have a path to update.
> 
> > Unfortunately, the only way to enter DFU mode is by sending a command over HID -- there is no way to do it on the device.
> > So, to update, the HID blacklisting needs to be removed.
> > I will send you a shell script that puts the device into DFU mode and invokes dfu-util.
> 
> maybe ... or to send a single command, you can also send it directly
> to the USB device rather than through the HID layer.
> It's a bit challenging to write in a shell script (but not
> impossible), my own lame Python one-liner makes my Jabra 410 ring :
> python -c "from ctypes import * ; so = CDLL('libusb-1.0.so') ;
> so.libusb_init(c_void_p()) ;
> so.libusb_control_transfer(so.libusb_open_device_with_vid_pid(None,
> 0x0b0e, 0x0412), 0x21, 0x09, 0x0203, 0x0003, '\x03\x08\0', 3, 5000)"
> it would probably put it in DFU mode if I knew the secret command.

One thing that might be worth considering is to provide the firmware
through LVFS (adding Richard in CC).
Once you figure out whether blacklisting or not the devices at the HID
level, I am sure Richard would be happy to help to have the firmware
upgrades directly handled in LVFS/fwupd so users can just rely on
fwupd to update the devices (and it's just one clic away in
gnome-software).

> 
> >
> > > > Could we remove the blacklisting even if the current firmware behaves a bit "weird"
> > > > with regard to volume button handling?
> > > >  I don't think this quirk is severe enough to warrant the complete blacklisting.
> > >
> > > wrt 'the complete blacklisting', not really it's just disabling instantiating a HID device
> > > by default, the USB device is still there, adventurous people who knows what to do
> > > with it can still ask for the HID device (e.g by passing
> > > 'quirks=0x0b0e:0x0412:0x40000000' as usbhid module parameter to avoid ignoring
> > > it)
> >
> > That's a nice trick, but most end users can't do that.
> 
> most end users cannot use the current firmware either ...

We *could* blacklist depending on the firmware version too.

> Actually plugging the Jabra SPEAK 410 (firmware 1.9) on my workstation
> (running Ubuntu LTS 14.04 with kernel 4.4) has just randomly made my
> mouse misbehave to my great dismay. With the old firmware, not all
> issues are gone.
> 
> 
> > > wrt 'current firmware behaves a bit "weird" with regard to volume button', that was an
> > > example but over the 5 buttons (vol_up, vol_down, mic_mute, call, hang_up), none of
> > > them is behaving properly with just the regular HID driver:
> > > vol_up/down works only once as mentioned earlier, mute/call/hang never sends
> > > events (due to the state the device is in by default). If I remember properly getting
> > > them to work requires to send HID reports
> > > (SET_REPORT) to the device first, ie basically writing a program to do so.
> > > So with no working buttons by default, it's not really interesting to instantiate the
> > > driver ...
> >
> > Yes, the volume buttons have issues. We are fixing it. The other telephony related buttons need a softphone application to help drive the state machine in the device. For example, when you hit the call button a report is issued. Now a softphone must acknowledge that a call is open. If this does not happen, the device will time out and emit a hangup report. If you press hangup with an active call, a hangup report is emiited. If you press hangup without an active call, no report is emitted. So I don't think it's fair to say 'no buttons working'. And it definitely is interesting for us that the HID driver is instantiated. Without it you can't write applications that does call control, firmware update etc.
> 
> You cannot or you can ... actually with the current firmware issues,
> we wrote 2 years chrome.usb application which works well so far.
> 
> 
> >
> > > > As mentioned we have a new firmware coming out now that fixes it.
> > > > And if ChromiumOS intends to continue with jabra_vold and blacklisting in the
> > > > future, I guess there is no conflict?
> > >
> > > Are you planning to provide the new firmware and the updater to the Linux users ?
> > > If so, we might be able to make the quirk conditional on the firmware version ? (hence
> > > my firmware version reading question above)
> >
> > Yes. As mentioned dfu-util can do the update given a tiny shell script wrapper, and the firmware will be available on jabra.com. Also we have a mass deployment tool for corporate Linux based thin client environments.
> >
> > > ChromiumOS devs will do whatever is necessary to keep the current devices
> > > working and avoiding the current userspace daemon would be one less maintenance
> > > burden, but for other Linux users, there is very little value in getting an always broken
> > > HID device unless they can update their devices.
> >
> > Agreed. But it is catch-22 here -  the HID blacklisting needs to be lifted in order for firmware update on a Linux system to be possible.
> 
> I don't think so, as mentioned above.
> It would have been nice to ignore it in HID based on the firmware
> version/bcdUSB but not my call.

I do not see a reason not to. Maybe Jiri will, but the fact that one
version works and one doesn't seem enough to allow such specific
blacklisting.

Cheers,
Benjamin

> 
> -- 
> Vincent

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Jiri Kosina]

On Wed, 13 Sep 2017, benjamin.tissoires@redhat.com wrote:

> I do not see a reason not to. Maybe Jiri will, but the fact that one
> version works and one doesn't seem enough to allow such specific
> blacklisting.

The blacklist matching currently doesn't support that, but it'd be trivial 
to match, and I actually think it generally makes sense to me. So feel 
free (once you guys settle on solution that both Chromium and Jabr folk 
find acceptable) to send this together with a hid-core patch that'd add a 
possibility to perform per-fw-version matching.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Richard Hughes]

On 13 September 2017 at 18:02, benjamin.tissoires@redhat.com
<benjamin.tissoires@redhat.com> wrote:
>> I don't think so, as mentioned above.
>> It would have been nice to ignore it in HID based on the firmware
>> version/bcdUSB but not my call.
>
> I do not see a reason not to. Maybe Jiri will, but the fact that one
> version works and one doesn't seem enough to allow such specific
> blacklisting.

If there's any interest in making the firmware easily upgradable I'd
be happy to help. The fwupd project is already able to upgrade lots of
different type of hardware securely and sanely and we're always
looking for more devices to add to the supported matrix. If this
sounds interesting, please grab me off-cc with details as I'm happy to
help. Thanks!

Richard

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Wed, Sep 13, 2017, vpalatin@google.com wrote:

> On Tue, Sep 12, 2017 at 4:22 PM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> >
> > On Tue, 12 Sep 2017, vpalatin@google.com wrote:
> >
> > > On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@jabra.com>
> wrote:
> > > >
> > > > On Fri, 8 Sep 2017, vpalatin@google.com wrote:
> > > >
> > > >> Re-sending (seems I forgot the HTML subpart that linux-input
> > > >> doesn't
> > > >> like)
> > > >>
> > > >> On Fri, Sep 8, 2017 at 3:13 PM, Jiri Kosina <jikos@kernel.org> wrote:
> > > >> >
> > > >> > On Tue, 5 Sep 2017, nolsen@jabra.com wrote:
> > > >> >
> > > >> > > From: Niels Skou Olsen <nolsen@jabra.com>
> > > >> > >
> > > >> > > Two Jabra speakerphone devices were added to the ignore list
> > > >> > > in
> > > >> > > 2013 because, at the time, the device HID interfaces didn't
> > > >> > > work well with kernel usbhid driver, and could reportedly
> > > >> > > cause volume key event storm.
> > > >> >
> > > >> > Also apparently there was an userspace application that made
> > > >> > use of these keys, and required the usbhid driver to be unbound from them.
> > > >> >
> > > >> > How come this is not the case any more?
> > > >
> > > > I can't really tell why, but it could be that our firmware has
> > > > "improved" since 2013, and maybe also the Linux drivers and user
> > > > mode stuff like PulseAudio have improved the situation. Anyway, I
> > > > don't see the volume event storm issue when I test on a Ubuntu
> > > > desktop with patched 4.4 and 4.13 kernels, and our firmware
> > > > SPEAK410/1.8.0 and SPEAK510/2.10.0.
> > >
> > > A related question: How does I read the firmware on Jabra speaker ?
> > > (see below why)
> > > Pick something which looks like a brand new Jabra SPEAK 410 (Model:
> > > PHS001U P/N 7410 - 219  , Ver.: A120314) gives me :
> > >   idVendor           0x0b0e GN Netcom
> > >   idProduct          0x0412
> > >   bcdDevice            1.09
> > >   iManufacturer           0
> > >   iProduct                2 Jabra SPEAK 410 USB
> > >   iSerial                 3 50C971FEF72Dx010900
> > >
> > > is the bcdDevice related to hardware version or firmware version ?
> >
> > The bcdDevice is the firmware version. So you are running 1.9.0 (the last level is
> always 0).
> >
> > > >> On our side, we are still using a custom userspace for the Jabra
> > > >> speakers (ie the jabra_vold daemon:
> > > >> https://chromium.googlesource.com/chromiumos/platform/jabra_vold/
> > > >> +/ma ster plus some direct USB interfacing in a Chrome app).
> > > >> while If somebody is using the device another way, we can
> > > >> blacklist it or detach it on our side in the future,  I'm
> > > >> somewhat surprised that it's working well through the HID
> > > >> interface with the Jabra speakerphone 510. Even if there is no
> > > >> longer any basic breakage, in my experience there are other
> > > >> challenges to overcome with the 510 firmware (at least the one I
> > > >> had on my devices) e.g. for the volume key to work more than
> > > >> once, you need to do a precise sequence on the USB
> > > audio interface every time one of the volume key is released.
> > > >> Do you have another kernel driver for this ? a userspace software ?
> > > >
> > > > Thank you for your input, Vincent. As mentioned above I can't
> > > > reproduce the volume event storm. I can, however, reproduce the
> > > > issue you mention, that our device only emits an event for the
> > > > first volume key press. We have a new firmware fixing that, so
> > > > that volume keys now behave sanely on Linux. I would be happy to send you
> the new firmware, if you could find the time to try it out with ChromiumOS.
> > > > Just let me know.
> > >
> > > Sure I can test it, if you have a firmware updater for Linux (ie
> > > downloaded firmware from Jabra website gives me a .dfu file I don't
> > > know what I'm supposed to do with)
> >
> > The .dfu file can be programmed into the device using dfu-util (http://dfu-
> util.sourceforge.net/). The device needs to be put into DFU mode before running dfu-
> util.
>
> Along with the firmware version in bcdDevice, this is great news !
> So everybody should have a path to update.
>
> > Unfortunately, the only way to enter DFU mode is by sending a command over HID
> -- there is no way to do it on the device.
> > So, to update, the HID blacklisting needs to be removed.
> > I will send you a shell script that puts the device into DFU mode and invokes dfu-
> util.
>
> maybe ... or to send a single command, you can also send it directly to the USB
> device rather than through the HID layer.
> It's a bit challenging to write in a shell script (but not impossible), my own lame
> Python one-liner makes my Jabra 410 ring :
> python -c "from ctypes import * ; so = CDLL('libusb-1.0.so') ;
> so.libusb_init(c_void_p()) ;
> so.libusb_control_transfer(so.libusb_open_device_with_vid_pid(None,
> 0x0b0e, 0x0412), 0x21, 0x09, 0x0203, 0x0003, '\x03\x08\0', 3, 5000)"
> it would probably put it in DFU mode if I knew the secret command.

Mmm, that's nice. That might come in handy, thanks for sharing!

> >
> > > > Could we remove the blacklisting even if the current firmware behaves a bit
> "weird"
> > > > with regard to volume button handling?
> > > >  I don't think this quirk is severe enough to warrant the complete blacklisting.
> > >
> > > wrt 'the complete blacklisting', not really it's just disabling
> > > instantiating a HID device by default, the USB device is still
> > > there, adventurous people who knows what to do with it can still ask
> > > for the HID device (e.g by passing 'quirks=0x0b0e:0x0412:0x40000000'
> > > as usbhid module parameter to avoid ignoring
> > > it)
> >
> > That's a nice trick, but most end users can't do that.
>
> most end users cannot use the current firmware either ...
> Actually plugging the Jabra SPEAK 410 (firmware 1.9) on my workstation (running
> Ubuntu LTS 14.04 with kernel 4.4) has just randomly made my mouse misbehave to
> my great dismay. With the old firmware, not all issues are gone.

That's not really an issue with our HID interface. The root cause is that hid-core in hidinput_configure_usage() by default maps some vendor defined input field usages to mouse button (and other) events that the X11 server picks up. Vendor defined usages should not be default mapped to generic events. I have posted another patch that solves this by adding a vendor specific HID driver which prevents mapping of Jabra vendor defined usages. (See: http://www.spinics.net/lists/linux-input/msg53022.html)

> > > wrt 'current firmware behaves a bit "weird" with regard to volume
> > > button', that was an example but over the 5 buttons (vol_up,
> > > vol_down, mic_mute, call, hang_up), none of them is behaving properly with just
> the regular HID driver:
> > > vol_up/down works only once as mentioned earlier, mute/call/hang
> > > never sends events (due to the state the device is in by default).
> > > If I remember properly getting them to work requires to send HID
> > > reports
> > > (SET_REPORT) to the device first, ie basically writing a program to do so.
> > > So with no working buttons by default, it's not really interesting
> > > to instantiate the driver ...
> >
> > Yes, the volume buttons have issues. We are fixing it. The other telephony related
> > buttons need a softphone application to help drive the state machine in the device.
> > For example, when you hit the call button a report is issued. Now a softphone must
> > acknowledge that a call is open. If this does not happen, the device will time out and
> > emit a hangup report. If you press hangup with an active call, a hangup report is
> > emiited. If you press hangup without an active call, no report is emitted. So I don't
> > think it's fair to say 'no buttons working'. And it definitely is interesting for us that the
> > HID driver is instantiated. Without it you can't write applications that does call control,
> > firmware update etc.
>
> You cannot or you can ... actually with the current firmware issues, we wrote 2 years
> chrome.usb application which works well so far.
>
>
> >
> > > > As mentioned we have a new firmware coming out now that fixes it.
> > > > And if ChromiumOS intends to continue with jabra_vold and
> > > > blacklisting in the future, I guess there is no conflict?
> > >
> > > Are you planning to provide the new firmware and the updater to the Linux users
> ?
> > > If so, we might be able to make the quirk conditional on the
> > > firmware version ? (hence my firmware version reading question
> > > above)
> >
> > Yes. As mentioned dfu-util can do the update given a tiny shell script wrapper, and
> the firmware will be available on jabra.com. Also we have a mass deployment tool for
> corporate Linux based thin client environments.
> >
> > > ChromiumOS devs will do whatever is necessary to keep the current
> > > devices working and avoiding the current userspace daemon would be
> > > one less maintenance burden, but for other Linux users, there is
> > > very little value in getting an always broken HID device unless they can update
> their devices.
> >
> > Agreed. But it is catch-22 here -  the HID blacklisting needs to be lifted in order for
> firmware update on a Linux system to be possible.
>
> I don't think so, as mentioned above.
> It would have been nice to ignore it in HID based on the firmware version/bcdUSB but
> not my call.

Yes, let's try to augment the ignore feature to include firmware version where needed.

Thanks,
Niels
**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Wed, Sep 14 2017, benjamin.tissoires@redhat.com wrote:

> [adding Richard, the LVFS maintainer]
>
> On Sep 13 2017 or thereabouts, Vincent Palatin wrote:
> > On Tue, Sep 12, 2017 at 4:22 PM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> > >
> > > On Tue, 12 Sep 2017, vpalatin@google.com wrote:
> > >
> > > > On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> > > > >
> > > > > On Fri, 8 Sep 2017, vpalatin@google.com wrote:

[ snip ]

> One thing that might be worth considering is to provide the firmware through LVFS
> (adding Richard in CC).
> Once you figure out whether blacklisting or not the devices at the HID level, I am sure
> Richard would be happy to help to have the firmware upgrades directly handled in
> LVFS/fwupd so users can just rely on fwupd to update the devices (and it's just one
> clic away in gnome-software).

Yes, it would be very nice indeed to distribute our firmware for Linux users through LVFS.
Can the LVFS architecture handle proprietary (ie. closed source) updaters? Not all our
devices can be updated using dfu-util, and I am not sure all the updater code can be
open sourced.

> > > > > Could we remove the blacklisting even if the current firmware behaves a bit
> > > > > "weird" with regard to volume button handling?
> > > > >  I don't think this quirk is severe enough to warrant the complete blacklisting.
> > > >
> > > > wrt 'the complete blacklisting', not really it's just disabling
> > > > instantiating a HID device by default, the USB device is still
> > > > there, adventurous people who knows what to do with it can still
> > > > ask for the HID device (e.g by passing
> > > > 'quirks=0x0b0e:0x0412:0x40000000' as usbhid module parameter to
> > > > avoid ignoring
> > > > it)
> > >
> > > That's a nice trick, but most end users can't do that.
> >
> > most end users cannot use the current firmware either ...
>
> We *could* blacklist depending on the firmware version too.

Yes, let's work on that!

Thanks,
Niels

**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Wed, 13 Sep 2017, jikos@kernel.org wrote:

> On Wed, 13 Sep 2017, benjamin.tissoires@redhat.com wrote:
>
> > I do not see a reason not to. Maybe Jiri will, but the fact that one
> > version works and one doesn't seem enough to allow such specific
> > blacklisting.
>
> The blacklist matching currently doesn't support that, but it'd be trivial to match, and I
> actually think it generally makes sense to me. So feel free (once you guys settle on
> solution that both Chromium and Jabr folk find acceptable) to send this together with
> a hid-core patch that'd add a possibility to perform per-fw-version matching.

Great! Shall I give it a shot? Or is there someone with more intimate knowledge
about hid-core that wants to do it?

How should it work?

A simple setup would be to attach an optional list of blacklisted firmware versions
to each entry in hid_ignore_list[]? If this list is empty, all firmware versions are
blacklisted. The attached list could just be a static array. Would this be acceptable?

Thanks,
Niels

**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Wed, Sep 13 2017, hughsient@gmail.com wrote:

> On 13 September 2017 at 18:02, benjamin.tissoires@redhat.com
> <benjamin.tissoires@redhat.com> wrote:
> >> I don't think so, as mentioned above.
> >> It would have been nice to ignore it in HID based on the firmware
> >> version/bcdUSB but not my call.
> >
> > I do not see a reason not to. Maybe Jiri will, but the fact that one
> > version works and one doesn't seem enough to allow such specific
> > blacklisting.
>
> If there's any interest in making the firmware easily upgradable I'd be happy to help.
> The fwupd project is already able to upgrade lots of different type of hardware
> securely and sanely and we're always looking for more devices to add to the
> supported matrix. If this sounds interesting, please grab me off-cc with details as I'm
> happy to help. Thanks!

Thanks Richard, that sounds good! I will reach out to you off-list.

Thanks,
Niels

**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************

Re: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Vincent Palatin]

On Fri, Sep 15, 2017 at 9:52 AM, Niels Skou Olsen <nolsen@jabra.com> wrote:
> On Wed, 13 Sep 2017, jikos@kernel.org wrote:
>
>> On Wed, 13 Sep 2017, benjamin.tissoires@redhat.com wrote:
>>
>> > I do not see a reason not to. Maybe Jiri will, but the fact that one
>> > version works and one doesn't seem enough to allow such specific
>> > blacklisting.
>>
>> The blacklist matching currently doesn't support that, but it'd be trivial to match, and I
>> actually think it generally makes sense to me. So feel free (once you guys settle on
>> solution that both Chromium and Jabr folk find acceptable) to send this together with
>> a hid-core patch that'd add a possibility to perform per-fw-version matching.
>
> Great! Shall I give it a shot? Or is there someone with more intimate knowledge
> about hid-core that wants to do it?
>
> How should it work?
>
> A simple setup would be to attach an optional list of blacklisted firmware versions
> to each entry in hid_ignore_list[]? If this list is empty, all firmware versions are
> blacklisted. The attached list could just be a static array. Would this be acceptable?

Where the firmware version is stored (eg here in bcdUSB)  is neither
really defined nor available at the pure HID level (ie you likely need
the USB descriptors). So probably you want to remove the Jabra devices
from the hid_ignore_list[] and add the new versioned quirk returning
HID_QUIRK_IGNORE in usbhid_lookup_quirk() [in
drivers/hid/usbhid/hid-quirks.c]. It seems we can either create a new
list with USB VID/PID/min bcdUSB or actually just add some code for it
as this might not extend to tons of devices, but the maintainers can
give guidance on this point.

-- 
Vincent

RE: [PATCH] HID: Remove Jabra speakerphone devices from ignore list

[Niels Skou Olsen]

On Wed, 13 Sep 2017, jikos@kernel.org wrote:

> On Wed, 13 Sep 2017, benjamin.tissoires@redhat.com wrote:
>
> > I do not see a reason not to. Maybe Jiri will, but the fact that one
> > version works and one doesn't seem enough to allow such specific
> > blacklisting.
>
> The blacklist matching currently doesn't support that, but it'd be trivial to match, and I
> actually think it generally makes sense to me. So feel free (once you guys settle on
> solution that both Chromium and Jabr folk find acceptable) to send this together with
> a hid-core patch that'd add a possibility to perform per-fw-version matching.

I believe that ChromiumOS and Jabra agree on a firmware version based
blacklisting of these 2 devices.  We release new firmwares for the 2
devices and add code to ignore the HID interface on all previous versions.

We have discussed using 'bcdDevice' for this. I am afraid the bcdDevice
field won't cut it as firmware version for devices in general. In all
descriptions I have seen, the field is a vendor defined device release
number. In the USB 3.1 spec, bcdDevice is described like this:

  "Device release number in binary-coded decimal"

For Jabra devices the bcdDevice contains the firmware version, but it is
vendor specific. So I don't think it makes sense to come up with
a generic mechanism based on this.

Therefore, my proposal is to handle this in the vendor switch in
hid_ignore(). I could add a case for Jabra that checks
bcdDevice against a known good version.

To access bcdDevice we can do something like this:

u16 hid_get_bcd_device(struct hid_device *hdev)
{
    struct usb_device *usbdev =
        interface_to_usbdev(to_usb_interface(hdev->dev.parent));

   return le16_to_cpu(usbdev->descriptor.bcdDevice);
}

There are several vendor specific drivers that do something
along these lines. Would this be OK in hid-core.c? I have tested

Comments welcome, thanks.
Niels

**** GN GROUP NOTICE - AUTOMATICALLY INSERTED**** The information in this e-mail (including attachments, if any) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Any opinions expressed in this e-mail are those of the individual and not necessarily the GN group. Thank you. ******************** DISCLAIMER END ************************