Re: [RFC] input: syfs switches for SKE keypad

Re: [RFC] input: syfs switches for SKE keypad

[Dmitry Torokhov]

Hi Sundar,

On Tue, Oct 05, 2010 at 06:54:42PM +0200, Sundar R IYER wrote:
> Hi Dmitry,
> 
> Meego folks have a requirement for dynamic sysfs switches
> for input drivers. I saw a patch from Samu (Nokia) for the same but which
> lost its way out.  Here is a small modified patch set for the SKE
> driver *only* which completes this requirement and hence a question for
> you. (The idea is only a sysfs implemention; its not yet synced in with the
> mainline code)
> 
> Would you be okay to accept a stand-alone patch like the below for all the
> input drivers that we would be pushing in or do you have some comments
> or improvements suggested to be folded in the original patch set from Nokia,
> so that it can get through into the generic tree?

I am not the biggest fan of such solution and I would prefer having this
facility on a more generic level, maybe tied in with a special for of PM
(something like user-controlled)?  Then most of the devices would simply
reuse existing suspend/resume hooks without the need to add more and
more pretty much duplicate code.

Thanks.

-- 
Dmitry

Re: [RFC] input: syfs switches for SKE keypad

[Trilok Soni]

Hi Sundar,

On 10/5/2010 11:11 PM, Dmitry Torokhov wrote:
> Hi Sundar,
> 
> On Tue, Oct 05, 2010 at 06:54:42PM +0200, Sundar R IYER wrote:
>> Hi Dmitry,
>>
>> Meego folks have a requirement for dynamic sysfs switches
>> for input drivers. I saw a patch from Samu (Nokia) for the same but which
>> lost its way out.  Here is a small modified patch set for the SKE
>> driver *only* which completes this requirement and hence a question for
>> you. (The idea is only a sysfs implemention; its not yet synced in with the
>> mainline code)
>>
>> Would you be okay to accept a stand-alone patch like the below for all the
>> input drivers that we would be pushing in or do you have some comments
>> or improvements suggested to be folded in the original patch set from Nokia,
>> so that it can get through into the generic tree?
> 
> I am not the biggest fan of such solution and I would prefer having this
> facility on a more generic level, maybe tied in with a special for of PM
> (something like user-controlled)?  Then most of the devices would simply
> reuse existing suspend/resume hooks without the need to add more and
> more pretty much duplicate code.

I agree with Dmitry. Meego people or you should explain the real end-to-end
usecase first. Why it can't fit anywhere else?

We should not fill in features very specific to userspace frameworks. I see lately
lot of Android and Meego specific bits into TS and Keypad drivers from many folks.

---Trilok Soni

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

RE: [RFC] input: syfs switches for SKE keypad

[Sundar R IYER]

Hi,

>-----Original Message-----
>From: Trilok Soni [mailto:tsoni@codeaurora.org]
>Sent: Wednesday, October 06, 2010 2:02 PM
>
>I agree with Dmitry. Meego people or you should explain the real end-to-end
>usecase first. Why it can't fit anywhere else?

I don't know the full details; but what I can think of (or did I read it somewhere?)
is events like phones with slider keypad; you can power save keypad controller
when the keypad is not active. And these events are probably issued from the user
space to the kernel and that's why the requirement probably. And I do remember
Samu mentioning about unwanted wakeup events which were avoided via these switches.

Adding Samu who can explain more on this.

>We should not fill in features very specific to userspace frameworks. I see lately
>lot of Android and Meego specific bits into TS and Keypad drivers from many
>folks.
>

Yeah. IMO it is because people want to mainline and push out all drivers more and more;
And as of today most of these drivers and HW are tested and delivered on such frameworks :)

Regards,
Sundar

RE: [RFC] input: syfs switches for SKE keypad

[Onkalo Samu]

On Wed, 2010-10-06 at 10:56 +0200, ext Sundar R IYER wrote:
> Hi,
> 
> >-----Original Message-----
> >From: Trilok Soni [mailto:tsoni@codeaurora.org]
> >Sent: Wednesday, October 06, 2010 2:02 PM
> >
> >I agree with Dmitry. Meego people or you should explain the real end-to-end
> >usecase first. Why it can't fit anywhere else?
> 
> I don't know the full details; but what I can think of (or did I read it somewhere?)
> is events like phones with slider keypad; you can power save keypad controller
> when the keypad is not active. And these events are probably issued from the user
> space to the kernel and that's why the requirement probably. And I do remember
> Samu mentioning about unwanted wakeup events which were avoided via these switches.
> 
> Adding Samu who can explain more on this.

This is how I see this issue

I tried to push enable / disable entries to generic input layer to avoid
driver specific controls. That was not accepted.

The need for keypad locking is not following any global PM transition.
In phones (like N900), global suspend / resume is not used at all. Phone
is running all the time. For example phone must be able to handle
incoming calls all the time. Instead suspend / resume, system is in deep
idle state as much as possible. Wake up from that takes couple of
milliseconds and everything is running again. Powers, clocks and any
extra activity must be turned off when ever possile depending on the
overall system state.

For input devices this means that keypad, touch controller etc. are
turned off or partially disabled for example when the screen is blanked.
Meanwhile system may still have other activity ongoing like mp3
playback. When the screen is off, there must be some way to tell to
touch controller that please turn off and save some power. This not
following pm transitions. On the other hand, disable entry may trig
pm_runtime suspend transifion for that device.

For mobile devices it is not acceptable to filter events away at some
upper SW layer depending on the system state. The HW which generates
those events may not generate events at all to allow longer CPU sleep
periods.

In ideal world it would be nice to control device states based on for
example user count. However, there are several listeners for input
devices and it is hard or impossible to have them all to follow overall
state transition (screen blanked etc.). Instead, there is some system
state controller in the userspace who is responsible to get all the HW
in the correct state. Separate disable / enable entries makes life much
easier.

Hopefully this clears out our point of view.

Regards,
Samu

> 
> >We should not fill in features very specific to userspace frameworks. I see lately
> >lot of Android and Meego specific bits into TS and Keypad drivers from many
> >folks.
> >
> 
> Yeah. IMO it is because people want to mainline and push out all drivers more and more;
> And as of today most of these drivers and HW are tested and delivered on such frameworks :)
> 
> Regards,
> Sundar
> 
> 

Re: [RFC] input: syfs switches for SKE keypad

[Trilok Soni]

Hi Samu,

On 10/6/2010 3:18 PM, Onkalo Samu wrote:
> On Wed, 2010-10-06 at 10:56 +0200, ext Sundar R IYER wrote:
>> Hi,
>>
>>> -----Original Message-----
>>> From: Trilok Soni [mailto:tsoni@codeaurora.org]
>>> Sent: Wednesday, October 06, 2010 2:02 PM
>>>
>>> I agree with Dmitry. Meego people or you should explain the real end-to-end
>>> usecase first. Why it can't fit anywhere else?
>>
>> I don't know the full details; but what I can think of (or did I read it somewhere?)
>> is events like phones with slider keypad; you can power save keypad controller
>> when the keypad is not active. And these events are probably issued from the user
>> space to the kernel and that's why the requirement probably. And I do remember
>> Samu mentioning about unwanted wakeup events which were avoided via these switches.
>>
>> Adding Samu who can explain more on this.
> 
> This is how I see this issue
> 
> I tried to push enable / disable entries to generic input layer to avoid
> driver specific controls. That was not accepted.
> 
> The need for keypad locking is not following any global PM transition.
> In phones (like N900), global suspend / resume is not used at all. Phone
> is running all the time. For example phone must be able to handle
> incoming calls all the time. Instead suspend / resume, system is in deep
> idle state as much as possible. Wake up from that takes couple of
> milliseconds and everything is running again. Powers, clocks and any
> extra activity must be turned off when ever possile depending on the
> overall system state.
> 
> For input devices this means that keypad, touch controller etc. are
> turned off or partially disabled for example when the screen is blanked.
> Meanwhile system may still have other activity ongoing like mp3
> playback. When the screen is off, there must be some way to tell to
> touch controller that please turn off and save some power. This not
> following pm transitions. On the other hand, disable entry may trig
> pm_runtime suspend transifion for that device.
> 

I think what you are referring is similar to Android specific early suspend/resume
framework. For example, what is the use of TS (if not used as wakeup) resources
when the screen goes blank, so better to early suspend it rather than waiting
upto the platform suspend to happen.

I think this can be solved with pm_runtime, isn't it? Though I am not expert
at pm_runtime, but this framework can be explored to enable these features.

---Trilok Soni

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

RE: [RFC] input: syfs switches for SKE keypad

[Sundar R IYER]

Hi Trilok,

>-----Original Message-----
>From: Trilok Soni [mailto:tsoni@codeaurora.org]
>
>I think what you are referring is similar to Android specific early suspend/resume
>framework. For example, what is the use of TS (if not used as wakeup) resources
>when the screen goes blank, so better to early suspend it rather than waiting
>upto the platform suspend to happen.

I think no. IMO TS should be disabled only when the user decides to lock off
the phone or screen. This is independent of any suspend or early suspend operation.
As Samu said, lots of back ground operations might keep the CPU running.

>I think this can be solved with pm_runtime, isn't it? Though I am not expert
>at pm_runtime, but this framework can be explored to enable these features.
>

Hmm. Yes. Even I think so; but I am not really sure if these run time helpers for
suspend/resume can be invoked from the user space. If I understand correctly, 
a event like a lock-key, keypad slider open/close or MMC slot door close/open
should trigger an event to user space, which can then force devices to suspend/resume.
If this is possible via these runtime_* helpers, then as Dmitry says, it would be up to
the user space to suspend/resume the device; we end up using a single helper for either
run time suspend or platform suspend. Maybe Rafael can comment here.

Regards,
Sundar

Re: [RFC] input: syfs switches for SKE keypad

[Dmitry Torokhov]

On Wed, Oct 06, 2010 at 05:11:07PM +0530, Trilok Soni wrote:
> Hi Samu,
> 
> On 10/6/2010 3:18 PM, Onkalo Samu wrote:
> > On Wed, 2010-10-06 at 10:56 +0200, ext Sundar R IYER wrote:
> >> Hi,
> >>
> >>> -----Original Message-----
> >>> From: Trilok Soni [mailto:tsoni@codeaurora.org]
> >>> Sent: Wednesday, October 06, 2010 2:02 PM
> >>>
> >>> I agree with Dmitry. Meego people or you should explain the real end-to-end
> >>> usecase first. Why it can't fit anywhere else?
> >>
> >> I don't know the full details; but what I can think of (or did I read it somewhere?)
> >> is events like phones with slider keypad; you can power save keypad controller
> >> when the keypad is not active. And these events are probably issued from the user
> >> space to the kernel and that's why the requirement probably. And I do remember
> >> Samu mentioning about unwanted wakeup events which were avoided via these switches.
> >>
> >> Adding Samu who can explain more on this.
> > 
> > This is how I see this issue
> > 
> > I tried to push enable / disable entries to generic input layer to avoid
> > driver specific controls. That was not accepted.
> > 
> > The need for keypad locking is not following any global PM transition.
> > In phones (like N900), global suspend / resume is not used at all. Phone
> > is running all the time. For example phone must be able to handle
> > incoming calls all the time. Instead suspend / resume, system is in deep
> > idle state as much as possible. Wake up from that takes couple of
> > milliseconds and everything is running again. Powers, clocks and any
> > extra activity must be turned off when ever possile depending on the
> > overall system state.
> > 
> > For input devices this means that keypad, touch controller etc. are
> > turned off or partially disabled for example when the screen is blanked.
> > Meanwhile system may still have other activity ongoing like mp3
> > playback. When the screen is off, there must be some way to tell to
> > touch controller that please turn off and save some power.

So exactly like I was saying it is all about the PM and thus input layer
is really the wrong place to solve this.

> >  This not
> > following pm transitions.

What do you mean? It may not follow system-whide PM transtitions but it
is per-device PM transition that I believe everyone wants to have
support for. You shut off devices individually and in subtrees when they
are not in use/needed.

> >  On the other hand, disable entry may trig
> > pm_runtime suspend transifion for that device.
> > 
> 
> I think what you are referring is similar to Android specific early suspend/resume
> framework. For example, what is the use of TS (if not used as wakeup) resources
> when the screen goes blank, so better to early suspend it rather than waiting
> upto the platform suspend to happen.
> 
> I think this can be solved with pm_runtime, isn't it? Though I am not expert
> at pm_runtime, but this framework can be explored to enable these features.

I think last time Rafael mentioned that runtime PM did not allow for
forcing power state from userspace but I wonder if it would be possible
for userspace to signal and "accelerate" the idle state for a device and
then standard runtime PM framework would kick in...

-- 
Dmitry

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Alan Stern]

On Wed, 6 Oct 2010, Dmitry Torokhov wrote:

> > I think this can be solved with pm_runtime, isn't it? Though I am not expert
> > at pm_runtime, but this framework can be explored to enable these features.
> 
> I think last time Rafael mentioned that runtime PM did not allow for
> forcing power state from userspace but I wonder if it would be possible
> for userspace to signal and "accelerate" the idle state for a device and
> then standard runtime PM framework would kick in...

Yes; drivers can implement their runtime power policy any way they
want.  For example, a driver could create a sysfs attribute file which
userspace could use to ask for changes in the power state.

The real question is whether the driver is platform-specific.  If it is 
then fine, it can do whatever it wants.  If it isn't then it should 
try to avoid doing things that are tied to a specific platform.

Alan Stern

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Dmitry Torokhov]

On Wednesday, October 06, 2010 09:19:13 am Alan Stern wrote:
> On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> > > I think this can be solved with pm_runtime, isn't it? Though I am not
> > > expert at pm_runtime, but this framework can be explored to enable
> > > these features.
> > 
> > I think last time Rafael mentioned that runtime PM did not allow for
> > forcing power state from userspace but I wonder if it would be possible
> > for userspace to signal and "accelerate" the idle state for a device and
> > then standard runtime PM framework would kick in...
> 
> Yes; drivers can implement their runtime power policy any way they
> want.  For example, a driver could create a sysfs attribute file which
> userspace could use to ask for changes in the power state.
> 
> The real question is whether the driver is platform-specific.  If it is
> then fine, it can do whatever it wants.  If it isn't then it should
> try to avoid doing things that are tied to a specific platform.
>

No, I really think it is wrong. This what leads us to the situation we
are in at the moment. Every device [re]implements  its own little knobs
to do power management. Accelerometers export their (often tailored to a
specific platform) attributes in sysfs in nonstandard way. And so on,
and so forth.

Here I'd like to see these (PM) hooks done on device core level, i.e.
the knobs should be unified and live in /sys/devices/.../deviceX/power/

Thanks.

-- 
Dmitry

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Alan Stern]

On Wed, 6 Oct 2010, Dmitry Torokhov wrote:

> > > I think last time Rafael mentioned that runtime PM did not allow for
> > > forcing power state from userspace but I wonder if it would be possible
> > > for userspace to signal and "accelerate" the idle state for a device and
> > > then standard runtime PM framework would kick in...
> > 
> > Yes; drivers can implement their runtime power policy any way they
> > want.  For example, a driver could create a sysfs attribute file which
> > userspace could use to ask for changes in the power state.
> > 
> > The real question is whether the driver is platform-specific.  If it is
> > then fine, it can do whatever it wants.  If it isn't then it should
> > try to avoid doing things that are tied to a specific platform.
> >
> 
> No, I really think it is wrong. This what leads us to the situation we
> are in at the moment. Every device [re]implements  its own little knobs
> to do power management. Accelerometers export their (often tailored to a
> specific platform) attributes in sysfs in nonstandard way. And so on,
> and so forth.
> 
> Here I'd like to see these (PM) hooks done on device core level, i.e.
> the knobs should be unified and live in /sys/devices/.../deviceX/power/

I haven't followed this thread in detail.  What sort of knobs are you 
talking about?  That is, what needs to be done?  Maybe the PM core 
already provides these features.

Alan Stern

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Dmitry Torokhov]

On Wed, Oct 06, 2010 at 02:19:03PM -0400, Alan Stern wrote:
> On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> 
> > > > I think last time Rafael mentioned that runtime PM did not allow for
> > > > forcing power state from userspace but I wonder if it would be possible
> > > > for userspace to signal and "accelerate" the idle state for a device and
> > > > then standard runtime PM framework would kick in...
> > > 
> > > Yes; drivers can implement their runtime power policy any way they
> > > want.  For example, a driver could create a sysfs attribute file which
> > > userspace could use to ask for changes in the power state.
> > > 
> > > The real question is whether the driver is platform-specific.  If it is
> > > then fine, it can do whatever it wants.  If it isn't then it should
> > > try to avoid doing things that are tied to a specific platform.
> > >
> > 
> > No, I really think it is wrong. This what leads us to the situation we
> > are in at the moment. Every device [re]implements  its own little knobs
> > to do power management. Accelerometers export their (often tailored to a
> > specific platform) attributes in sysfs in nonstandard way. And so on,
> > and so forth.
> > 
> > Here I'd like to see these (PM) hooks done on device core level, i.e.
> > the knobs should be unified and live in /sys/devices/.../deviceX/power/
> 
> I haven't followed this thread in detail.  What sort of knobs are you 
> talking about?  That is, what needs to be done?  Maybe the PM core 
> already provides these features.
> 

Mobile folks wish to power down some devices (most often input -
touchscreen, keypad) under certain circumstances to save power.
So far they were doing that by adding "disable" hook to individual
drivers and while I did allow that in for some devices I feel that we
need more standardised solution, preferably one that could re-use
existing PM hooks in drivers.

-- 
Dmitry

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Alan Stern]

On Wed, 6 Oct 2010, Dmitry Torokhov wrote:

> On Wed, Oct 06, 2010 at 02:19:03PM -0400, Alan Stern wrote:
> > On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> > 
> > > > > I think last time Rafael mentioned that runtime PM did not allow for
> > > > > forcing power state from userspace but I wonder if it would be possible
> > > > > for userspace to signal and "accelerate" the idle state for a device and
> > > > > then standard runtime PM framework would kick in...
> > > > 
> > > > Yes; drivers can implement their runtime power policy any way they
> > > > want.  For example, a driver could create a sysfs attribute file which
> > > > userspace could use to ask for changes in the power state.
> > > > 
> > > > The real question is whether the driver is platform-specific.  If it is
> > > > then fine, it can do whatever it wants.  If it isn't then it should
> > > > try to avoid doing things that are tied to a specific platform.
> > > >
> > > 
> > > No, I really think it is wrong. This what leads us to the situation we
> > > are in at the moment. Every device [re]implements  its own little knobs
> > > to do power management. Accelerometers export their (often tailored to a
> > > specific platform) attributes in sysfs in nonstandard way. And so on,
> > > and so forth.
> > > 
> > > Here I'd like to see these (PM) hooks done on device core level, i.e.
> > > the knobs should be unified and live in /sys/devices/.../deviceX/power/
> > 
> > I haven't followed this thread in detail.  What sort of knobs are you 
> > talking about?  That is, what needs to be done?  Maybe the PM core 
> > already provides these features.
> > 
> 
> Mobile folks wish to power down some devices (most often input -
> touchscreen, keypad) under certain circumstances to save power.
> So far they were doing that by adding "disable" hook to individual
> drivers and while I did allow that in for some devices I feel that we
> need more standardised solution, preferably one that could re-use
> existing PM hooks in drivers.

The OMAP people are working on exactly the same problem and are doing 
their best to solve it using the runtime PM framework.  There have been 
a couple of threads about it on the linux-pm mailing list:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-September/028689.html
https://lists.linux-foundation.org/pipermail/linux-pm/2010-September/028868.html

The question is not so much how the driver should be told to power-down
a device (the PM framework takes care of all that); it's how to
recognize when those "certain circumstances" occur.  Can this be done
by the kernel in a reasonably platform-independent way?  Or does the
kernel have to be told by userspace?  The PM framework supports both 
kinds of mechanism.

Alan Stern

Re: [RFC] input: syfs switches for SKE keypad

[Rafael J. Wysocki]

On Wednesday, October 06, 2010, Dmitry Torokhov wrote:
> On Wed, Oct 06, 2010 at 02:19:03PM -0400, Alan Stern wrote:
> > On Wed, 6 Oct 2010, Dmitry Torokhov wrote:
> > 
> > > > > I think last time Rafael mentioned that runtime PM did not allow for
> > > > > forcing power state from userspace but I wonder if it would be possible
> > > > > for userspace to signal and "accelerate" the idle state for a device and
> > > > > then standard runtime PM framework would kick in...
> > > > 
> > > > Yes; drivers can implement their runtime power policy any way they
> > > > want.  For example, a driver could create a sysfs attribute file which
> > > > userspace could use to ask for changes in the power state.
> > > > 
> > > > The real question is whether the driver is platform-specific.  If it is
> > > > then fine, it can do whatever it wants.  If it isn't then it should
> > > > try to avoid doing things that are tied to a specific platform.
> > > >
> > > 
> > > No, I really think it is wrong. This what leads us to the situation we
> > > are in at the moment. Every device [re]implements  its own little knobs
> > > to do power management. Accelerometers export their (often tailored to a
> > > specific platform) attributes in sysfs in nonstandard way. And so on,
> > > and so forth.
> > > 
> > > Here I'd like to see these (PM) hooks done on device core level, i.e.
> > > the knobs should be unified and live in /sys/devices/.../deviceX/power/
> > 
> > I haven't followed this thread in detail.  What sort of knobs are you 
> > talking about?  That is, what needs to be done?  Maybe the PM core 
> > already provides these features.
> > 
> 
> Mobile folks wish to power down some devices (most often input -
> touchscreen, keypad) under certain circumstances to save power.
> So far they were doing that by adding "disable" hook to individual
> drivers and while I did allow that in for some devices I feel that we
> need more standardised solution, preferably one that could re-use
> existing PM hooks in drivers.

There's no interface for that at the PM core level, but I think we should
add it, perhaps in analogy to the autosuspend one.  Namely, we can add a
flag for drivers who want to make their suspend/resume callbacks to be
reachable directly from user space.  Setting that flag would enable a sysfs
attribute in /sys/devices/.../power/ allowing user space to invoke
pm_runtime_suspend() and pm_runtime_resume() for the given device.

Thanks,
Rafael

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Pavel Machek]

Hi!
 
> For mobile devices it is not acceptable to filter events away at some
> upper SW layer depending on the system state. The HW which generates
> those events may not generate events at all to allow longer CPU sleep
> periods.

Ok.

> In ideal world it would be nice to control device states based on for
> example user count. However, there are several listeners for input
> devices and it is hard or impossible to have them all to follow overall
> state transition (screen blanked etc.). Instead, there is some
> system

So you have mobile device; why is it impossible to just close the
device when you do not want the events? I guess it is hard for generic
distros, but on your phone, you should be able to modify Xserver to
close touchscreen/keypad device when it is not needed... right?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC] input: syfs switches for SKE keypad

[Ferenc Wagner]

Pavel Machek <pavel@ucw.cz> writes:

>> For mobile devices it is not acceptable to filter events away at some
>> upper SW layer depending on the system state. The HW which generates
>> those events may not generate events at all to allow longer CPU sleep
>> periods.
>
> Ok.
>
>> In ideal world it would be nice to control device states based on for
>> example user count. However, there are several listeners for input
>> devices and it is hard or impossible to have them all to follow overall
>> state transition (screen blanked etc.). Instead, there is some
>> system
>
> So you have mobile device; why is it impossible to just close the
> device when you do not want the events? I guess it is hard for generic
> distros, but on your phone, you should be able to modify Xserver to
> close touchscreen/keypad device when it is not needed... right?

We'd had this discussion before... cf. eg.
http://thread.gmane.org/gmane.linux.kernel.input/9266/focus=9767

The problem was that several processes may have a device open, while
another process should be able to control the state of the device.
Maybe this could be solved by making the controlling process a proxy,
and having all "user" processes going though it.  Then the controlling
(proxy) process could open/close the device as it wants, letting the
runtime PM do its job.  But this would mean duplicating some kernel
functionality (at least multiplexing) in user space.
-- 
Regards,
Feri.

Re: [linux-pm] [RFC] input: syfs switches for SKE keypad

[Pavel Machek]

Hi!

On Wed 2010-10-13 19:35:49, Ferenc Wagner wrote:
> Pavel Machek <pavel@ucw.cz> writes:
> 
> >> For mobile devices it is not acceptable to filter events away at some
> >> upper SW layer depending on the system state. The HW which generates
> >> those events may not generate events at all to allow longer CPU sleep
> >> periods.

Actually, I question this, too.

Obviously, touchscreen needs to be turned off, but how common are
accidental button presses?

> >> In ideal world it would be nice to control device states based on for
> >> example user count. However, there are several listeners for input
> >> devices and it is hard or impossible to have them all to follow overall
> >> state transition (screen blanked etc.). Instead, there is some
> >> system
> >
> > So you have mobile device; why is it impossible to just close the
> > device when you do not want the events? I guess it is hard for generic
> > distros, but on your phone, you should be able to modify Xserver to
> > close touchscreen/keypad device when it is not needed... right?
> 
> We'd had this discussion before... cf. eg.
> http://thread.gmane.org/gmane.linux.kernel.input/9266/focus=9767
> 
> The problem was that several processes may have a device open, while
> another process should be able to control the state of the device.
> Maybe this could be solved by making the controlling process a proxy,
> and having all "user" processes going though it.  Then the

Yes, and the proxy is normally called "X server". We already have it.

> (proxy) process could open/close the device as it wants, letting the
> runtime PM do its job.  But this would mean duplicating some kernel
> functionality (at least multiplexing) in user space.

Yes. We already do that.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html