Power management of a computer display - KTH

Power management of a computer display
Developing a daemon for intelligent management of computer display brightness
SEBASTIAN OLSSON, seo@kth.se
JONATAN ÅKESSON, jonatan.akesson@gmail.com
Bachelor’s Thesis at CSC
Supervisor: Per Austrin
Examiner: Mårten Björkman
Degree Project in Computer Science, First Level, DD143X
CSC, Royal Institute of Technology

Abstract
The goal with this project is to investigate how the energy management
can be improved on a linux computer. Focus lies on the screen back light
as this is one of the major energy consumers in a laptop computer. In the
systems available today the regulation is static and the back light is set
in fixed steps without the user behavior in consideration. Adaboost is a
machine learning algorithm that is implemented in a software daemon
to regulate the back light adaptive. The algorithm is trained with data
containing the user demands in the specific system state. Data covering
key presses per time, actual brightness,battery level and the information
if power cord is plugged in or not. The algorithm will continuously classify
the current system state and increase or decrease the back light. A
statistical study shows that the daemon consumes more energy than the
original system. Future developments and improvements are discussed.

Referat
Energistyrning av datorskärmar
Detta projekt syftar till att undersöka hur energihanteringen kan förbättras
på en Linuxdator. Fokus i implementationen ligger på skärmens
bakgrundsbelysning eftersom detta är en av de största energiförbrukarna
i en bärbar dator. I de system som finns tillgängliga idag så sker
regleringen statiskt och bakgrundsbelysningen regleras i fasta steg utan
anpassning till användarens beteende. Adaboost som är en lärande algoritm
implementeras i en mjukvaru daemon för att reglera ljusstyrkan
adaptivt. Algoritmen tränas med data för användarens önskemål i det
aktuella körläget med avseende på tangenttryckningar per tid, aktuell
ljusstyrka, batterinivå och information om strömkabeln är inkopplad eller
ej. Algoritmen klassificerar sedan kontinuerligt aktuellt körläge och
höjer eller sänker bakgrundsbelysningen adaptivt. En statistisk undersökning
visar att vår energihanterare drar mer ström än om den är
inaktiv. Framtida utveckling och förbättringar diskuteras

Statement of collaboration
The table below gives an estimate on how much of each part of the project each
author has worked on.
Table 1. Distribution of the workload
Part Sebastian Jonatan
Research 30 % 70 %
Preliminaries 60 % 40 %
Evaluation methods 50 % 50 %
Report layout 60 % 40 %
Developing the software 50 % 50 %
Report writing 50 % 50 %

Contents
1 Introduction 1
1.1 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Scope of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Method 3
2.1 Literature review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Back light control . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2 Adaptive Boost - Adaboost . . . . . . . . . . . . . . . . . . . 4
2.4 System evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Results 6
3.1 Aspects of power management . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Full brightness at all times . . . . . . . . . . . . . . . . . . . 6
3.1.2 Persistant behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 Incorrect behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 No gradual change in brightness . . . . . . . . . . . . . . . . 7
3.2 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Program structure . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Training set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3 OS commands . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Statistical evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Discussion 13
4.1 Existing shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Further research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Learning algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7 Energy saving versus user experience . . . . . . . . . . . . . . . . . . 16

5 Conclusion 17
Bibliography 18
Appendices 18
A Source code 19
A.1 daemon.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 1
Introduction
Mobile devices increase their market share every year. In 2007 [1], for the first time,
more laptop computers that stationary computers were sold. In December 2012 [2]
more tablets that laptops were sold for the first time.
The increased mobility and dependency of battery-powered devices have made the
power management an even more important subject. Power management is a large
subject and a lot of factors and many different hardware components influence power
consumption.
LCD [3] technology has evolved and traditional CCFL [4] back light is now being
replaced with more power efficient LED [5] instead. Still the back light of the LCD
is a major power consumer. Software power conservation related to the LCD are
automatic switch off and screen dimming. Commercial available power management
in personal computers behaves relatively static with regard to back light and will
turn the back light off after a fixed time of inactivity. Very common is also the
function to detect if the lid on a laptop is closed and react with screen switch off or
sleep mode. In some units ambient light sensors are used to be able to do intelligent
dimming.
Despite these advancements, we think that the power managers of today lack intelligence
in a sense that they are quite indifferent to how the user behaves. We have
been quite disappointed with this fact, and thus decided to try to make a minimal
power manager of our own.
1.1 Problem formulation
In short, the goal of the project is to
1. Carry out a study about the shortcomings of standard present-day computer
power managers
1

CHAPTER 1. INTRODUCTION
2. Based on the results from the study, develop our own power manager
3. Evaluate our power manager
1.2 Scope of the project
To accomplish the first point, we will study only our own laptop computers. Because
the field of research is huge, we decided to confine ourselves only to the study of
power management of the brightness level for a computer display.
The power manager we are developing will be a software daemon, capable of manipulating
the brightness settings. It will be specifically configured to work on
Sebastian’s laptop computer, which is an Asus Zenbook UX31A with Arch Linux
installed. There is therefore no guarantee of portability. To add a sense of originality
to our project, we will focus on making the daemon [6–8] intelligent in terms of
understanding the way the user behaves. The idea is that the power management
will adjust itself to the usage of the computer in relation to activity and habits.
The aim is to save power without obstructing user interaction drastically.
Lastly, the power manager will be evaluated through a minimal study measuring
the amount of power it saves. The user-friendliness aspect of the manager will not
be evaluated due to limited time and difficulty.
1.3 Purpose
The main purpose of the project is to reduce the amount of electricity that personal
computers consume. This is of course relevant since sustainable development is
an important subject today. We are ourselves quite unhappy with present-time
standard power managers when it comes to controlling the brightness of the screen
because of their overly simple behavior (described in later sections). Our view
is that because power managers behave in such simple manner, great amounts of
energy go to waste. We think that this problem can be averted by designing a more
intelligent power manager.
Besides the energy-saving aspect, we also acknowledge a few problems about today’s
power managers in terms of user experience. We think that a more intelligent power
manager would be able to improve this factor as well. Another purpose is therefore
to hopefully make users appreciate the behavior of the power manager more.
2

Chapter 2
Method
The following sections describe how we went about fulfilling our goals.
2.1 Literature review
Our source material consisted primarily of articles and specifications on the Internet.
The ACPI specification [9] has been a useful and undisputably reliable source of
information, being compiled by leading organizations in the area of technology. It
has provided the theoretical bits of information that we need to understand power
management in itself.
While we did find quite much information about ACPI and about self-learning
daemons, we did not manage to find anything combining these two concepts. We
interpret this as an indication that our specific idea is somewhat unique. The articles
and documentation that we do have found were supportive when working with the
more practical parts of the project (mostly coding).
2.2 Preliminaries
To better understand the problem and the possibilities with the technologies involved
in this project, we perform a small study of the problems with today’s common
power managers. The result will simply take the form of a collection of problems
that we have identified in our daily usage of our own computers. Both usability
aspects and power-wasting aspects will be taken into account. These problems will
then be kept in mind when thinking of features to focus on during development of
the daemon.
3

2.3 System design
CHAPTER 2. METHOD
The daemon is designed with properties described in the sections below.
2.3.1 Back light control
It must be possible for the user to manually set the display brightness while the
daemon is running. There are usually at least two different ways of controlling the
display brightness on a Linux laptop computer. Most computers complie to the
ACPI [9] standard and this is the default way to control the backlight. The second
option is to control the computer specific hardware directly. An alternative way to
switch off the back light is through DPMS. [10; 11]
2.3.2 Adaptive Boost - Adaboost
To fulfill the objectives there is a need to classify the current system situation. The
classification will be used to take the decision if the brightness should be increased
or decreased in a specific situation. In this project we use an Adaboost implementation
called isciboost to do the classification. The advantages with Adaboost is
that it is able to tweak the classifier to take incorrect classifications into consideration.
For each iteration in the training of the algorithm the weight of the incorrect
classifications are raised and the weight of the correct classifications are lowered.
In this way the subsequent iterations focus on the data-sets that have been incorrectly
classified. Adaboost can react to nonconforming data and form a responsive
algorithm suitable to the situation.
Training the algorithm
To be able to take decisions based on the current system state it is necessary to
have a set of training data with information of desired states in different situations.
In the current application the training of the algorithm is performed when the user
add information that is valuable for the algorithm. The system will take action if
the user adjusts the brightness with the hardware keys on the keyboard. When this
activity is discovered the program will consider this as a back light level state that
is desired by the user in the current situation. This information will be stored into
the training set and the algorithm will train with the updated training set. The
system information that is collected is the time average of the key press rate the
last minutes, current back light level, battery charge level and the power cord is
connected or not. The collected data-sets will also contain the information if the
specific entry is classified as one of the two classifications: decrease back light or
increase back light. The collection of user desires through this data and the repeated
4

2.4. SYSTEM EVALUATION
training of the algorithm will make the system adapt to user preferences in a given
unclassified state.
Classification
The implemented daemon will iteratively ask the Adaboost implementation for a
classification given the current system state. Adaboost will respond with a classification
of the unclassified state based on the training data described above. The
classification is performed with a statement that the back light should be lowered
and the Adaboost algorithm will then tell if this statement is likely to be true or
false and the back light will be decreased or increased. Since the classification is
done in real time iteratively the system will reach an equilibrium state where the
back light is kept stable if none of the analyzed parameters are changed.
2.4 System evaluation
The system can be evaluated in essentially two ways: in terms of usability and in
terms of how much power it saves. Because we have little time at our disposal,
we have chosen to evaluate only the power-saving aspect, and not very comprehensively.
One hour is dedicated to studying the power consumption when the daemon is not
active. Each second, the file /sys/class/power_supply/BAT0/power_now is read,
which contains the current power consumption. The higher the value, the faster is
the rate at which the battery is discharging. The power cord is to be unplugged and
the screen will be configured with a full level of brightness (4302/4302 units), which
is the default configuration. During the measurements, the computer is to be used
for the sole task of writing this report. Another hour is dedicated to studying the
consumption with the daemon running. The configurations are the same as above
except for the brightness level, of course. Like the other hour, we are continuously
using the computer to write this report.
5

Chapter 3
Results
Following our preliminary study, we will start by presenting our recognition of the
areas where standard power managers lack the intellect to save power. We will then
describe the actual program and finish by presenting the results of our statistical
evaluation.
3.1 Aspects of power management
The following subsections explain the problems that we identified in our preliminary
study.
3.1.1 Full brightness at all times
Presumption 1: The longer time that has passed from the moment when the user
last touched the computer, the higher is the probability that the user is not currently
using the computer.
3.1.2 Persistant behavior
Because usual power managers are unable to learn, they persist to continue behaving
in a way that might trouble the user. Imagine the following scenario: A person is
sitting in front of a stationary Ubuntu computer, logged in. Instead of actively
interacting with the computer, she is studying from a book on the table that the
monitor is placed on. Every fifteen minutes or so, she browses the Web briefly and
then returns to her studies.
Because of the current power management settings, the display shuts off and automatically
logs out after ten minutes of no interaction. Since the person does not
6

3.2. SYSTEM DESIGN
want to have to reenter the password each time, she presses a key or touches the
mouse now and then to make sure the computer “stays awake”. This annoying phenomenon
is one of the quite obvious issues that a more intelligent power manager
might be able to fix.
3.1.3 Incorrect behavior
Perhaps uncommonly, there are times when the power manager behaves in a way it
should not. On one occasion, we started an audio file which was set to repeat when
done playing, pressed mute and left the computer on over the night, expecting it to
eventually enter sleep mode by itself. However, because the audio file was constantly
playing, even if muted, the computer stayed awake.
3.1.4 No gradual change in brightness
On perhaps most systems, the display brightness tends to jump between a few
discrete states instead of gradually changing. For example, pressing a button on a
computer while its screen is turned off generally causes the screen brightness to go
from turned off to maximum. We consider this to be a problem, as the user might
not always want to increase the brightness more than “necessary”.
3.2 System design
This section will describe the behavior of the system. For the actual source code,
see the appendix.
The system consists of a folder of files. The daemon is initiated on the targeted
machine by executing
sudo python2 daemon.py
from the terminal (tested with Python 2.7.3).
3.2.1 Program structure
The behavior of the program is summarized in form of pseudocode below:
1. Start the keylogger, which keeps record of the number of keypresses lately.
2. Start the keylistener, which listens on the F5 and F6 keys and decreases or
increases the brightness of the screen accordingly.
3. Read current backlight brightness level.
4. Read current power consumption.
7

CHAPTER 3. RESULTS
5. Classify the current system state using Adaboost.
6. If the current state was classified as a state where the brightness should
increase:
7. Increase it by 0.5 \%
8. Else:
9. Decrease it by 0.5 \%.
10. If F6 is pressed:
11. Add a tuple (k,p,l,b,higher) to the training set, where
k is the number of keypresses last 60 seconds,
p is T if the power cord is plugged in and F otherwise,
l is the current brightness in percent,
b is the current battery level in percent.
12. Increase the brightness by 500 out of 4302 units (about 12 \%).
13. Wait for 5 seconds.
14. Re-train with Adaboost.
15. If F5 is pressed:
16. Add a tuple (k,p,l,b,lower) to the training set.
17. Decrease the brightness by 500 out of 4302 units (about 12 \%).
18. Wait for 5 seconds.
19. Re-train with Adaboost.
20. Return to step 3.
3.2.2 Training set
The file named power.data contains the entries for the training set.s An excerpt
with three entries might look like this:
66, T, 0, 99, higher
30, F, 57, 99, lower
0, F, 100, 28, lower
where:
• The first column is a numeric measure of the keyboard activity last 30 seconds.
This is roughly the same quantity as six times the number of keypresses within
that time period.
• The second column is T if the power chord is plugged in and F otherwise.
• The third column is the screen brightness given in percent.
• The fourth column is ther battery level given in percent.
• The fifth column contains the word “higher” if the brightness is decided to be
increased and “lower” otherwise.
8

3.2. SYSTEM DESIGN
3.2.3 OS commands
Backlight
The backlight level can be read from the system directory in Linux. There are
normally two separate directories one for the ACPI control and one for the specific
graphics hardware. The actual brightness that the computer is set to can be
read from the system with the following or similar commands depending on linux
installation and hardware:
cat /sys/class/backlight/acpi\_video0/actual\_brightness
cat /sys/class/backlight/intel_video/actual_brightness
The graphics hardware specific setting has the advantage of greater specificity and
greater range than the ACPI setting. The ACPI setting can only show integers
from 0-10 where 0 is low( but non zero) back light and 10 is maximum back light.
The graphics hardware specific setting can be set from 0 to 4000 where 0 is back
light off and 4000 is maximum back light. We choose to implement the Intel specific
method because of the factors mentioned above. the aim with the daemon is to be
seamless and user friendly. The steps in the ACPI setting is to large to fulfill the
task. The portability should have been better with the ACPI setting.
To set the back light the same directories as above is used. The commands used to
set the back light to the numeric level specified in the command:
echo 10 | sudo tee /sys/class/backlight/acpi_video0/brightness
echo 4000 | sudo tee /sys/class/backlight/intel_video/brightness
This will set the backlight to maximum level.
Power data
The current battery charge level is calculated from the data retrieved from the
system directory:
cat /sys/class/power_supply/BAT0/charge_now
cat /sys/class/power_supply/BAT0/charge_full
The commands will return the battery actual charge and the charge when fully
charged in mAh Battery remaining in percent is then easily calculated by dividing
these values.
To be able to tell if the AC cord is connected or not this command is used:
cat /sys/class/power_supply/ADP0/online
All console commands are called from the implemented program that also reads
their return as input.
9

Keyboard
CHAPTER 3. RESULTS
Since the algorithm will take keystrokes as an input this data has to be catured.
This is achived by reading the following file for keypress events.
/dev/input/event0
3.3 Statistical evaluation
The study was performed from 8 AM to 10 AM, April 11. The daemon was unactive
during the first hour (3600 seconds) of measurement and active during the second
hour. The power usage is illustrated in the graph below. There are a total of 7200
data points, each associating a point in time (separated by one second) with a level
of electric power.
Figure 3.1. One hour of normal usage followed by one hour of usage with the
daemon activated.
It was apparent that the brightness level was changing continuously during the
latter hour. At one point, the brightness was slowly brought down to its lowest
level.
Shortly thereafter, two additional measurements were made in order to get an idea
of how much power we could potentially save. The red graph in the plot below
10

3.3. STATISTICAL EVALUATION
shows the level of power consumption during ten seconds with the brightness level
at maximum. The green graph does the same but with the screen turned off.
Figure 3.2. Comparison of power consumption for two brightness settings.
The values were taken from the table below.
Table 3.1. Power consumption for two different brightness settings
Full brightness (µW) Turned off display (µW)
Second 1 10220000 7063000
Second 2 10374000 6937000
Second 3 10374000 9324000
Second 4 10290000 7371000
Second 5 10290000 7329000
Second 6 10234000 7238000
Second 7 10234000 7329000
Second 8 10136000 7350000
Second 9 10269000 7483000
Second 10 10703000 7378000
Average power 10312400 7480200
These measurements show that in theory, the power usage can be dropped down to
11

CHAPTER 3. RESULTS
7480200
≈ 73 % (3.1)
10312400
of the standard level by controlling the display brightness alone.
12

Chapter 4
Discussion
4.1 Existing shortcomings
Early in the project focus was to identify specific problems regarding power management
and to try to address them. These specific problems could be that an playing
muted audio file could keep the screen turned on even if the computer is unused
for example. Exceptional problems that could be common depending on situation.
This approach could have been extended with thorough user studies to identify
when the traditional power management is inadequate. When greater knowledge
in the area was achieved focus shifted somewhat towards the implementation of
an more general algorithm that seamed more interesting with the limited time and
resources at hand. This implementation solve many of identified issues. When the
daemon is active the brightness is actively changed dependant on system state and
it is changed gradually almost constantly in a way that doesn’t interfere with the
user. The system is also adoptable as long as the user actively adjust the back light
to learn the system.
4.2 System design
The implementation is naturally strongly dependant on the information in the training
set. In the current design some parameters are taken into consideration and it
is probably possible to reach better results if more/other variables are introduced.
The implementation is experimental at this stage and it has limitations. The current
approach will demand that the user actively adjusts the back light. If the user
doesn’t adjust the back light it will not be able to learn from new situations. Of
course a good initial training set can produce adequate results but the system will
not be adoptable in this case. Another aspect in a real life scenario is that it is
likely that the user primarily increases the back light. This will probably lead to
13

CHAPTER 4. DISCUSSION
that the back light is set to high in many situations if the user not actively tries to
save energy by lowering the back light. Contributing to the poor test results is the
fact that the current program runs with high update rate and many iterations per
minute. The main focus has been to evaluate the possibilities regarding back light
control for power management. The program is not optimized to lower consumption
at this stage.
4.3 Diagram
As we can see from figure 3.1, the software daemon has not contributed to reducing
the power consumption in our case. Quite the contrary - it appears that the consumption
stays around 11 W in the unactive case while it stays around 12.5 W in
the active case most of the time. If we were to presume that the power consumption
is roughly proportional to the level of brightness, the results contradict our
presumption. This is because the display was set to full brightness during the first
hour, and varying during the second. How can this be?
The likely answer is that just running the system drains more power than the system
saves. After all, our system performes quite many tasks regularly: logging keys,
reading and writing to files, and training a classifier (though not very often).
More formally, let b1(t) denote the brightness level at time t during the first hour
of the experiment, given as a quota. The power usage P1 µW may then be modeled
by
P1(t) = α + βb(t) (4.1)
where α ≈ 10312400 according to table 3.1 (assuming that the sampling error is
reasonably small). Note that b1(t) = 1. Quite similarily, the power usage P2 µW
during the second hour may be modeled by
P2(t) = α + βb2(t) + δ (4.2)
where b2(t) ranges between 0 and 1 at time t, and δ is the additional power strain
that running the daemon puts on the machine. Our objective has been to save
power during a time period [a, b], i.e. make it so that
b
b
P2(t)dt > P1(t)dt (4.3)
a
a
As has been shown, this mission failed. While it must be true that b2(t) ≥ b1(t) for
all t, this comes at the price of a constant addition δ which apparently causes the
net power usage to be higher when our daemon is active.
In order to complete the objective, we need to reduce δ and/or force the b2 function
to map to lower values. Ideally, we focus on minimizing δ to insignificance and
leaving b2 untouched so that the user has the freedom to vary the brightness level
14

4.4. FURTHER RESEARCH
at own will. This could for example be accomplished by reducing the frequency at
which our daemon reads the current brightness. Doing so would make the system
less responsive, however. There are probably a huge number of parts of the program
which could be refined that we have not thought about yet.
4.4 Further research
The implementation today consists of a general algorithm that do not address all
the specific problems described in chapter 3. The daemon can be developed further.
Our chosen Adaboost implementation can accept various data and we believe that
significant power conservation could be achived by identifying(preferably by user
studies) and addressing the back light setting in this situations. Ultimately the
user could learn the system to address these specific exceptional problems. The
challenge in this case is to be able to create an intuitive way for the user to pass on
this information to the system.
4.5 Learning algorithm
Adaboost has shown to be useful in this application. The ability to train the
algorithm is very suitable in this case because the system can be in an endless
number of states and it is impossible to anticipate the required action in different
situations. The icsiboost implementation has the advantage that it is easy to work
with. It also easily adopts to different data making testing and evaluation of different
parameter problem free. Using the implemented program over time will create a
substantial amount of data in the training set. One way to limit the data set is to
remove old entries. The execution time of the classification and training will limit
the update rate of which the program can run. One way to restrict the training
time is to limit the number of iterations in the training. This will make training
faster but the classification error will also be larger. In the current implementation
the weak classifiers is constructed from the discrete system states. It might be
possible to improve the classification if different weak classifiers are constructed
and maybe other learning algorithms are tested. To fulfil the aims with this project
it is important that the execution of the program is energy efficient. One important
concern is to limit the update rate as much as possible to conserve energy but on
the other hand keep it high enough to give a responsive behaviour.
4.6 User experience
To be able to take wise decisions to conserve energy user interaction has been
observed. By analyzing common user behavior the system can adapt to the user
15

CHAPTER 4. DISCUSSION
interaction and not the other way around. A common behavior of a generic system
is to do a full wake up when a user interact with the computer. The system will
turn on full back light regardless of the user intent and the intensity of the user
interaction. A user can for example move the mouse with the intent to check if
the computer is turned on or awake. In another situation a user can hit a key on
the keyboard to check the current time or the name of the playing song in a media
player. It would be acceptable or even better for the user experience to do a partial
wake up in this situations. Generic systems of today behaves relatively static in
the respect of back light dimming. When a user is dissatisfied with the current
brightness and adjusts it the system will keep the new setting regardless of changes
in the user environment.
4.7 Energy saving versus user experience
By implementing learning algorithms it is possible to create a system that interact
with the user in an more intelligent way. By taking historical factors into account
it is possible to make the system adoptable and alterable over time. This can
create a better user experience if the system can avoid unintended behavior. One
consideration when implementing the system to maximize energy conservation is
also to what extent the user can accept a worsen user experience with the benefit
of energy conservation.
16

Chapter 5
Conclusion
As our results have shown, the brightness of a laptop display in our case alone
accounts for 27 % of the power usage, making it quite a significant factor to reduce.
By studying the way the user behaves, we believe it is be possible to save most
of this power. We are also confident that the user experience can be enhanced
this way. More research needs to be done in this area in order to find out how.
Perhaps even more power can be saved by controlling other related factors in the
same fashion, such as when the computer goes to sleep? Maybe the user experience
really improves by changing the display brightness in a gradual manner, as we have
theorized? Could more intelligent management of power usage be the key to save
vast amounts of electricity in the future? For the sake of sustainable development,
we hope so, and hope that our study has contributed to the progress, even if by
only scraping the surface of a vast number of power saving possibilities.
17

Bibliography
1. Bärbara datorer går om stationära [homepage on the Internet]. IDG; 2007.
Available from: http://www.idg.se/2.1085/1.116318.
2. Surfplattan går om bärbar pc [homepage on the Internet]. Dagens
Nyheter; 2012. Available from: http://www.dn.se/ekonomi/teknik/
surfplattan-gar-om-barbar-pc.
3. LCD Definition [homepage on the Internet]. PCMag; 2012. Available
from: http://www.pcmag.com/encyclopedia_term/0,1237,t=LCD&i=45973,
00.asp.
4. Cold cathode [homepage on the Internet]. Wikipedia; 2012. Available from:
http://en.wikipedia.org/wiki/CCFL.
5. Back light [homepage on the Internet]. Wikipedia; 2012. Available from: http:
//en.wikipedia.org/wiki/Backlight.
6. Deamon Defenition [homepage on the Internet]. The Linux Information Project;
2012. Available from: http://www.linfo.org/daemon.html.
7. Linux daemon howto [homepage on the Internet]; 2012. Available from: http:
//www.netzmafia.de/skripten/unix/linux-daemon-howto.html.
8. Linux daemon list [homepage on the Internet]; 2012. Available from: Referens:
https://wiki.archlinux.org/index.php/Daemons_List.
9. Hewlett-Packard. Advanced Configuration and Power Interface Specification;
2011.
10. Display Power Management Signaling [homepage on the Internet]. Arch Linux;
2012. Available from: https://wiki.archlinux.org/index.php/Display_
Power_Management_Signaling.
11. Goodart J. Display Power Management (DPM) Standard Release A. 39899
Balentine Drive, Suite 125 Newark, CA 94560: Video Electronics Standards
Association; 2003.
18

Appendix A
Source code
Further below is the source code for the main module of the program, demon.py,
slightly modified to make it fit. At the time of writing, all the project files can be
found here:
https://github.com/Sebelino/kexjobb
This includes statistics.dat, which contains the results for figure 3.1.
A.1 daemon.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import time
import os
import subprocess
import re
import thread
from threading import Thread
from constants import MAX_BL
from constants import TRAIN_DELAY
from constants import DIM_PERCENT
from sysdata import sysdata
def initialize():
os.system("python2 key.py &")
os.system("logkeys -k")
open("keylog.log","w").close() # Empties the file.
19

os.system("logkeys --start --output keylog.log")
APPENDIX A. SOURCE CODE
initialize()
keylog_change = (123,0,0) # (Bytes,number of F5s,number of F6s)
train_delay_counter = -1
def add_entry_decrease(brightness,key_presses):
sysdata_tuple = sysdata()
battery_level = str(sysdata_tuple[0])
plugged_in = ’T’ if sysdata_tuple[5] else ’F’
entry = "\n%s, %s, %s, %s, lower"%(key_presses,plugged_in,brightness,
battery_level)
print "Adding entry: %s"% entry
with open("power.data","a") as training_set_file:
training_set_file.write(entry)
def add_entry_increase(brightness,key_presses):
sysdata_tuple = sysdata()
battery_level = str(sysdata_tuple[0])
plugged_in = ’T’ if sysdata_tuple[5] else ’F’
entry = "\n%s, %s, %s, %s, higher"%(key_presses,plugged_in,brightness,
battery_level)
print "Adding entry: %s"% entry
with open("power.data","a") as training_set_file:
training_set_file.write(entry)
def confine_training_set():
rows = file(’power.data’,’r’).readlines()
entry_count = len(filter(None,rows))
if entry_count >= 20:
start_index = entry_count-19
open(’power.data’,’w’).writelines(rows[start_index:])
def manual_adjustments(brightness,key_presses):
global train_delay_counter,keylog_change
lines = file(’keylog.log’,’r’).readlines()
last_line = lines[-1]
p = re.compile(r’(|)’)
tokens = p.split(last_line)
current_vals = (os.path.getsize("keylog.log"),
len(filter(lambda x: x == "",tokens)),
len(filter(lambda x: x == "",tokens)))
if((keylog_change[1] == current_vals[1]) and
(keylog_change[2] == current_vals[2])):
20

A.1. DAEMON.PY
return False
confine_training_set()
for token in reversed(tokens):
if token == ’’:
add_entry_increase(brightness,key_presses)
break
elif token == ’’:
add_entry_decrease(brightness,key_presses)
break
train_delay_counter = TRAIN_DELAY
keylog_change = current_vals
time.sleep(0.3)
return True
def kod():
global train_delay_counter,keylog_change
print " %s"% train_delay_counter
bl = str(MAX_BL)
s = get_active_window_title("")
actual_bright = os.popen(’python2 get_brightness.py’).readline()
#read keypresses
f = open(’keypress_count’,’r’)
key_presses = f.read()
f.close()
if not key_presses:
print "Should not happen."
key_presses = "0"
manual_change = manual_adjustments(str(int(float(actual_bright)/MAX_BL*100)),
key_presses)
if(train_delay_counter == 0):
os.system("icsiboost -S power -n 10")
train_delay_counter = -1
if(manual_change):
return
# skriver till fil klassifierings
sysdata_tuple = sysdata()
battery_level = str(sysdata_tuple[0])
plugged_in = ’T’ if sysdata_tuple[5] else ’F’
skriv = "\n%s, %s, %s, %s, lower"%(key_presses,plugged_in,
21

APPENDIX A. SOURCE CODE
str(int(float(actual_bright)/MAX_BL*100)),battery_level)
f = open(’power.test’,’w’)
f.write("")
f.write(skriv)
print(skriv)
f.close()
lista = boost()
stay = lista[2]
higher = lista[3]
increase = 0
if float(stay) > 0:
pass
elif float(higher) > 0:
increase = 1
delta = int(DIM_PERCENT*0.01*MAX_BL)
if increase == 1:
blint = int(actual_bright) + delta
if blint > MAX_BL:
bl=str(MAX_BL)
else:
bl = str(blint)
else:
blint = int(actual_bright) - delta
if blint < 0:
bl="0"
else:
bl = str(blint)
arst = os.system("python2 illuminator.py %s"% bl)
train_delay_counter -= 1
if train_delay_counter < 0:
train_delay_counter = -1
time.sleep(0.1)
def get_active_window_title(self):
root = subprocess.Popen([’xprop’, ’-root’, ’_NET_ACTIVE_WINDOW’],
stdout=subprocess.PIPE)
22

A.1. DAEMON.PY
for line in root.stdout:
m = re.search(’^_NET_ACTIVE_WINDOW.* ([\w]+)$’, line)
if m != None:
id_ = m.group(1)
id_w = subprocess.Popen([’xprop’, ’-id’, id_, ’WM_NAME’],
stdout=subprocess.PIPE)
break
if id_w != None:
for line in id_w.stdout:
match = re.match("WM_NAME\(\w+\) = (?P.+)$", line)
if match != None:
return match.group("name")
return "active win no"
def boost():
lista = []
read = os.popen("icsiboost -S power -C < power.test; echo $?")
time.sleep(0.1)
rad = read.readline()
lista = rad.split(" ")
return lista
while 1:
kod()
root.mainloop()
23