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) 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. 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? > > 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
