What's missing in the USB specification and how to change that?


Djoga'Ro

moonstruck
Joined
Apr 3, 2016
Messages
2,410
Ever expected something to have been specified by the USB Implementers Forum, but had to find out they missed it?

I've got two things so far.

a) A device class USB switch or device sub class Host Hopping Hub

KM/KVM switches seem to be a mess since USB. If you employ a standard wired keyboard and a standard wired mouse, you're good with any emulating KM/KVM switch, but else it's trial and error. Since it's not specified, host don't know the concept of a switch that spans a subtree of devices, that can be afk for a bit. So there are very simple switches, where the host you're not working on thinks the devices got disconnected, since the host polls and no one answers, and the host you switch to thinks the devices just got connected and initializes them all - everytime. At least they're transparent. Then there are emulating switches, that play the host for your keyboard at the keyboard port and for your mouse at the mouse port. Towards the actual hosts they play keyboard and mouse and retweet your input to them and report "nothing happened" to the still polling hosts your currently not working on - but they only do standard keyboard and mouse.
When you look for more capable switches, you'll find terms like TTU (True Transparent USB), True USB, and DDM (Dynamic Device Mapping). But don't try to find out, what they actually do and can do. It'll drive you crazy. I tried. I'm crazy. And found nothing.

b) Keyboards emitting Unicode or UTF-8 characters/values

If you've got a programmable keyboard and think "Well, I want the capabilities of the layout Neo2, but I don't want the host to need to know anything other than en-us. So for everything you can find on the en-us layout I'll have the board emit scancodes as usual and for everything else I emit UTF-8. Then I can use every USB-capable machine - even BIOSs - and on machines, that know the full USB HID standard, I get to use all my magic.", you'll head out to find the methods to do so, and will see, it's not been specified. Why not? God damn it! Of course, you can build a keyboard that does whatever, but then your users will need your special drivers. It'd be such a simple yet powerful addition.

Second question, how to get useful stuff specified?

In my cases, regarding:

b) I had found some discussion online, where some ones wanted exactly that specified by the USB-IF. IIRC, it would need a proper draft submitted by a member company and backed by two (?) additional companies. And I think, those discussing were saying, the companies they work for, might be willing to do just that. I don't know, what came of it - can't find the discussion anymore.

a) Haven't found anything about getting something like that specified. As if I were the first to think of it, which I cannot believe, since there are KVM switch manufacturers out there struggling to come up with better workarounds. What I'd like to see:
Would it be too far fetched to specify USB Switch or Host Hopping Hub and a proper protocol, so that a switch could go "Oi, host! My gang's off to play with another. Stay tuned!" Then host would know not to senslessly poll the affected devices and not to deem them disconnected. It could also be made possible - via proper protocol - for the host to answer "Do whatever, but device XYZ has to stay with me!" in case XYZ is mass storage you're writing to or something. Or, when you switch back, host: "Oi, device! You just laid with another. Let's do some synching regarding your state!". Or, "non-active" host: "Oi, switchy-thingy! Let the user know, the kitchen's on fire here!" Or - tying in with b) - specify new buttons like KM Switch Command Key and while we're at it VM Host Command Key - so essentially zoom-out-of-scope command keys.
I'd say, that would make for a sophisticated new generation of KM/KVM switches of Awesomeness - or rather of Common Sense, damn it.


Let's hear, what you'd like to see and what battle plans you got in store to get the USB-IF to do something useful! Regarding the latter I fall a bit short. :/
 
Last edited:
c) Device Class "Firmware Recipient"

Ever had an external device and the manufaturer providing firmware updaters compiled for MS Windows only?

Why not have a specification for fw update protocol and package/container format, that allow for opt-in digital signing and verification and/or authentication and leaves room for a bunch of flexibility within (like the usb driver generically providing the Firmware Recipient with access to the packages payload (as an active/complex-FR mode next to a passive/simple-FR mode))?
The manufacturer would then just provide OS-agnostic packages and you'd just need to get some generic software, that runs on your OS.
Regarding UX it could easily go so far, that you double-click the package file and get a dialogue like
"This claims to be a firmware update for USB device model XYZ. There is a matching device connected to this computer. Do you want to apply this update to said device?
[Yes|No|Maybe]"
 
Never had that issue personally, most hardware I've bought turns out to use a common chipset that linux supports already. The bigger problem I have is stuff that just stops getting any kind of patch once the next version of said things is out, but that's not something any kind of USB change could help.
 
Are you talking about usability of USB devices?
If so I mean something like that:

Of course, a new specification could only affect device not yet produced (though technicaly more complex devices might be assimilatable into the new scheme via fw updates :)). Still, I'd like to see change in this area.
 
Not really, unless you count the safe usage of a device when a bug in its firmware has been publicly released on t'internet. In general these things will still technically work for you unless it's submitting to some sort of DoS attack.

And for the record, I've never even considered the firmware on my 8-bit-do controller. It's a bluetooth device, and while there have been holes in those types of stack, it's only a joystick. If something did manage to supply a dodgy upgrade to it from my computers when I use them, it's the only way it could be made to appear as a keyboard device over bluetooth or something more dodgy to attack my computers, but I don't anticipate that happening in reality. I guess if I used the joystick when out and about someone could pair with it without my noticing and apply a bugged update, but I don't generally do that, and it'd be much easier for them to simply swipe my phone if I had it balanced on something and was using both of my hands to work the controller.

Edit: Most IoT things that I consider to be a much bigger attack surface are able to download and upgrade to their own new firmwares, at least while they're still being supplied.

Edit2: But to be fair I don't have a reason to dismiss your proposal, just don't see much use for it at present. Who knows what future network adaptors and joysticks will be capable of.
 
Last edited:
Neither is it hurting me that much for now. It's just, that I thought via-USB fw updates seem to often be rather exclusive, and further, that that should be solved in the USB specifications. Then I thought, that I already started a thread about missing/missed things in the spec, and added it.
At times, for bug, feature, security reasons application of an already realized fw update can be desired and then it would have been nice, wasn't it so restricting OS-wise.
 
Back
Top