Developer Forum

> Sometimes when I plug in a USB device I get a dialog asking if I want to
> configure it ... surely it would be possible to have that mechanism also
> consult a database (part of a distro, or on some web server) fpr info
> about the device, and offer the option for to poke at the device a bit to
> see if it behaves. That stuff works for music CDs; why not USB devices?

Not everyone who uses USB devices uses X.
It's a bit difficult to pop up a "unscrew my printer" dialog when you're
on the console.

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

> Kernel developers are a diverser lot than you think ;-)
> We don't enable autosuspend in drivers we can't test, except where
> the lack of a kernel driver forces us to use a broad swipe. Printers
> were tested, too, and most printers seem to work.

My experience suggests the opposite. Of the several I've tried so far,
none have worked with usb suspend.

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

>
> > Windows will autosuspend hubs, bluetooth devices, HID devices
>
> Hi Matthew,
>
> are you sure about windows suspending the HID devices in runtime? I have
> never seen LEDs of USB keyboard connected to windows host to go off after
> some time of not using it.

Not so sure about keyboards, but I've seen the LEDs on USB mice dim or go off
after a few seconds of inactivity under Windows, but under Linux they stay on.

> We have been playing with runtime autosuspend of HID devices, are
> currently postponed the full support, as it turns out that many devices
> don't support this feature properly (probably due to not being tested in
> Windows).

Interesting. Which devices did you notice failing?
Was it a case that they would sleep and not come back out of that state?

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

> > Plus if you're connected to such a device for monitoring purposes you're
> > probably powered by it as well, so you have little to gain from suspend
> > even if it works.
>
> I currently don't have any HID UPS by hand to verify, but I'd be surprised
> if they would advertise remote wakeup capability ... ?

Looks like mine does..

Bus 001 Device 004: ID 051d:0002 American Power Conversion Back-UPS Pro 500/1000/1500
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x051d American Power Conversion
idProduct 0x0002 Back-UPS Pro 500/1000/1500
bcdDevice 1.06
iManufacturer 3 APC
iProduct 1 Back-UPS ES 500 FW:801.e6.D USB FW:e6
iSerial 2 AB0530291763
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA

...

Dave


--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Hm, if you look at SuSE and Fedora, they too are putting usbfs in
/dev/bus/usb/ now, not mounting the filesystem, but using the device
nodes for access due to ACLs for local users.

libusb works just fine with this, and I think that all other programs
that directly access the old /proc/bus/usb mount are fixed up, with the
exception of usbview (but I do have patches floating around for that to
solve it.)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

> >
> > > Kernel developers are a diverser lot than you think ;-)
> > > We don't enable autosuspend in drivers we can't test, except where
> > > the lack of a kernel driver forces us to use a broad swipe. Printers
> > > were tested, too, and most printers seem to work.
> >
> > My experience suggests the opposite. Of the several I've tried so far,
> > none have worked with usb suspend.
>
> All of mine work. I'm wondering if this has something to do with
> a hub or motherboard... How should we test it? Tried plugging elsewhere?

no hubs involved, directly plugged them into the mainboard.
Fairly recent Intel chipsets on all the systems I tested.

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

> >
> > > Compare that to:
> > >
> > > "My USB printer broke, guess I'd better report it to LKML".
> >
> > But while this is still a likely probability, the chances are no
> > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
>
> I wouldn't be so sure, I was thinking of doing just that based on an
> internal conversation I had yesterday.
>
> Let's see what breaks and what happens :)

here's a head start for you.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359

That's just the ones that were handy..

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

> Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > > Which is why I didn't suggest doing that, of course. he only
> > > one making that kind of straw man argument seems to be you.
> >
> > But however you phrase it, that's effectively what it is. "Does your
> > device work?" just makes users wonder why the damn computer doesn't know
> > already. "This option may prevent your device from working. Click here
> > to switch it off" results in them wondering why it was switched on in
> > the first place. Many of our users aren't technical - they don't care
> > about saving 200mW, they just care about their printer working when they
> > plug it in.
>
> Devices rarely simply crash. Although Windows doesn't do runtime power
> management, it certainly will suspend all devices when the system goes
> into suspension. Buggy devices typically disconnect and reconnect when
> resumed. This is testable for in software without user intervention.

The printer I mentioned earlier this thread wouldn't work again
until I physically unplugged and replugged the usb cable.
It spewed descriptor read errors every time I tried to talk to it.
Even unloading and reloading the usb modules didn't bring it back
to life.

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

>
> > here's a head start for you.
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359
> >
> > That's just the ones that were handy..
>
> The last report appears to be related more to the EHCI-cpufreq problem,
> for which a patch was recently posted.

I was a bit iffy about including that one, but decided to because
some of the reporters noted that the problem 'went away' after
we pushed out a kernel disabling usb suspend by default.
See comments 16 & 17.

Clearly not the problem everyone was seeing, but it looks like
a few people piled on one bug with the same symptom from multiple
problems.

Dave

--
http://www.yqcomputer.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/