On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > 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 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.
And, frankly, if I got a requestor like that every time I plugged in a
new USB device I'd be fairly unhappy.
> > 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 ...
Because I don't believe we'll ever identify every device that gets
broken, and so as a result I think it's better to disable the
functionality by default for anything that might be broken.
> 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.)
Users understand CDs. They don't understand runtime power management.
> > 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...)
I also handle a lot of the desktop/kernel integration.
> 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.
"Usbfs files can't handle Access Control Lists (ACL), which are the
default way to grant access to USB devices for untrusted users of a
desktop system. The usbfs functionality is replaced by real device-nodes
managed by udev. These nodes live in /dev/bus/usb and are used by
libusb."
(From Kconfig)
> > 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...)
System/Preferences/Power Management
> 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.
It can be, but I'd prefer to have userspace enable functionality than
have the kernel break things.
--
Matthew Garrett | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
