Message-Id: <200708030737.56316.david-b@pacbell.net>
Date:	Fri, 3 Aug 2007 07:37:55 -0700
From:	David Brownell <david-b@...bell.net>
To:	linux-usb-devel@...ts.sourceforge.net
Cc:	Matthew Garrett <mjg59@...f.ucam.org>, Greg KH <gregkh@...e.de>,
	Rogan Dawes <lists@...es.za.net>,
	Oliver Neukum <oliver@...kum.org>,
	linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:
> 
> > Which is, as I pointed out, the wrong response.  Desktoppy
> > people should be making their tools do more intelligent things
> > with new USB devices they see ... like updating databases of
> > broken devices, and configuring *this* system to know that of
> > the devices it regularly deals with, this handful is broken.
> 
> Popping up a box saying "Is your device broken?" isn't good UI. 

Which is why I didn't suggest doing that, of course.  The only
one making that kind of straw man argument seems to be you.


> > > But while this is still a likely probability, the chances are no 
> > > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
> > 
> > So you're saying all the distros want to make PM problems worse?
> 
> No. But given a choice between working hardware or marginally better 
> runtime PM, they're going to choose working hardware.

However, you've strongly implied that you want to see a short term
patch, of the type which will (as Rogan Dawes implied) prevent solving
the problem in the long term ...


> > And that with all the other desktoppy stuff they're doing, not one
> > of them is willing to help make things better?
> 
> This patch is exactly that - a way of getting most of the benefits of 
> autosuspend without any real probability of breaking hardware. If you 
> mean "Are the distributions willing to pop up dialogs asking users to 
> start caring about obscure aspects of the USB spec", then I don't think 
> that's actually making things better.

Evidently you were reading someone else's message and blaming its
content on me ... since the focus of what I wrote was having a
database *OUTSIDE THE KERNEL* which would obviate the need for
any user interaction in most cases.

If I were to describe any dialog users would see, it would be more
like "I don't recognize this device, help me set it up right...".
As with music CDs, that help might update the database for the next
person.  (Assuming this were done well, of course.)


> > Pardon me if I want to hear distro vendors agree with you before I
> > believe that.
> 
> I'm speaking as part of the Ubuntu kernel team, and I've been discussing 
> this with Fedora people.

And has the discussion included the userspace people?  (I don't
know how Ubuntu or Fedora folk structure such platform-scope
tasks.  By inference, there's not enough cross-pollination...)

Speaking of which, what's this /dev/bus/usb/* crap on Ubuntu?
I had to undo all that on my Feisty system before any normal
/proc/bus/usb stuff would work again.


> > > Breaking  
> > > people's hardware (even if, at a fundamental level, it's the hardware 
> > > that's broken) generally irritates users - and I suspect that the users 
> > > it'll irritate the most are the ones who won't report it to LKML.
> >
> > Having a laptop drain its battery an hour before it needs to is
> > also irritating.  (As are the extortionate prices for each model's
> > unique batteries, but that's a different issue.)
> 
> You commonly run a laptop off battery while having a printer plugged in?

Unfortunately I need to run laptop off AC since its battery life is
painfully short, and since Linux behaves so incredibly rudely when
the battery power goes down to almost-zero:  it lets it go to zero
rather than hibernating.  (And doesn't automatically enter suspend
when it idles, either...)

Note by the way that if you were -- for the sake of argument -- accept
my premise that this should all be handled in userspace ... it's very
easy to make userspace code do what you want.  It doesn't need to be
done inside the kernel.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists