[systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 18:56, "Bjørn Mork" <bjorn at mork.no> wrote:

> Lars Knudsen <larsgk at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170109/6af24cd8/attachment.html>