On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote: > On Jan 9, 2017 18:56, "Bjørn Mork" <bj...@mork.no> wrote: > > > Lars Knudsen <lar...@gmail.com> writes: > > > > > It seemed like if just one interface in the description list was > > > somehow > > > compliant with modem manager, the full device seemed claimed. > > > > > > I may have missed something in my headers while experimenting. > > > Can you > > > > give > > > an example of a header structure that will not be assumed to be a > > > modem > > > > by > > > MM while still accessible as a proper CDC serial device - without > > > blacklisting anything? > > > > I am slowly starting to wonder if the concern is about composite > > devices > > where you want a subset of the functions to be used in one context > > (MM) > > and another subset to be used in another context (WebUSB)? Is this > > correct? > > > > Well, ideally, any WebUSB device that exposes a CDC interface (e.g. > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK) > would: > > 1) not be considered a modem (it would not make sense to do a modem > including webusb headers - in the same device mode at least) > 2) provide standard /dev/ttyUSBx serial functionality on the standard > CDC > endpoints (e.g. interface 1 above) > 3) provide full user access to the WebUSB CDC/BULK interface (2 > above)
So I read the spec quickly but clearly not well enough. Is the separate WebUSB interface parallel to the others in functionality? eg, it's just another conduit for the same information as the other interfaces? Or is it some other completely separate protocol? Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled with AT commands, like a Nokia 21M-02. It exposes 8 interfaces; 3 ttys and one ethernet device: 0 - cdc-acm commc 1 - cdc-acm data 2 - cdc-acm commc 3 - cdc-acm data 4 - cdc-acm commc 5 - cdc-acm data 6 - cdc-ether commc 7 - cdc-ether data Now if that supported webusb, would you have: 8 - webusb If that is true, then what is supposed to happen with this modem when you plug it in? Just because it has a WebUSB descriptor, should it be automatically "claimed" by a running browser or such, and be unavailable to the rest of the system? Would all the ttys and ethernet devs be re-permissioned to the browser user? Or, could you expand on "it wouldn't make sense" to do a modem with WebUSB descriptors? Why not? > What I was asking before is for an example header/configuration > descriptors > where MM would *not* pick up the CDC interface but the system still > creating a /dev/ttyUSBx device (or ttyACMx - which it's called when > MM is > installed) - without creating blacklisting rules specifically for > e.g. > *that* VID/PID combo. It depends. If MM is running and MM has been configured to probe devices (which can be easily changed with udev rules) then MM will probe and claim any device that it determines is a modem, including devices that expose ttys that respond to queries like AT+GCAP indicating they support WWAN standards. Also including cdc-wdm devices that speak QMI or MBIM or AT. So it's certianly possible to configure the scenario you're trying, if you use udev rules to blacklist devices or if you disable probing entirely. If you can write udev rules that detect the presence of a webusb descriptor, then you can disable MM probing for that device too. > When I was experimenting the last few days - this did not seem > possible. I > had to completely wipe any indication of this device being CDC before > MM > stopped claiming it. Surely, MM should not pick it up if the device > indicates it doesn't have call functionality? MM disregards the "call functionality" part because only Nokia and Ericsson ever actually filled that in. Nobody really cares about getting the detailed parts of cdc-acm correct, and because there's no real certification or anything, nobody bothered. So these fields are essentially useless in the real world. Same reason some vendors put "0123456789abcdef" into the USB serial number field for *every single device* of a given VID/PID. You simply cannot rely on vendors getting descriptors correct. Dan > > > > If so, then I believe you won't be able handle that in a single > > configuration. If you mix all functions in a single configuration > > then > > you are correct that MM will take control of the device based on > > the > > functions it (or the kernel) supports. > > > > Split the function subsets in different configurations and make the > > OS > > and/or userspace select the active one if you need to support these > > different use cases. Anything else is going to be an endless mess > > of > > workarounds and quirk lists all over the place. > > > > > > Bjørn > > > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
