RandR Config Panel - Final Report

["Pascal Schoenhardt" <stoanhart gmail com>]

Hi everyone,

Sorry for the delay with this report. I have been moving back to
Victoria, BC, for school. I have had no internet connection for days
as Shaw, my cable ISP, has 10000 new connections to make. I am on the
list for the 12'th! Ouch! Additionally, the apartment which was
advertised as cleaned and furnished was not cleaned, and the furniture
was a pile of moldy couches and broken desks outside the front door.
We've done a lot of cleaning over the last few days. This is the first
time I've had a chance to come to the university and use the WiFi.

So, my project is definitely not complete. However, I am absolutely
dedicated to finishing it. I am not going to abandon this, and when it
is done, I have many other ideas for things I would like to contribute
to GNOME.

What really slowed me down 99% of the time was simply the learning
curve, and the relative complexity of C and GLib/GObject. Don't get me
wrong, I really love it; I think it is amazing to see an object system
implemented in code, rather than in the language. I love how the glib
project greatly simplifies programming in C, and adds a reliable and
efficient base on which to build modern software on just about any
device you could possibly think of. But even so, it's dramatically
more difficult than Python and Java, the languages I had the most
experience with.

I would say that the vast majority of my time on this project was
frustratingly spent reading API documentation, and trying to get
something "simple" working. Often, something I thought would take 30
minutes ended up taking all day. However, I am starting to really
"get" it. I am used to C now, and know the purpose and API of many
parts of Gnome and GLib. I really hope (but from past experience, will
not promise) that I can finish the rest of this project quickly.

Not too much has changed since the last update before this one. I will
quickly describe the state of each of the 4 components of the project:
the gnome-settings-daemon module, the "engine" module, the gui module,
and the GDK patch.

The gnome-settings-daemon module currently responds to a DBus message
to open the gui. To open the GUI, it loads the "engine" module, which
is where all of the work with profiles and RandR state occurs, which
then loads the GUI module. When the GUI is closed, the gsd module can
automatically unload the engine module after a timeout period, to save
memory. The gsd module can not yet catch hotkeys, which will
eventually be used to quickly switch through profiles.

The engine and gui modules, though existing as separate modules,
currently function as one. This is the primary area where progress is
stalled. The idea was that the engine is responsible for the following
functions:
  - Save and load profiles
  - On a screen change event, automatically look for and, if it
exists, apply the appropriate profile for the new configuration.
  - Read the current state of display configuration from RandR
  - Apply any changes from the GUI.
The GUI modules was not meant to do any actual work. It was meant
simply to display information to the user, and pass changes back to
the engine.

There are two main problems I have not yet solved that are slowing me down here.
  1) This is the biggest one: I am not sure how to uniquely identify a
display device, which is crucial to being able to store, load, and
intelligently apply profiles. With most devices, EDID information
holds the manufacturer, model, and serial number of the device, which
is perfect. However, EDID is not always available. I need a way to
identify a display without EDID.

The approach I am currently looking at using involves using X's XID's
for the outputs and CRTCs, along with other information, and hashing
it. This has some problems though: the XID's are not meant to be
persistent. They could change each time X is launched. However,
through testing in the three computers I am using, I have found that
they are always the same. I suppose they may change if a different
video cards are inserted, but I have not tested this yet. If anyone
has any ideas on how to uniquely identify display devices, that would
really help me out.

  2) The minor one: RandR provides a lot on information on state.
Currently, the GUI needs to access RandR info directly, in order to
display it. Ideally, I need to come up with a nice data structure that
holds all relevant information in a way that can be:
  - easily passed from engine to GUI, to separate "controller" from "view"
  - Allow the gui to easily do things like, for example, list which
refresh rates are available for a specific output at a specific
resolution, without needing to loop through all modes supported on an
output, group those modes by resolution, and finally loop through each
group and get all of the different refresh rates.
  - Can easily be dumped to GConf, and restored again.

Lately, I have been thinking that maybe it is unnecessary to put the
GUI in a separate module as the engine. After all, the GUI is quite
small, memory wise. It wouldn't take much more resources or time to
have the GUI code loaded each time the engine code is loaded, and
would simplify things a bit. However, it still doesn't eliminate the
need for a nice data structure for the RandR state, since it still
needs to be dumped to GConf.

Finally, the status of the GDK patch. A long while back, I posted a
patch to bugzilla. I received a lot of feedback for that, and most of
it has been applied. However, I had to restore that work from a
backup, which I stupidly did using ZIP files. All file permissions
were lost, and thus the svn directory broke. So my work is based on an
old version of GDK. I will need to freshly checkout from SVN, and then
manually re-apply all of my work. Does anyone have any experience with
this?

This is all I will write for now. I need to start working on my SOC
report for my school, where this summer counts as a co-op term (co-op
is a program to mix work experience with studies). I will hopefully be
able to start working on this stuff again after next weekend, when
things have settled down a bit.

I will continue to post updates on my website, at www.pascals.ca.

Thanks everyone!

Pascal