Hi!
> >> > Phase 3: Probably explicit control left to open/close.
> >>
> >> While that's generally a good idea, it's important to recognize that
> >> some devices should be runtime-suspended even while they are open.
> >
> > From the kernel side, yes (and that should be transparent to the user space
> > having them open). By the user space, no.
>
> Allowing user space to suspend input devices while they are still open
> is useful. The user-space code that reads from the input devices does
> not need to know if the device is suspended or not, and the kernel
> cannot auto suspend input devices based on inactivity.
Actually, I'd like you to fix your userspace and close input devices
when it does not need them. Given the way you control the platform it
should not be that hard. I do not see why we'd want to invent new
interface for "uhuh, I have opened the keyboard but I am not really
interested in keys being pressed".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Am Sonntag 01 M?rz 2009 23:56:47 schrieb Pavel Machek:
> > Allowing user space to suspend input devices while they are still open
> > is useful. The user-space code that reads from the input devices does
> > not need to know if the device is suspended or not, and the kernel
> > cannot auto suspend input devices based on inactivity.
>
> Actually, I'd like you to fix your userspace and close input devices
> when it does not need them. Given the way you control the platform it
> should not be that hard. I do not see why we'd want to invent new
> interface for "uhuh, I have opened the keyboard but I am not really
> interested in keys being pressed".
Generally you can't do this. A task has an open fd.
- you cannot assume it can open the device again (fd may be inherited)
- keeping the device open makes sure you are talking to the same device
- you may want to avoid repeating expensive initialisations
- some input devices also do output
Regards
Oliver
On Mon 2009-03-02 09:24:36, Oliver Neukum wrote:
> Am Sonntag 01 M?rz 2009 23:56:47 schrieb Pavel Machek:
> > > Allowing user space to suspend input devices while they are still open
> > > is useful. The user-space code that reads from the input devices does
> > > not need to know if the device is suspended or not, and the kernel
> > > cannot auto suspend input devices based on inactivity.
> >
> > Actually, I'd like you to fix your userspace and close input devices
> > when it does not need them. Given the way you control the platform it
> > should not be that hard. I do not see why we'd want to invent new
> > interface for "uhuh, I have opened the keyboard but I am not really
> > interested in keys being pressed".
>
> Generally you can't do this. A task has an open fd.
>
> - you cannot assume it can open the device again (fd may be
> inherited)
Well, those tasks that matter - X servers and similar - usually can.
> - keeping the device open makes sure you are talking to the same device
Well, you have to handle hotplug anyway, so... and the name will not
change unless you unplug/replug.
> - you may want to avoid repeating expensive initialisations
That kind of initializations should perhaps be done at insmod, not
open time?
> - some input devices also do output
I guess you want to separate those to two different devices, then.
Anyway...
* I'd prefer "close to powersave". I can see that can be tricky to
use. So the alternative is
* ioctl() "I'm not interested in exact keys, powersave" is something
that makes sense. It should really be discussed with input people.
I'd hate to see
* magic /sys/.../file where you echo 1 to powersave. It is too
disconnected from the input fd, and while it may make it easier to
retrofit powermanagement without modifying Xservers etc... it will
ultimately result in pretty ugly hacks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 2 Mar 2009 09:24:36 +0100
Oliver Neukum <[email protected]> wrote:
> - you may want to avoid repeating expensive initialisations
btw this "expensive intialization" for a correct driver... is the same
thing you need to do to get the device out of power saving mode..
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org