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 ? > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
