Hi, all.
The many smartphones and embedded devices have LCD panel with
touchscreen. The LCD panel is turned off for power saving and
touchscreen also is disabled if there isn't user input for a while or if
user presses power key briefly. This state is such idle, not suspend.
The framebuffer device driver of kernel supplies sysfs interface to
control blanking level of framebuffer and we can turn off LCD panel
using this sysfs at the above case.
Currently i know there isn't the generic way for disabling input device
via user interface, so i am looking for the way for disabling
input device on kernel side for above case.
The above case has a condition which the touchscreen is disabled if LCD
panel is turned off. The framebuffer framework of kernel has notifier
block to callback on events like hardware display blank change occured,
so the callback function disabling and enabling input device can be
called using notifier block of framebuffer. The callback function is
implemented in each touchscreen driver or can be implemented though
input core if this can be generic way for input device.
Actually i wonder whether this approach makes sense. I know this is a
specific case but certainly necessary function in the smartphone and
embedded devices.
Thanks.
From: Mark Brown <hidden> Date: 2011-03-15 15:17:31
On Tue, Mar 15, 2011 at 06:06:26PM +0900, Joonyoung Shim wrote:
The framebuffer device driver of kernel supplies sysfs interface to
control blanking level of framebuffer and we can turn off LCD panel
using this sysfs at the above case.
Currently i know there isn't the generic way for disabling input device
via user interface, so i am looking for the way for disabling
input device on kernel side for above case.
Isn't the expectation here that userspace closes the input device when
it blanks the screen?
On Tue, Mar 15, 2011 at 03:17:29PM +0000, Mark Brown wrote:
On Tue, Mar 15, 2011 at 06:06:26PM +0900, Joonyoung Shim wrote:
quoted
The framebuffer device driver of kernel supplies sysfs interface to
control blanking level of framebuffer and we can turn off LCD panel
using this sysfs at the above case.
quoted
Currently i know there isn't the generic way for disabling input device
via user interface, so i am looking for the way for disabling
input device on kernel side for above case.
Isn't the expectation here that userspace closes the input device when
it blanks the screen?
Closing the device might be a bit unwieldy, I was thinking more along
the lines of having a way of "accelerating" runtime PM timeout and using
that framework to put the device to sleep.
--
Dmitry
On Tue, Mar 15, 2011 at 06:06:26PM +0900, Joonyoung Shim wrote:
Hi, all.
The many smartphones and embedded devices have LCD panel with
touchscreen. The LCD panel is turned off for power saving and
touchscreen also is disabled if there isn't user input for a while or if
user presses power key briefly. This state is such idle, not suspend.
The framebuffer device driver of kernel supplies sysfs interface to
control blanking level of framebuffer and we can turn off LCD panel
using this sysfs at the above case.
Currently i know there isn't the generic way for disabling input device
via user interface, so i am looking for the way for disabling
input device on kernel side for above case.
The above case has a condition which the touchscreen is disabled if LCD
panel is turned off. The framebuffer framework of kernel has notifier
block to callback on events like hardware display blank change occured,
so the callback function disabling and enabling input device can be
called using notifier block of framebuffer. The callback function is
implemented in each touchscreen driver or can be implemented though
input core if this can be generic way for input device.
Actually i wonder whether this approach makes sense. I know this is a
specific case but certainly necessary function in the smartphone and
embedded devices.
I do not believe that we should tie the 2 together. I can come up with
scenarios where you woudl want to put the keeboard/touchcsreen to sleep
before turning off the display and vice versa.
Thanks.
--
Dmitry
On Wed, Mar 16, 2011 at 04:12:35PM +0900, Joonyoung Shim wrote:
On 2011-03-16 오후 1:55, Dmitry Torokhov wrote:
quoted
On Tue, Mar 15, 2011 at 06:06:26PM +0900, Joonyoung Shim wrote:
quoted
Hi, all.
The many smartphones and embedded devices have LCD panel with
touchscreen. The LCD panel is turned off for power saving and
touchscreen also is disabled if there isn't user input for a while or if
user presses power key briefly. This state is such idle, not suspend.
The framebuffer device driver of kernel supplies sysfs interface to
control blanking level of framebuffer and we can turn off LCD panel
using this sysfs at the above case.
Currently i know there isn't the generic way for disabling input device
via user interface, so i am looking for the way for disabling
input device on kernel side for above case.
The above case has a condition which the touchscreen is disabled if LCD
panel is turned off. The framebuffer framework of kernel has notifier
block to callback on events like hardware display blank change occured,
so the callback function disabling and enabling input device can be
called using notifier block of framebuffer. The callback function is
implemented in each touchscreen driver or can be implemented though
input core if this can be generic way for input device.
Actually i wonder whether this approach makes sense. I know this is a
specific case but certainly necessary function in the smartphone and
embedded devices.
I do not believe that we should tie the 2 together. I can come up with
scenarios where you woudl want to put the keeboard/touchcsreen to sleep
before turning off the display and vice versa.
Right, as you say, various scenarios can come up, so i think generic
way for disabling input device needs more and more.
Not only input, other devices need this facility as well.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 15, 2011 at 06:06:26PM +0900, Joonyoung Shim wrote:
quoted
Hi, all.
The many smartphones and embedded devices have LCD panel with
touchscreen. The LCD panel is turned off for power saving and
touchscreen also is disabled if there isn't user input for a while or if
user presses power key briefly. This state is such idle, not suspend.
The framebuffer device driver of kernel supplies sysfs interface to
control blanking level of framebuffer and we can turn off LCD panel
using this sysfs at the above case.
Currently i know there isn't the generic way for disabling input device
via user interface, so i am looking for the way for disabling
input device on kernel side for above case.
The above case has a condition which the touchscreen is disabled if LCD
panel is turned off. The framebuffer framework of kernel has notifier
block to callback on events like hardware display blank change occured,
so the callback function disabling and enabling input device can be
called using notifier block of framebuffer. The callback function is
implemented in each touchscreen driver or can be implemented though
input core if this can be generic way for input device.
Actually i wonder whether this approach makes sense. I know this is a
specific case but certainly necessary function in the smartphone and
embedded devices.
I do not believe that we should tie the 2 together. I can come up with
scenarios where you woudl want to put the keeboard/touchcsreen to sleep
before turning off the display and vice versa.
Right, as you say, various scenarios can come up, so i think generic way for disabling input device needs more and more.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Brown <hidden> Date: 2011-03-16 09:47:50
On Tue, Mar 15, 2011 at 09:53:46PM -0700, Dmitry Torokhov wrote:
Closing the device might be a bit unwieldy, I was thinking more along
the lines of having a way of "accelerating" runtime PM timeout and using
that framework to put the device to sleep.
I guess if I get the time to get the rate control stuff I've mentioned
before done that'd also be another way of doing this.