101–110 of 123 posts
What are the conditions where this problem manifests? I have a Das Keyboard that sporadically become unresponsive until I unplug and plug it back in. How do I know if my problem is caused by the issue described in the article?
Hopefully that helps narrow down your issue.
Earlier quoted context omitted.
No, the spec is saying don't issue a request at all for "at least" 10ms. "At least" because you might have to wait longer, who knows how long, until it's safe to issue a request without triggering a disconnect.
I don't understand that, if devices can take as long as they please then why give the 10ms delay at all? It'd be like telling the hardware engineers "you're not allowed to wake up your device for at least 10ms". Is that just the spec trying to say "this should cover most use cases" and it turns out that's not really the case in practice? Or maybe it's an expected limitation of the technology that it would be nearly i…
Earlier quoted context omitted.
No, the spec is saying don't issue a request at all for "at least" 10ms. "At least" because you might have to wait longer, who knows how long, until it's safe to issue a request without triggering a disconnect.
I don't understand that, if devices can take as long as they please then why give the 10ms delay at all? It'd be like telling the hardware engineers "you're not allowed to wake up your device for at least 10ms". Is that just the spec trying to say "this should cover most use cases" and it turns out that's not really the case in practice? Or maybe it's an expected limitation of the technology that it would be nearly i…
Be sure to check out the mailing list post linked from the G+ post which contains more technical details and proposed fixes http://marc.info/?l=linux-usb&m=137714769606183&w=2
Why on earth is all the text on that website set to font-weight:600 and using Courier New of all fonts? Incredibly hard to read.
I would rather prefer kernel hackers to do something useful, instead of wasting time and money to make every LKML archive look aesthetically beautiful.
hackers != designers
Earlier quoted context omitted.
Why on earth is all the text on that website set to font-weight:600 and using Courier New of all fonts? Incredibly hard to read.
I can read the website perfectly fine. It may not be shiny like all the iCrap, but it doesn't need to attract "average" users (e.g. spoiled, rich 12-year olds). I would rather prefer kernel hackers to do something useful, instead of wasting time and money to make every LKML archive look aesthetically beautiful. hackers != designers
> 1337hax0ll
> hackers != designers
I guess not, so there's no reason.
Earlier quoted context omitted.
I can read the website perfectly fine. It may not be shiny like all the iCrap, but it doesn't need to attract "average" users (e.g. spoiled, rich 12-year olds). I would rather prefer kernel hackers to do something useful, instead of wasting time and money to make every LKML archive look aesthetically beautiful. hackers != designers
So angry. Did you design Courier New or something? > 1337hax0ll > hackers != designers I guess not, so there's no reason.
Earlier quoted context omitted.
So angry. Did you design Courier New or something? > 1337hax0ll > hackers != designers I guess not, so there's no reason.
I think his point explains git beautifully.
(I bet all of them had their terminal font set to Courier New Bold while doing so)
this is wrong interpretation actually. There is no "maximum" for a reason. Because it should be evaluated as "hey hardware developer, you will have guaranteed 10 ms from System Software to resume". If you don't wake up in 10ms, you are clearly violating the spec. 9.2.6.2 states: After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of 10 ms before the device attached t…
Nothing there says that the hardware must be ready at or after 10ms. It simply says that software can't ask for anything before 10ms is up. Software has to wait 10ms, and then might have to wait longer.
> 7.1.7.7 Resume
> The USB System Software must provide a [minimum] 10 ms resume recovery time (TRSMRCY) during which it will not attempt to access any device connected to the affected (just-activated) bus segment.
> 9.2.6.2 Reset/Resume Recovery Time
> After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of [at least] 10 ms before the device attached to the port is expected to respond to data transfers.
... I would say that thinking the hardware can safely take more than 10 ms seems like a naive interpretation. You may note that system calls like usleep(10) sleep for "at least" 10 ms; there's no upper bound. The spec simply reflects this fairly typical aspect of software.
Earlier quoted context omitted.
Optimized for "white on black" color scheme. http://marc.info/?q=configure
That still looks terrible, hehe