From: Alan Stern <stern@rowland.harvard.edu>
To: Dmitrii Pasechnik <dima.pasechnik@cs.ox.ac.uk>
Cc: Greg KH <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org
Subject: Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
Date: Sat, 24 Dec 2022 11:00:25 -0500 [thread overview]
Message-ID: <Y6ciGZ1D0Hcb6Uua@rowland.harvard.edu> (raw)
In-Reply-To: <Y6Y8j9pvgevaKd1l@hilbert>
On Fri, Dec 23, 2022 at 11:41:03PM +0000, Dmitrii Pasechnik wrote:
> On Fri, Dec 23, 2022 at 09:52:50AM -0500, Alan Stern wrote:
> > On Fri, Dec 23, 2022 at 12:58:41PM +0000, Dmitrii Pasechnik wrote:
> > > On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> > > > A bit off to the side from the main point of this thread, but...
> > > >
> > > > On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > > > >
> > > > >
> > > > > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > > > > >
> > > > > >Which agrees with the information on the web site. I have no idea what
> > > > > >WebUSB is supposed to be.
> > > > >
> > > > > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > > > >
> > > > > https://en.wikipedia.org/wiki/WebUSB
> > > >
> > > > The Wikipedia article agrees with you that WebUSB is a JavaScript API.
> > > > As such, it is used for communication between web browsers and
> > > > JavaScript programs.
> > >
> > > No, it's used by browsers (which run JavaScript code in them) to
> > > communicate with USB hardware. Or, if you like,
> > > standalone JavaScript programs to communicate with USB hardware.
> > > Let me copy from the wiki here:
> > >
> > > ---------------------------------
> > > A Universal Serial Bus, or a USB is an industry standard [...]
> > > WebUSB is a set of API calls that enable access to these hardware
> > > devices from web pages. WebUSB is developed by the World Wide Web
> > > Consortium(W3C).[1] The webUSB API provides a safe, and developer
> > > familiar means of communication to edges devices from web pages. The
> > > webUSB API integrates into existing USB libraries and shortens the
> > > development cycle for integrating new devices into the web environment
> > > by not needing to wait for browser support for these devices.
> > >
> > > Early versions of webUSB came out around as an alternative to Flash,
> > > Chrome Serial, and other custom approaches to connecting browsers to
> > > hardware. WebUSB aims to solve the four goals of any interface being;
> > > fast to make, cross platform, look good, accessibility.
> > >
> > > > Not for communication between programs and USB
> > > > devices. So I don't understand why a USB device needs to be concerned
> > > > about it.
> > >
> > > I hope the above explains.
> >
> > Actually, it's ambiguous.
> >
> > The article says that WebUSB is an API used by JavaScript programs when
> > they want to interact with a USB device. Which means it is something
> > that JavaScript programs can know about and interact with. Fine.
> >
> > But the article doesn't say what happens on the device's side of the
> > conversation. Does the WebUSB framework use some special messages when
> > communicating with a USB device, so it will only work with devices which
> > support WebUSB's protocol, or does it use plain ordinary USB messages
> > which any USB device will support?
> >
> > To put it another way, do USB devices need to have specialized firmware
> > in order to be compatible with WebUSB, or will WebUSB work with all USB
> > devices? If the latter is true then why does the BBC micro:bit device
> > have a special WebUSB interface? Does the extra interface provide some
> > sort of device-specific information which WebUSB can make use of but
> > which isn't essential?
>
> here is what I could find about the device side of WebUSB: https://web.dev/build-for-webusb/
> Basically, WebUSB support offers some extras, e.g. one can get a
> specific pop-up with a URL in it (supplied by the board) in the web browser as
> the device is plugged in the USB port.
>
> Also, on the software side, this: https://developer.chrome.com/articles/usb/
> is more informative than the Wikipedia article.
> And here is how WebUSB-capable device is meant to talk ot the machine
> it's plugged in: https://wicg.github.io/webusb/#webusb-platform-capability-descriptor
Those are very helpful, thank you.
Interestingly, none of those documents mentions anything about having a
special WebUSB interface in the configuration. The WebUSB information
on a device is accessed using standard or vendor-specific control
messages with the device (not an interface) as recipient. So the
question of why the micro:bit has a WebUSB interface remains a
mystery...
Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: "Jó Ágila Bitsch" <jgilab@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
Dmitrii Pasechnik <dima.pasechnik@cs.ox.ac.uk>
Subject: Re: usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised
Date: Sat, 31 Dec 2022 20:49:08 +0100 [thread overview]
Message-ID: <Y6ciGZ1D0Hcb6Uua@rowland.harvard.edu> (raw)
Message-ID: <20221231194908.xPnXjP2ae6k7YyF9WGxQW3xMpLAPNoY2jKydMdB_k5k@z> (raw)
> On Fri, Dec 23, 2022 at 11:41:03PM +0000, Dmitrii Pasechnik wrote:
> > On Fri, Dec 23, 2022 at 09:52:50AM -0500, Alan Stern wrote:
> > > On Fri, Dec 23, 2022 at 12:58:41PM +0000, Dmitrii Pasechnik wrote:
> > > > On Thu, Dec 22, 2022 at 04:24:55PM -0500, Alan Stern wrote:
> > > > > A bit off to the side from the main point of this thread, but...
> > > > >
> > > > > On Thu, Dec 22, 2022 at 10:32:09AM +0000, Dima Pasechnik wrote:
> > > > > >
> > > > > >
> > > > > > On 20 December 2022 19:57:05 WET, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > > > >> USB Interfaces: MSD, CDC, HID, WebUSB
> > > > > > >
> > > > > > >Which agrees with the information on the web site. I have no idea what
> > > > > > >WebUSB is supposed to be.
> > > > > >
> > > > > > WebUSB is a JavaScript API, supported by Chromium -derived browsers (Firefox not there yet)
> > > > > >
> > > > > > https://en.wikipedia.org/wiki/WebUSB
> > > > >
> > > > > The Wikipedia article agrees with you that WebUSB is a JavaScript API.
> > > > > As such, it is used for communication between web browsers and
> > > > > JavaScript programs.
> > > >
> > > > No, it's used by browsers (which run JavaScript code in them) to
> > > > communicate with USB hardware. Or, if you like,
> > > > standalone JavaScript programs to communicate with USB hardware.
> > > > Let me copy from the wiki here:
> > > >
> > > > ---------------------------------
> > > > A Universal Serial Bus, or a USB is an industry standard [...]
> > > > WebUSB is a set of API calls that enable access to these hardware
> > > > devices from web pages. WebUSB is developed by the World Wide Web
> > > > Consortium(W3C).[1] The webUSB API provides a safe, and developer
> > > > familiar means of communication to edges devices from web pages. The
> > > > webUSB API integrates into existing USB libraries and shortens the
> > > > development cycle for integrating new devices into the web environment
> > > > by not needing to wait for browser support for these devices.
> > > >
> > > > Early versions of webUSB came out around as an alternative to Flash,
> > > > Chrome Serial, and other custom approaches to connecting browsers to
> > > > hardware. WebUSB aims to solve the four goals of any interface being;
> > > > fast to make, cross platform, look good, accessibility.
> > > >
> > > > > Not for communication between programs and USB
> > > > > devices. So I don't understand why a USB device needs to be concerned
> > > > > about it.
> > > >
> > > > I hope the above explains.
> > >
> > > Actually, it's ambiguous.
> > >
> > > The article says that WebUSB is an API used by JavaScript programs when
> > > they want to interact with a USB device. Which means it is something
> > > that JavaScript programs can know about and interact with. Fine.
> > >
> > > But the article doesn't say what happens on the device's side of the
> > > conversation. Does the WebUSB framework use some special messages when
> > > communicating with a USB device, so it will only work with devices which
> > > support WebUSB's protocol, or does it use plain ordinary USB messages
> > > which any USB device will support?
> > >
> > > To put it another way, do USB devices need to have specialized firmware
> > > in order to be compatible with WebUSB, or will WebUSB work with all USB
> > > devices? If the latter is true then why does the BBC micro:bit device
> > > have a special WebUSB interface? Does the extra interface provide some
> > > sort of device-specific information which WebUSB can make use of but
> > > which isn't essential?
> >
> > here is what I could find about the device side of WebUSB: https://web.dev/build-for-webusb/
> > Basically, WebUSB support offers some extras, e.g. one can get a
> > specific pop-up with a URL in it (supplied by the board) in the web browser as
> > the device is plugged in the USB port.
> >
> > Also, on the software side, this: https://developer.chrome.com/articles/usb/
> > is more informative than the Wikipedia article.
> > And here is how WebUSB-capable device is meant to talk ot the machine
> > it's plugged in: https://wicg.github.io/webusb/#webusb-platform-capability-descriptor
>
> Those are very helpful, thank you.
>
> Interestingly, none of those documents mentions anything about having a
> special WebUSB interface in the configuration. The WebUSB information
> on a device is accessed using standard or vendor-specific control
> messages with the device (not an interface) as recipient. So the
> question of why the micro:bit has a WebUSB interface remains a
> mystery...
>
> Alan Stern
I may be able to shed some light on this:
TLDR:
There are 2 separate "serial" interfaces, one to control via the normal OS character device,
and one to connect to via a browser.
More details:
The reason for this additional interface is that WebUSB does not have any facilities
to detach the kernel driver, so once the kernel claimed a specific interface, say
/dev/ttyACM0, it is no longer accessible to WebUSB. (It would still be able to access the
serial port via WebSerial, but that browser feature is newer than WebUSB.)
The way out for Micro:bit and many similar boards, is to provide an additional vendor-specific
interface, that provides the same functionality as serial/ACM, but uses different class
descriptors, so the kernel doesn't claim it and a Javascript application can access it.
Therefore, you can access the device via the browser AND via /dev/ttyACM0.
This allows more flexibility for the user to use either mechanism.
Therefore, it would actually defeat the purpose, if the OS claimed that extra serial interface
itself, as the browser could no longer claim it.
Then again, the better way to implement this specific feature would probably for the website
to use WebSerial to access the serial port instead.
Incidentally, I posted a patch yesterday, that would allow Linux-based USB gadgets to
announce it's WebUSB landing page URL via a device capability BOS descriptor and a
WebUSB-defined vendor specific call. This implements the optional device side parts of WebUSB,
that enables better discoverability from the user side.
Note: To access a device through WebUSB, it is not strictly necessary to change anything on
the device side. Just make sure you have permissions and the kernel didn't claim the interface
already. The browser also requires explicit user interaction to allow access.
(In current Chrome, the feature to show the popup on device insertion is behind a flag:
chrome://flags/#enable-webusb-device-detection)
Best regards,
Jó
next prev parent reply other threads:[~2022-12-24 16:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 12:57 usb 1-3: Product: BBC micro:bit CMSIS-DAP not recognised dima.pasechnik
2022-12-19 15:00 ` Greg KH
2022-12-19 16:29 ` dima.pasechnik
2022-12-19 18:10 ` dima.pasechnik
2022-12-19 18:25 ` Greg KH
2022-12-19 22:20 ` dima.pasechnik
2022-12-19 23:36 ` Alan Stern
2022-12-20 13:08 ` dima.pasechnik
2022-12-23 14:50 ` Greg KH
2022-12-23 23:51 ` dima.pasechnik
2022-12-24 6:53 ` Greg KH
2022-12-25 11:08 ` dima.pasechnik
2022-12-25 18:52 ` Mike Spivey
2022-12-20 6:57 ` Greg KH
2022-12-20 14:50 ` dima.pasechnik
2022-12-20 19:57 ` Alan Stern
2022-12-22 10:32 ` Dima Pasechnik
2022-12-22 21:24 ` Alan Stern
2022-12-23 12:58 ` Dmitrii Pasechnik
2022-12-23 14:52 ` Alan Stern
2022-12-23 23:41 ` Dmitrii Pasechnik
2022-12-24 16:00 ` Alan Stern [this message]
2022-12-31 19:49 ` Jó Ágila Bitsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y6ciGZ1D0Hcb6Uua@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=dima.pasechnik@cs.ox.ac.uk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).