On Tue, 12 Sep 2017, vpalatin@xxxxxxxxxx wrote: > On Mon, Sep 11, 2017 at 11:27 AM, Niels Skou Olsen <nolsen@xxxxxxxxx> wrote: > > > > On Fri, 8 Sep 2017, vpalatin@xxxxxxxxxx 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@xxxxxxxxxx> wrote: > >> > > >> > On Tue, 5 Sep 2017, nolsen@xxxxxxxxx wrote: > >> > > >> > > From: Niels Skou Olsen <nolsen@xxxxxxxxx> > >> > > > >> > > 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 ************************ ��.n��������+%������w��{.n�����{��)��^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
