Re: 2.6: drivers/input/power.c is never built

Pavel Machek
2005-02-19T00:14:51Z

Hi!

> > If usb keyboard has power button... I do not think we really want to
> > route that through acpi. And what if acpi is not available? (APM knows
> > about suspend key in weird way, but not about power key).
>
> I'd suggest to primarily care about acpi. The other important power
> management subsystems will follow suit.

But... power key is not really a powermanagment and we do not want to
have 1000 different ways "deliver info about power key into
userspace".

And acpi way of delivery things is not really suitable.... it mixes
power key (and similar) with battery alarms etc. ACPI interface is
*not* nice, lets not emulate that one.

> > > > trip points), and I do not see how you can do interrupts for fan
> > > > status. Either fans are under Linux control (and kernel could tell you
> > > > when it turns fan on/off, but...), or they do not exist from Linux's
> > > > point of few.
> > >
> > > They still can have a readable rate, even if not under os control.
> > > Nevertheless I don't think you can reasonably define what might
> > > interest user space or not and in which detail.
> >
> > Well, we can say that userspace definitely is interested in "power"
> > key ;-).
>
> I wouldn't call that selfevident. The system might be eg. a ticket
> vending system and we care only about wake ups from touchscreen,
> trackball and modem and about volume control keys. I don't think
> you can make up any rules about what user space is interested or not.

Yes, maybe userspace is not interested in "space" key. In such case
userland simply ignores "space" event. I do not know why "power" key
should be handled in any other way.

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!