<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jan 10, 2017 07:51, "Greg KH" <<a href="mailto:greg@kroah.com">greg@kroah.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:<br>
> On <a href="tel:2017-01-09" value="+4520170109">2017-01-09</a> 9:55 am, Greg KH wrote:<br>
> > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:<br>
> > > Greg KH <<a href="mailto:greg@kroah.com">greg@kroah.com</a>> writes:<br>
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen wrote:<br>
> > > >> Web USB can only grab devices which has special Web USB headers. It can not<br>
> > > >> grab any USB device.<br>
> > > >><br>
> > > >> <a href="https://wicg.github.io/webusb/#webusb-descriptors" rel="noreferrer" target="_blank">https://wicg.github.io/webusb/<wbr>#webusb-descriptors</a><br>
> > > ><br>
> > > > Ah, fun :(<br>
> > > ><br>
> > > > So, we can add a quirk into the kernel cdc-acm driver to never bind to a<br>
> > > > device that has the wusb platform capability descriptor,<br>
> > ><br>
> > > I fail to see why a quirk should be necessary. New device classes are<br>
> > > expected to use new class/subclass codes distintly different from<br>
> > > anything handled by existing class drivers.<br>
> ><br>
> > One would hope, but it seems like they want to piggy-back on the cdc-acm<br>
> > spec.  But I could be totally wrong here, does anyone have the actual<br>
> > descriptor dump of a device anywhere?<br>
><br>
> We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should<br>
> always have its interfaces marked vendor-specific. Below is an example of a<br>
> device which implements both a CDC-ACM interface and a WebUSB interface.<br>
<br>
</div>Ick, why would you want both interfaces on a device?  Are you going to<br>
allow firmware to talk to both endpoints at the same time?  Why?<br>
<br>
Why not just make it a "one interface" type of device?<br></blockquote></div></div></div><div dir="auto">I work for a medical company, where we are using long lived software and hardware. Having the option of supporting both WebUSB and USB serial will allow us to move to pure web and still support legacy platforms.</div><div dir="auto"><br></div><div dir="auto">If we - in stead - were to only have WebUSB or standard CDC, we would force an impossible break.</div><div dir="auto"><br></div><div dir="auto">Having modemmanager estimating that "this WebUSB device is *probably* not a modem" and furthermore allowing user access to that device (udev/systems) would be a huge help in the direction of true PnP for users and manufacturers.</div><div dir="auto"><br></div><div dir="auto">Yesterday night I finally got WebUSB and MM running in parallel (so..Sorta halfway there on Linux at least): <a href="https://twitter.com/denladeside/status/818717316443676672">https://twitter.com/denladeside/status/818717316443676672</a></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
thanks,<br>
<br>
greg k-h<br>
</blockquote></div><br></div></div></div>