A small update: When the modemmanager finishes probing (~16 secs after connection) data seems to stop flowing in from the WebUSB bulk endpoint also. It is, however, possible to reconnect and get data again - so I need to see if there should be anything in the mbed firmware causing that behavior or there is some sort of silent reset of interfaces/endpoints happening on the linux side when probing is done.
On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen <lar...@gmail.com> wrote: > I finally managed to make a configuration that *seems* to work and I > realize that I may have had something else blocking the WebUSB interface > (2) while modemmanager was communicating with the CDC_ACM interface (1). > > I made a clean arbitrary VID/PID and get what seems to be a functioning > WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface - > so while I thought the modemmanager grabbed my WebUSB interface part, it > must have been because of a faulty combination on my side - my apologies. > WebUSB actually *does* seem to give immediate "bulk" access to a device > otherwise claimed by modemmanager - a very nice option to have and sorry > for the confusion I had that modemmanager grabbed more interfaces than it > should have. > > Still, the original request still stands and please tell me if it's a > viable path: > > 1. If a device has a WebUSB descriptor, it's most probably *not* a modem > - and should in stead be considered a device that in this rare case needs > to be whitelisted (as modem), while defaulting to not being it. This is to > ease the usage from non-browsers to the same hardware, which can then > happen immediately and not be required to fail and wait over the > modemmanager probing period (30 sec?) - related to modemmanager > 2. If a device has a WebUSB descriptor, at least the interface linked to > WebUSB should be made accessible in user land by default so no average user > has to figure out how to do udev rules - related to udev/systemd > > my headers that seem to work now for the case above: > > Bus 002 Device 089: ID 1209:d010 InterBiometrics > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.10 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x1209 InterBiometrics > idProduct 0xd010 > bcdDevice 0.01 > iManufacturer 1 empriKit > iProduct 2 empriKit|MOTION > iSerial 3 00.01 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 90 > bNumInterfaces 3 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 1 AT-commands (v.25ter) > iInterface 0 > CDC Header: > bcdCDC 1.10 > CDC Call Management: > bmCapabilities 0x03 > call management > use DataInterface > bDataInterface 1 > CDC ACM: > bmCapabilities 0x02 > line coding and serial state > CDC Union: > bMasterInterface 0 > bSlaveInterface 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0010 1x 16 bytes > bInterval 16 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 10 CDC Data > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x05 EP 5 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Binary Object Store Descriptor: > bLength 5 > bDescriptorType 15 > wTotalLength 29 > bNumDeviceCaps 1 > ** UNRECOGNIZED: 18 10 05 00 38 b6 08 34 a9 09 a0 47 8b fd a0 76 88 15 > b6 65 00 01 57 02 > Device Status: 0x0001 > Self Powered > > > On Mon, Jan 9, 2017 at 10:32 PM, Reilly Grant <m...@reilly.io> wrote: > >> On 2017-01-09 9:55 am, Greg KH wrote: >> >>> On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote: >>> >>>> Greg KH <g...@kroah.com> writes: >>>> > On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen >>>> wrote: >>>> >> Web USB can only grab devices which has special Web USB headers. It >>>> can not >>>> >> grab any USB device. >>>> >> >>>> >> https://wicg.github.io/webusb/#webusb-descriptors >>>> > >>>> > Ah, fun :( >>>> > >>>> > So, we can add a quirk into the kernel cdc-acm driver to never bind >>>> to a >>>> > device that has the wusb platform capability descriptor, >>>> >>>> I fail to see why a quirk should be necessary. New device classes are >>>> expected to use new class/subclass codes distintly different from >>>> anything handled by existing class drivers. >>>> >>> >>> One would hope, but it seems like they want to piggy-back on the cdc-acm >>> spec. But I could be totally wrong here, does anyone have the actual >>> descriptor dump of a device anywhere? >>> >> >> We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should >> always have its interfaces marked vendor-specific. Below is an example of a >> device which implements both a CDC-ACM interface and a WebUSB interface. As >> far as I've noticed ModemManager has not interfered with the browser >> accessing this device but Lars has observed this behavior. What I have had >> to do, however, is add a udev rule which sets ownership on the devnode so >> that the browser can access it as an unprivileged user-space application. >> What would be nice to have from systemd-udevd is a way to write a rule that >> will detect the presence of WebUSB descriptors (which is a BOS capability >> descriptor) and set ownership accordingly. >> >> Bus 002 Device 040: ID 2341:8037 Arduino SA >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 2.10 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 64 >> idVendor 0x2341 Arduino SA >> idProduct 0x8037 >> bcdDevice 1.00 >> iManufacturer 1 Arduino LLC >> iProduct 2 Arduino Micro >> iSerial 3 WUARTR >> bNumConfigurations 1 >> Configuration Descriptor: >> bLength 9 >> bDescriptorType 2 >> wTotalLength 98 >> bNumInterfaces 3 >> bConfigurationValue 1 >> iConfiguration 0 >> bmAttributes 0xa0 >> (Bus Powered) >> Remote Wakeup >> MaxPower 500mA >> Interface Association: >> bLength 8 >> bDescriptorType 11 >> bFirstInterface 0 >> bInterfaceCount 2 >> bFunctionClass 2 Communications >> bFunctionSubClass 2 Abstract (modem) >> bFunctionProtocol 1 AT-commands (v.25ter) >> iFunction 0 >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 0 >> bAlternateSetting 0 >> bNumEndpoints 1 >> bInterfaceClass 2 Communications >> bInterfaceSubClass 2 Abstract (modem) >> bInterfaceProtocol 0 None >> iInterface 0 >> CDC Header: >> bcdCDC 1.10 >> CDC Call Management: >> bmCapabilities 0x01 >> call management >> bDataInterface 1 >> CDC ACM: >> bmCapabilities 0x06 >> sends break >> line coding and serial state >> CDC Union: >> bMasterInterface 0 >> bSlaveInterface 1 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x81 EP 1 IN >> bmAttributes 3 >> Transfer Type Interrupt >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0010 1x 16 bytes >> bInterval 64 >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 1 >> bAlternateSetting 0 >> bNumEndpoints 2 >> bInterfaceClass 10 CDC Data >> bInterfaceSubClass 0 Unused >> bInterfaceProtocol 0 >> iInterface 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x02 EP 2 OUT >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0040 1x 64 bytes >> bInterval 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x83 EP 3 IN >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0040 1x 64 bytes >> bInterval 0 >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 2 >> bAlternateSetting 0 >> bNumEndpoints 2 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 0 >> bInterfaceProtocol 0 >> iInterface 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x04 EP 4 OUT >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0040 1x 64 bytes >> bInterval 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x85 EP 5 IN >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0040 1x 64 bytes >> bInterval 0 >> Binary Object Store Descriptor: >> bLength 5 >> bDescriptorType 15 >> wTotalLength 57 >> bNumDeviceCaps 2 >> FIXME: alloc bigger buffer for device capability descriptors >> Device Status: 0x0000 >> (Bus Powered) >> >> >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel