Thanks! Yes I meant the SCSI subclass. Bootability spec is quite useful and the CD changer example makes sense.
nullplan wrote:
That's a specific type of reply on the USB. And it is used basically whenever the device doesn't like something. Sent a command it couldn't handle? Stall. Made some kind of protocol error? Stall. The only thing it means is that the transfer failed.
Additionally, a stall on endpoint 0 resolves itself, but a stall on any other endpoint must be cleared with a Clear Feature request (because somehow, being stalled is a feature of endpoints). The BBB specification contains the more specific Reset Recovery procedure (send a BBB Reset request, then clear the stall on one pipe, then on the other, not sure about the order right now).
Well, if the drive actually stalls out, then there was a protocol error. So that means no, it is probably not a good idea to do that. It is a good idea to log what happened, then perform a reset recovery. If there was an actual read failure, you would get garbage data, followed by a CSW that indicates failure. And then you do what the BBB spec tells you to (depends on the actual status). If there was indeed a permanent failure, a retry is unlikely to matter.
The BBB spec I found from 1999 is too terse, there's no mentioning of many possible stall cases outside of the 13 cases.
Tried some drives on hand, most are well behaving, no stall at all during mixed reads and writes.
One of them though (you can probably guess the maker, who has already made a "fine" name for themselves among flash drive users and people from related industries), gives nothing but trouble.
It seems to work as a read only drive, but can stall either a CBW out or a CSW in once write is attempted. The write may work, or it may stall, it's highly random. If the write worked, some other read or write after it will soon stall.
When it stalls, if I follow the spec for a CSW stall (the spec doesn't talk about CBW stall at all), the drive will stall again, at which point the spec says that a reset recovery is needed.
But if a reset recovery is done, the drive will actually
STALL very soon after that, again either on the next CBW out, or a DATA in or out after the CBW, or a few cmds done the road, but it will do this for sure very soon after a reset recovery.
STALL is not a "USB stall" and looks more like a hard hang, during which the drive will flash its LED slowly at 1hz or so. The affected transaction doesn't complete, doesn't fail and doesn't timeout. If I hand it back in this state to a Linux host, Linux will print screen full of red texts in dmesg, with a conclusion of "unable to enumerate USB device". Only a physical power cycle can recover the drive from this "stall".
It also throws a lot of other strange errors from time to time, such as reporting that it's not ready because 'media is not present'.
Obviously one would want some kind of retry rather than keep panicking every time such a temperamental drive acts up?
nullplan wrote:
Well, how do you handle input devices in general? I intend to make them as generic as possible; to me, an input device is a collection of buttons, relative axes, and absolute axes. A keyboard has 105 of the former and none of the latter two. And the events the device reports are the rising and falling edges of the buttons.
I actually don't handle input in a general way. Keyboard is handled as keyboard (interpret scancode), and mouse is handled as mouse (passthrough to user space as is). Something else (hard to come up with an example of another input device, maybe a mic?) will have to be handled as something else. Like your grand plan to unify them all though. A mic might have buttons like mute and axis like XY but it seems quite difficult to treat a mic using some code meant for a keyboard.
nullplan wrote:
So you parse the incoming reports as just a collection of buttons that are now pressed. By comparing the result of that with the previous report, you can see which buttons were pressed and which were released. Another driver can turn this into input bytes for the terminal, but I would make that a later stage. At the USB report stage, you only keep track of buttons pressed and released.
Well, then you likely never typed more than two letters at a time, so the keyboard would send you a report with the first button, then the first and the second (which you discard) and then only the second. But what happens if you hold on to one key, then repeatedly strike another? I should think, with your current strategy you would see the first key being typed again every time you release the second key. That is not the expected behavior. That is why you should keep track of pressed and released buttons. Come on, it is only 105 bits, I think you can spare those.
For now my USB stage converts keycodes that are not discarded to scancode and hand that and the modifier status over to the PS/2 keyboard code.
Yes it indeed behaves just like what you mentioned, yet for PS/2 the 2nd key is repeated instead. Learned something new as I always thought that pressing down more than 1 key causes undefined behavior.
Still don't get the use case here. If soneone would like the 2nd key to be repeated, how about pressing that key by itself? Why holding the 1st one down as well?
You probably only need 48 bits to save the state of the previous reports, but without a well defined convention on how things should behave, processing this can be a huge headache.
What should happen if one holds 6 keys down and then releases the 4th one? How about releasing the 2nd and the 5th together? Are there standards/conventions for this cross different software/platforms?