Is it a technically a manufacturer messing up the USB spec definitions it should be following?
Of all the USB drives I've come across, this Philips one is the only one that behaves like this.
It's like its saying "hey, I'm a USB 2.0 spec device, no wait a moment, I'm really a USB 3.0 spec device." and we turn around and say "make ya mind up", by which time it's too late.
Sometimes we just can't fix every problem.
Granted this one is a tough one to solve.
Edward.
On Sat, Dec 19, 2015 at 01:51:15AM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > > Doesn't it effectively take the same amount of wall clock time?
> ..
> > If you're asking if current state vs unregistering/delaying would take
> > the same wall time - thinking about that now, it might be true.
>
> Right - that's what I meant. I think it will, because ..
>
>
> > I guess the implementaiton and how things like CONFIG_THREADS=n are
> > handled would determine that.
>
> .. by the time the menu is shown and/or SeaBIOS boots automatically
> there is only one thread running anyway, right?
>
> (Or is this where I am missing something?)
Thinking about this further, USB hubs are the real issue. In theory,
a hub could have the same issue of being detected initially as USB2
and then later as USB3. In this situation, delaying does fix the
issue, but it adds more wall time as then one can't query the devices
downstream of the hub until after the delay. Unregistration doesn't
work well with hubs, because it's complicated to determine
connectivity for devices downstream of a hub that's been removed, and
because it would require different code for unregistration of mice and
keyboards.
-Kevin
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios