xorg-devel Digest, Vol 57, Issue 17

Gene Mosher gene at viewtouch.com
Mon Oct 7 08:23:59 PDT 2013

On 10/06/2013 01:41 PM, Kristen Accardi wrote:
> On Oct 6, 2013 1:26 PM, "Gene Mosher" <gene at viewtouch.com
> <mailto:gene at viewtouch.com>> wrote:
>> On 10/06/2013 12:00 PM, xorg-devel-request at lists.x.org
> <mailto:xorg-devel-request at lists.x.org> wrote:
>>> Message: 2
>>> Date: Sun, 06 Oct 2013 11:17:13 -0700
>>> From: Keith Packard <keithp at keithp.com <mailto:keithp at keithp.com>>
>>> To: Mark Kettenis <mark.kettenis at xs4all.nl
> <mailto:mark.kettenis at xs4all.nl>>
>>> Cc: xorg-devel at lists.freedesktop.org
> <mailto:xorg-devel at lists.freedesktop.org>, kaccardi at gmail.com
> <mailto:kaccardi at gmail.com>,
>>> arjan at linux.intel.com <mailto:arjan at linux.intel.com>
>>> Subject: Re: [PATCH] Close non-keyboard devices on DPMS off
>>> Message-ID: <86siwe463a.fsf at miki.keithp.com
> <mailto:86siwe463a.fsf at miki.keithp.com>>
>>> Content-Type: text/plain; charset="utf-8"
>>> Mark Kettenis <mark.kettenis at xs4all.nl
> <mailto:mark.kettenis at xs4all.nl>> writes:
>>>> > Is that really desirable?
>>> It has a couple of benefits -- the first is that touch screens and touch
>>> pads often get input while your laptop screen is closed; this prevents
>>> that from waking up the X server.
>>> The second is that turning off input devices can allow the system to
>>> shut down USB resources and save a bunch of power. I posted the patch so
>>> that we could get measurements of the power savings.
>>>> > For me, moving the mouse has always been the most natural way to wake
>>>> > up the screen.
>>> Yeah, that's the usual way I wake my machine up as well. However, if you
>>> try this on an OS X machine, you'll find that only the keyboard will
>>> wake the machine up. So, it's not a universal policy at least.
>>>> > And I can imagine that touching the screen is the most
>>>> > natural way to do it on a device with a touchscreen.  Such devices
>>>> > might not even have keyboard.
>>> It's hard to imagine a device without *any* keys, but it's certainly
>>> possible. The trick would be to figure out how to detect this
>>> automatically; my machine lists six "keyboard" devices:
>>>     ? Power Button                            id=6 [slave  keyboard (3)]
>>>     ? Power Button                            id=8 [slave  keyboard (3)]
>>>     ? Sleep Button                            id=9 [slave  keyboard (3)]
>>>     ? FaceTime HD Camera (Built-in)           id=11 [slave  keyboard (3)]
>>>     ? Apple Inc. Apple Internal Keyboard / Trackpad id=12 [slave 
> keyboard (3)]
>>>     ? Video Bus                               id=7 [slave  keyboard (3)]
>>> I think the interesting part here is the potential for power savings
>>> while the screen is blanked; getting some idea of how much closing the
>>> other devices is worth would be really helpful in figuring out when to
>>> make this choice.
>>> --
>>> keith.packard at intel.com <mailto:keith.packard at intel.com>
>> Keith, why do you want to fix something that isn't broken, by breaking
> it?  You say it's hard to imagine a device without *any* keys, well such
> 'devices' are the ONLY kind of devices I ship running the X server. 
> These are not battery operated machines so the advantage of saving power
> doesn't exist.  What is wrong with waking up a touchscreen driven
> computer by touching the screen?  There's nothing wrong with it! 
>> --Gene Mosher
> You should always try to save power, even if you are using electricity
> instead of a battery.  Its the right thing to do.
The computers I am using to run the X Server are the latest VERY low
power VIA processors.  They use less than 1 watt about 99.8% of the
time.  The software I am using blanks the screen of the VERY low power
LED LCD after 20 seconds of inactivity.  I can hardly imagine using less
power.  I can hardly imagine the mess if my users touch the screen to
use it and nothing happens.  What are they supposed to do if they want
to use the touchscreen which has no mouse or keyboard attached?

More information about the xorg-devel mailing list