USB discussions getting a bit heated

Yes, fully expected to work, if they're class-compliant USB devices.  That's why we have standards in this business, so that you don't have to test each device individually with each different brand of computer.

There's an implicit assumption in there that the Pi is class-compliant or is following the standards. At this point, I'm not convinced that's a realistic expectation   It may end up that the Synopsis usb core in host mode just isn't ever going to work properly with linux. Nothing can be done about what's in the silicon today, regardess of what we think of the result, too late for that.  All we could ever hope for is that a Pi v2.0 uses something better. Either that or ditch the Pi and move to a different board altogether.

Yes, fully expected to work, if they're class-compliant USB devices.

Morgaine, you raise an interesting side issue here. How do I know my device or host is actually compliant ? 

Looking at http://www.usb.org/developers/compliance/ we can find some details of the various certification and compliance requirements. But I'm struggling to find any device that actually has the logo on it. Almost everything has the CE, FCC and equivalent logos, but I don't appear to own a single usb device that shows any of the usb compliance logos and like most people I have lots of usb things. The integrators list is closed, so I can't exactly look it up and even if it was open I likely couldn't lookup RPF or Broadcom, I'd need to know the exact detail of whatever Synopsis IP core was used.

So other than an assumption on my part that something with a plug that looks somewhat like a usb one will work, there's no simple way for me to know it's tested, is compliant, won't kill the thing I plug it into or burst into flames. (ok, CE probably ought to say it won't burst into flames, but same issue, how do I verify it actually meets whatever CE requirement ?)

IMHO, just because things mostly work doesn't mean you can expect them to work or that they're guaranteed to work. Even with the logo there's no guarantee, but it would at least give an indication they should generally be compliant with the standard and therefore they ought to interoperate.

However as your other thread on the Dynamode hub that has all the certified logos shows even the logos presence probably isn't good enough.

selsinork wrote:

 

So other than an assumption on my part that something with a plug that looks somewhat like a usb one will work, there's no simple way for me to know it's tested, is compliant, won't kill the thing I plug it into or burst into flames. (ok, CE probably ought to say it won't burst into flames, but same issue, how do I verify it actually meets whatever CE requirement ?)

Let's just hope that CE doesn't stand for caveat emptor

Unfortunately, there doesn't seem to be any policing of compliance.  The actual manufacturers are often no-name entities in far-away places with no reputation to protect, so there's nothing to prevent them from trying to cut every corner they can get away with.  I ran into this last year when I was trying to get cheap HDMI cables to work with my BeagleBoard.  It turned out that the cable makers didn't bother to hook up the individual ground/shield lines in the HDMI connectors, relying instead on the outer shell and a common foil shield to do the job.  This works as long as the cable is short and HDMI shields at both ends are connected to circuit ground, so few people will notice that it's out of compilance.  The manufacturer saves a penny, and if they get caught nobody gets punished.

It's generally difficult or impossible to tell whether actual products bought these days are in compliance.  A lot of the time it doesn't matter because you don't use the product in a way that exposes the problem.

Oh, it's much simpler than locating certification registrations or believing certification marks (which as we've seen, sometimes lie).  For those of us in the open source world there is an excellent pragmatic answer to your question:

A class-compliant USB device is one that works with open source drivers for that class, ie. requires no device-specific drivers.

None of my USB hubs, RF or wired mice, nor keyboards require device-specific drivers.  They use only the standard Linux drivers for their respective classes, and hence they are class-compliant as far as Linux is concerned.  This is obviously not an O/S-independent answer, but since only Linux is relevant in the current context, it is a sufficient one.

PS.  This is  true even in the Microsoft world.  Unfortunately I don't hold onto old packaging, but I've bought several devices that proclaimed something like "Class-compliant, requires no additional drivers" -- I look for that specifically, since it usually implies perfect operation in Linux out of the box.

Morgaine.

A class-compliant USB device is one that works with open source drivers for that class, ie. requires no device-specific drivers.

and when the open source driver is 'fixed' and your device stops working ?

I understand where you're coming from and the pragmatic answer is a good one. Reality doesn't always want to play ball.. 

So we have open source keyboard/mouse/whatever drivers that are known to work, but you have problems when you plug your device into the Pi - must be the device since it fails to work with the open source class driver    Ok, so I'm definetly playing devils advocate here, but as engineers I'm sure we realise it's never as simple as we'd like.

Let's just hope that CE doesn't stand for caveat emptor

Nooo...  China Export   probably not much difference then

selsinork wrote:

 

So we have open source keyboard/mouse/whatever drivers that are known to work, but you have problems when you plug your device into the Pi - must be the device since it fails to work with the open source class driver    Ok, so I'm definetly playing devils advocate here, but as engineers I'm sure we realise it's never as simple as we'd like.

Not so fast, cowboy.

When a device is pragmatically class-compliant when used with 500 trillion other Linux machines, but doesn't work with the open source driver for the class in Pi, then it's not reasonable to claim that the device is not class-compliant.  It may indeed be so, but it's not the leading candidate for an explanation, particularly when multiple devices exhibit the same behavior.

Not so fast, cowboy.

hehe..

When a device is pragmatically class-compliant when used with 500 trillion other Linux machines

however those 500 trillion other systems don't all share the same usb host controller, so not necessarily a valid comparison. It does help us narrow down the scope of the difference though.

It may indeed be so, but it's not the leading candidate for an explanation, particularly when multiple devices exhibit the same behavior.

Sure, but as we dig into some detail it gets harder to pin the tail on the donkey.  Lacking any certification audit trail we can't completely rule out everything else being broken, unlikely as it may be. So we assume the device is ok and the class driver is ok. We're still left with the low level driver, the IP core itself, or the Pi power design. We have some ability to modify the Pi power design, and the low level driver but don't know if a silicon issue could be compensated for in either of those ways.

Time may provide a solution, would certainly be disappointing if it didn't, and a software fix would be the best outcome..

selsinork wrote:

 

Time may provide a solution, would certainly be disappointing if it didn't, and a software fix would be the best outcome..

A software fix is quite likely to be able to resolve the problem, no matter how broken the controller core, just by working within its limitations.  In the same way that USB drivers reserve bandwidth for audio channels for example (and reject connections which they know cannot work), a driver that understands the controller's limits could allow only such devices that can work together to connect.

This could limit the choices, but we would at least have a 100% working platform within well defined constraints, and that is crucial.  Flakey operation has no place in USB.

Morgaine.

I'm seeing a lot of USB problems being reported at raspberrypi.org forum, especially with powered hubs.  It might just be my imagination and/or more new users coming up with new failure modes, but there seems to be a higher concentration of USB hub problems.  I wonder if they're caused by recent changes to the "blessed" operating system?

I think I'll stick with Debian "Squeeze" 6-19-04-2012 for now until this gets resolved.