OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/gnome-control-center?expand=0&rev=5

2008-05-31 10:19:52 +00:00 · 2008-05-31 10:19:52 +00:00 · 609f327b8e
commit 609f327b8e
parent 313281cd01
3 changed files with 923 additions and 8 deletions
--- a/gnome-control-center-randr-1.2.diff
+++ b/gnome-control-center-randr-1.2.diff
@ -22,6 +22,827 @@ index b75da5b..193fd65 100644
 gnome_display_properties_LDFLAGS = -export-dynamic
 gnome_display_properties_LDADD = \
 	$(DISPLAY_CAPPLET_LIBS) \
 diff --git a/capplets/display/TODO b/capplets/display/TODO
 new file mode 100644
 index 0000000..a1164e1
 --- /dev/null
 +++ b/capplets/display/TODO
@@ -0,0 +1,815 @@
 +Highlevel overview:
 +
 +- GTK+ work.
 +
 +	Allow applications to be notified whenever monitors are added
 +	or removed. Allow applications to get more detailed
 +	information about the connected monitors.
 +
 +	The main complication is that XRRGetScreenResources() is very 
 +	slow. We could call it only when the X server sends an event,
 +        but it's not desirable to have every application freeze for
 +        half a second. And certainly not desirable to have the X
 +        server block for n * 0.5 seconds.
 +
 +	With the X server work below we should be fine just calling
 +        XRRGetScreenResources on startup and in response to events.
 +
 +- X server work:
 +
 +	X server needs to poll for whether a monitor is plugged
 +        in. Whenever it detects a change, it should do an EDID query,
 +        and cache the resulting information. That way XRRGetScreenResources()
 +	can be the speed of a normal roundtrip. It's desirable that 
 +	normal client requests can still be processed during the EDID
 +        querying, but only a nice-to-have.
 +
 +	Drivers need to work reliably. There could be substantial work
 +	here. For F9, possibly only the Intel driver can be made to
 +	work. 
 +
 +	Interrupts and events must be generated whenever something changes
 +	about the outputs, if necessary by polling.
 +
 +	Events must be emitted whenever something changes, including when
 +	the reason for the change is a manual change.
 +
 +	The maximum framebuffer must be dynamically changable.
 +
 +- Control panel work:
 +	Capplet needs to be written. The main complications:
 +
 +	- It needs to pay attention to events from the X server
 +	  and update itself, ie., add show new monitors if they become
 +	  available when the applet is shown.
 +
 +	- It needs to store information under a key computed 
 +	  from a monitor identifier. The complication here is that
 +          it's not completely clear how to do this in GConf.
 +
 +	- Would probably be worthwhile to drop libgnome/libgnomeui from
 +	  the craplets.
 +
 +- Metacity work:
 +	- Metacity is already Xinerama aware, but it needs to update itself
 +	  when monitors come and go. 
 +
 +- GNOME panel work:
 +	- Is already Xinerama aware, but needs to listen and update itself
 +	  when monitors change. 
 +
 +- Evince work:
 +	- Make sure it deals sensibly with multiple monitors
 +
 +- OpenOffice work:
 +	- Make sure it deals sensibly with multiple monitors
 +
 +- An Xlib call to just return all the available information would be
 +  useful. At the moment we have to do a bunch of roundtrips to
 +  get the information. This is a would-be-nice though.
 +
 +- A dbus service could be written that pops up the applet whenever a
 +  monitor. It should only pop up if the new monitor is unknown. This
 +  is at best a nice-to-have, and low priority in my opinion.
 +
 +
 +*******************  Metacity
 +
 +Havoc:
 +
 +> I was just talking to bryan about this and "helping" him design it ;-)
 +
 +> But I wanted to be sure and lobby for a fix window managers
 +> need. Basically right now the WM can't tell "physical" from
 +> "logical" monitors.
 +
 +> A "logical" monitor is a desktop; it has its own panel, windows
 +> maximize to it, etc.
 +
 +> A "physical" monitor is a piece of hardware.
 +
 +> Sometimes people want to combine physical monitors into a video wall
 +> or just two monitors treated as one. Or at least a couple of noisy
 +> people in bugzilla want to do this.
 +
 +> When people talk about a "Xinerama aware" app or WM they usually
 +> mean that all physical monitors are treated as logical monitors,
 +> while lack of Xinerama-aware means treating the entire X screen (all
 +> physical monitors) as one logical monitor.
 +
 +> The problem is that the setting for "ignore Xinerama" or "don't be
 +> Xinerama aware" should be global to the desktop (GTK, all apps, WM)
 +> and should not be a window manager setting.
 +
 +> Bryan thought people who wanted non-Xinerama-aware should just use
 +> fvwm, which may be right, but what I'd say is that if there is any
 +> setting for this, it should be desktop-global and in this monitor
 +> config dialog.
 +
 +> It should not be a metacity or Compiz option, but in some way an X
 +> option in short. The implementation could be either an X server
 +> feature or an EWMH hint or whatever, but it should be controlled by
 +> the monitor config dialog and used by apps, GTK, etc. in addition to
 +> used by the WM.
 +
 +> People tend to insist this should be a WM option, but that's just
 +> busted, since GTK and apps also have Xinerama-awareness features.
 +
 +
 +******************* EDID
 +
 +edid-decode enhancements:
 +
 +- Rejects years <= 0x0f for all versions, but this should only be done
 +  for monitors claiming conformance to 1.4 (since 1.4 was released in
 +  2006). A monitor produced in 2005 should have 0x0f - it's the only 
 +  reasonable thing to do.
 +
 +- Uses 0x80 as the conformance mask for 1.4, should be 0
 +
 +- Should read from stdin
 +
 +- Should parse xrandr -verbose output more robustly
 +
 +- Color depth computation is wrong. It uses the formula
 +
 +	(edid[0x14] >> 3) + 2
 +
 +  The correct formula to use is
 +
 +	(edid[0x14] & 0x70) >> 3 + 4
 +
 +- 
 +
 +-=-=-=-
 +Computing a display name from EDID information:
 +
 +	  vendor = lookup_vendor (code);
 +
 +	  if (dsc_product && !is_gobbledigook (dsc_product))
 +	  {
 +               if (vendor && !fuzzy_string_search (vendor, dsc_product))
 +	       	  prepend (vendor);
 +	  }
 +	  else
 +	  {
 +		if (vendor)
 +		   append (vendor);
 +		else
 +		   append ("Unknown");
 +	  }
 +
 +          if (has size)
 +	  {
 +		convert_to_inches()
 +
 +		append (" %d\"", inches)
 +	  }
 +
 +(Does this internationalize at all)?
 +
 +We also need the ability to get laptop names. The laptop panel may report
 +a manufacturer that has nothing to do with the laptop manufacturer.
 +
 +Needed XRandr output properties:
 +
 +- Modes that the monitor supports, or enough information that the
 +  client can go throught the list of modes for the relevant
 +  CRTC/Outputs and filter those out that the monitor can't support.
 +
 +- The preferred mode, if any. Also useful if we could get a "strongly
 +  preferred" indication if it's an LCD with a fixed resolution.
 +
 +- Sufficient information that a fairly specific identifier can be
 +  computed. The algorithm the client should use is:
 +
 +	1 Have we seen exactly this monitor before? If yes, use
 +          settings for that.
 +
 +	2 Have we seen a monitor with similar specs before? If yes,
 +	  use settings for that. (But don't save, unless the user
 +	  changes the settings).
 +
 +	3 Otherwise, use some reasonable default for the monitor and
 +          save it.
 +
 +  A setting should only be used if the CRTC/Output allows it. Ie,. if
 +  a user has installed a new video card, then previously-used settings
 +  may no longer apply, so this must be checked every time.
 +
 +  (1) Implies that we really need a globally unique identifier for
 +  monitors. (2) is useful in an enterprise setting, but not absolutely
 +  critical, since (3) would still handle the majority of cases.
 +
 +  There is a question here: Where are machine specific preferences
 +  stored? Havoc mentions three possibilities here:
 +
 +     http://mail.gnome.org/archives/gnomecc-list/2001-October/msg00023.html
 +
 +  I'm not sure if any of them are implementable at this point. Also
 +  (1) may mostly take care of the problem.
 +
 +
 +  Usecases:
 +
 +  1. Fixed setup with some number of monitors.
 +     - They should be set to the correct mode on login. 
 +       Note that this involves setting the right position in the
 +       framebuffer too.
 +       What if someone swaps two monitors? Users are going to expect
 +       that the images will switch position.
 +
 +  2. Laptop being moved between home and work
 +     - Setups should be detected and the correct mode set, at least on
 +       login, but ideally when you put the laptop into the docking
 +       station.
 +
 +  3. Laptop gets projector plugged in.
 +
 +  Note the same model monitor can be used in two different ways. Ie.,
 +  at home, it's being used at one resolution, at work the same type of
 +  monitor is used at a different resolution.
 +
 +  Simple solution:
 +
 +  - The on-disk database is just a list of monitors. Each monitor has an
 +    associated mode. This has these problems:
 +         - If someone uses the same monitor model in two different ways.
 +         - If someone swaps the monitors around
 +
 +  Better solution
 +
 +  - The on-disk database is a list of configurations, where a
 +    configuration is a list of monitors and what outputs they are
 +    connected to, and the position in the framebuffer.
 +
 +  - Picking a default configuration is then a matter of selecting the
 +    closest existing configuration from the database.
 +
 +    	- If the stored configuration is a subset of the existing, 
 +	  then use that - then pick the best mode available for the
 +	  rest of the monitors
 +
 +	- If the stored configuration is a superset of the existing,
 +	  then use the projection of the configuration onto the monitors.
 +
 +	- Pick the configuration with the most overlap in monitors.
 +	  Although, if a configuration differs only in what outputs
 +	  they are connected to, then those outputs should probably
 +	  get their original modes set.
 +
 +  - Or maybe simply:
 +
 +    - If there is an exact match, use it, if not, pick a default.
 +    
 +    - Picking a new default must never change the mode of any existing
 +      output.
 +
 +******************* Capplet
 +
 +Somehow the applet will find out that a new monitor is plugged in
 +(either through notification, or through a refresh button). When this
 +happens, this monitor is looked up in a database and if it is found,
 +some suitable mode is set.
 +
 +Restrictions on the modes:
 +
 +- Monitors that are already plugged in should not get their mode
 +  changed just because a new monitor is plugged in.
 +
 +- If the exact configuration of monitors is known, and all the old
 +  monitors have the same mode as the known configuration, then just use
 +  the known configuration. Also do this, if the configuration is a
 +  subset of something known.
 +
 +- Otherwise, if the configuration is a subset of a known configuration
 +  where the only difference is that existing monitors have different
 +  modes, then try and convert that mode to something we can know
 +  about. Maybe configurations should be stored in terms of edges that
 +  line up.
 +
 +- Otherwise, just pick some good default for the mode, probably based
 +  on the EDID prferred mode if possible. By default cloning is
 +  probably best.
 +
 +- How do virtual desktops interact with this?
 +
 +
 +g-s-d:
 +
 +- On startup 
 +
 +     - It reads the configuration file into memory
 +
 +       	    capplet --configure
 +
 +     - It gathers the existing configuration from randr
 +
 +     - If the existing config is in the file, set that mode
 +
 +- On changes, including changes to the config file [this is crack]
 +
 +     - Reread configuration file
 +
 +     - Compare new configuration to database, if it is there, set the
 +       mode as appropriate
 +
 +     - If a monitor was added, pop up a bubble
 +
 +       	    capplet --show-bubble
 +
 +       	    capplet --set-mode
 +
 +capplet
 +
 +- On changes
 +
 +     - Update GUI
 +
 +- When user changes something, 
 +
 +     - Write configuration to file
 +
 +     - Signal gsd somehow
 +
 +Schemes:
 +	- configuration file changes
 +	  - randr code will have to be shared between gcc and gsd
 +
 +	- binary installed by gcc
 +	  - something will still have to listen for changes to pop
 +	    up the notification bubble.
 +
 +Structure of capplet:
 +
 +- There is a database on disk with monitors and their corresponding
 +  settings.
 +
 +- On startup, this database is read into memory. When the user accepts
 +  new settings, it is written back to disk.
 +
 +- When something changes about the settings
 +
 +  - If new configuration is in the database, use that mode
 +
 +  - Else, find all outputs that are now connected but weren't before,
 +    and set a default mode for them.
 +
 +  - If GUI is running, update graphics.
 +
 +
 +  - Notification thing: 
 +      - if 
 +
 +      - if the new configuration is found in the database, use it
 +
 +  and added if they are not already there. Initial settings are
 +      1 what the output is already doing, if anything
 +      2 based on an existing sufficiently similar monitor, if possible
 +      3 some reasonable default.
 +
 +- When the user changes settings in the GUI, the corresponding monitor
 +  in the database is updated.
 +
 +- Whenever the GUI settings change, for all displayed monitors the
 +  possible modes are recomputed.
 +
 +- Whenever a new monitor is selected in the GUI, it first gets all its
 +  possible modes computed based on the selections on other
 +  outputs. Then, if the possible modes include the existing choice of
 +  resolution, that is selected.
 +
 +  Actually, 
 +
 +  - initially, the settings are copied from the current settings
 +
 +  - whenever a gui setting changes for a monitor, all the other
 +    monitors get their list of choices set to whatever is possible
 +    given the chocie for the current monitor. A 'desired mode' is
 +    maintained, and the closest choice to that is displayed. Whenever
 +    the user actively selects something, that becomes the desired mode
 +    for that monitor.
 +
 +- Required
 +
 +  - Generate all outputs that are newly connected
 +
 +    	     foreach_newly_connected (Configuration *before, Configuration *after, 
 +	     			      OutputFunc);
 +
 +  - A way to generate the best mode for a connected output
 +
 +      	     existing best_mode() can probably be used
 +
 +  - Given a list of modes, pick the one closest to a given mode. 
 +
 +      	     (a possibility here is: pick an exact match, if that's impossible, then
 +	      pick the best one with the same width/height, if that's impossible, then
 +	      just pick the best mode on the list).
 +
 +  - For a configuation, fix the mode for a subset of the outputs, then list the 
 +    combinations for the rest of the outputs.
 +
 +    	     An obvious possibility here is to simply list all possibilities, then 
 +	     weed out those that don't work. Is this too expensive? It might be.
 +
 +Structure of login time program:
 +
 +- The configuration database is read
 +
 +- The current hardware configuration is generated
 +
 +- If the current configuration is found in the database, that mode is set.
 +
 +- If it isn't found, then nothing changes.
 +
 +     This could just be gnome-screen-resolution-capplet --reset
 +
 +*******************  Things that need to be done to the xrandr.patch:
 +
 +===
 +
 +XRRGetScreenResources() is a roundtrip and very slow (~0.5 s). GTK+
 +needs to keep information up-to-date by tracking events rather than
 +calling this function. In fact we probably can't call it at all unless
 +its performance improves significantly.
 +
 +If EDID processing really has to be this slow, and we can't get
 +interrupts when monitors are plugged in, then we have a problem,
 +because we can't do anything this expensive once per second.
 +
 +
 +Detailed notes (but most of the patch should be rewritten):
 +
 +
 +=== FIXME in gdkscreen-x11.c in get_width_mm()
 +
 +/* monitor pixel width / screen pixel width * screen_physical width */
 +
 +
 +
 +=== Check for 1.2 library
 +
 +The patch should check that the 1.2 version of the XRandR library is
 +available before using the functions. A possibility is to not use any
 +RandR unless 1.2 is available, another is to conditionalize the code.
 +
 +The most sane thing is probably to just require 1.2.
 +
 +On the other hand, installing a newer gtk+ on a system with older X is
 +probably not that unusual, so maybe it's better to do the full 1.0,
 +vs. 1.1 vs 1.2 check.
 +
 +For now it just requires 1.2.
 +
 +Actually, this might be fine because the only place where we make use
 +of a 1.1 library is in the _gdk_x11_screen_size_changed() function,
 +but there we have a fallback that just updates the variables in the
 +Screen struct itself.
 +
 +So, only defining HAVE_RANDR if we detect 1.2 should be ok.
 +
 +=== Monitor information available
 +
 +- Subpixel information. This should be set automatically for the fonts and
 +  store under the name of the monitor. If the user changes the font
 +  configuration, that change should also be stored under the monitor name.
 +
 +- When a monitor we don't know about is plugged in, a configuration should
 +  be generated:
 +
 +	- Screen size, computed based on the location of the screens 
 +
 +	- RGBA information
 +
 +	- Whether the screen has a panel on it
 +
 +	- If there is a conflict between stored information and EDID,
 +          the stored information wins
 +
 +	
 +
 +New API so far:
 +
 +(* monitors_changed) signal
 +gdk_screen_get_monitor_width_mm()
 +gdk_screen_get_monitor_height_mm()
 +gdk_screen_get_monitor_name() => Note this is the output (eg. "DVI-0")
 +
 +We should probably also have 
 +get_manufacturer()
 +get_serial()
 +get_resolutions()
 +
 +etc. 
 +
 +Should there be a GdkMonitor object that would correspond to an
 +output? Or maybe GdkOutput?
 +
 +screen_list_monitors()
 +
 +
 +*************************** Issues XRandR/Xserver
 +
 +- We need polling in the X server, whenever something changes, X must
 +  recompute the information and cache it, then send an event. Note the
 +  situation where the user disconnects and reconnects a monitor within
 +  the polling interval. The event could missed in that case since the polling
 +  cannot do a full EDID query. Difficult to see a way around this.
 +
 +  Actually, DDC allows random access, so it should be possible to just
 +  read theq vendor id and manufacturer codes. This can be done once a
 +  second without a problem. The polling should be turned off in power
 +  saving mode anyway.
 +
 +  - Driver work:
 +
 +  - Intel driver:
 +
 +    - EDID information is not reported for VGA when the output is not 
 +      turned on (i945 laptop).
 +
 +    - Screen size must be dynamically changable. (No xorg.conf changes
 +      should be required).
 +
 +    - Make use of ACPI information when possible. 
 +
 +      Adam has code on his freedesktop page.
 +
 +    - i830 laptop can be put in a state where XRandr reports that no
 +      outputs are connected to a CRTC, but the panel is on.
 +
 +      	      - Plug in VGA
 +	      - xrandr --auto
 +	      - xrandr --output VGA --off
 +	      - run chk 
 +	      - xrandr --verbose will now not report any outputs as turned on
 +	      - run chk again - all screens will be turned off
 +
 +    - Small Sun monitor - an 1152x921 mode is generated, but the
 +      monitor doesn't handle that. The monitor itself only claims to
 +      handle 1152x920.  It doesn't look to me like there is anything
 +      in the EDID information that would indicate that it could handle
 +      1152x921.
 +
 +      This happens with a radeon as wellso it may be a bug in the
 +      generic X server EDID parsing. The X server apparently
 +      interpretes the standard timing 1152x920 as 1152x921.
 +
 +      This happens because the X server uses
 +
 +      	    hsize * 4 / 5
 +
 +      which gives 921 for 1152. By using
 +
 +      	    (hsize / 5) * 4
 +
 +      you get 920. The 66 Hz version can bet set, the 76 Hz mode gets
 +      sync out of range. (Would be interesting to find out whether the
 +      1152x920 ModeLine would allow the 76 Hz version to be set).
 +
 +  This is for the ATI driver as shipped in F8:
 +
 +  - XRRGetScreenResources() takes half a second.
 +
 +    - Adam has now removed a workaround that caused some of the slowdown. 
 +  
 +  - If a DVI monitor is disconnected, you get "Unknown" for connection
 +    status.
 +
 +  - If a VGA monitor is plugged in, then EDID information is not
 +    available, even after running xrandr --verbose. The monitor has
 +    to be plugged in at driver startup time, apparently.
 +
 +  - Logging out and logging back in often results in some random mode being
 +    set. We need mode selection to not be completely screwed up.
 +    Currently it is. 
 +
 +  - The set up at server startup needs to be fixed. *If* randr actually works,
 +    then we might be able to do something sensible. 
 +
 +  - We need to revisit the idea that many monitors have broken EDID data.
 +    This may be less widespread than previously believed.
 +
 +- It may be useful to return the connector names as identifiers instead
 +  of relying on UTF-8 strings. Ie., have an enum
 +
 +	{ UNKNOWN, OTHER, DVI, VGA, HDMI, ...,  }
 +
 +  in addition to the string. The difference between UNKNOWN and OTHER is that
 +  UNKNOWN means the driver doesn't know, whereas OTHER means it is something 
 +  not listed in the enum (which could be listed in a later version).
 +
 +- Mouse cursor should be confined to the visible area. (It is already, I think)
 +
 +- It looks like EDID information is only available for one output
 +  even though it is actually read according to the log file.
 +  (nv, intel drivers)
 +
 +
 +*********************************
 +
 +
 +
 +DONE:
 +
 +Server work:
 +
 +    - i830 laptop incorrectly reports BadMatch when you configure the
 +      CRTC to drive both VGA and LVDS with the 1024x768 mode that both
 +      outputs can handle. (It should return 'failed' if it can't do
 +      that). Same for i945 laptop. It seems as if the same CRTC can't 
 +      drive more than one output at the same time on Intel. 
 +      
 +      This was a client bug, but the documentation for SetCrtcConfig
 +      should say that BadMatch will be returned if the outputs aren't
 +      clones.
 +
 +GTK+ patch is in now.
 +
 +=== Add helper function
 +
 +
 ++  if (screen_x11->randr12)
 ++  {
 ++       XRRScreenResources *sr;
 ++    XRROutputInfo *output;
 ++       gchar *retval;
 ++       
 ++    sr = XRRGetScreenResources ( screen_x11->xdisplay,
 ++                                 screen_x11->xroot_window );
 ++    
 ++    output = XRRGetOutputInfo ( screen_x11->xdisplay,
 ++                                sr,
 ++                                (RROutput)screen_x11->act_outputs[monitor_num]
 +);
 +
 +  Might be worthwhile to factor this out into a 
 +  gdk_screen_get_output_info (screen, monitor_num)
 +  helper function ? 
 +
 +Instead of cutting and pasting all over creation
 +
 +* Calling XRRGetScreenResources all the time is not going to fly. It
 +  takes hundreds of milliseconds ... Even if it didn't, it wouldn't
 +  be acceptable to do all those roundtrips.
 +
 +
 +=== Some g_prints left
 +
 +
 +=== Version check
 +
 +Should be (maj > 1) || (maj == 1 && min >= 2)
 +
 +
 +=== Grep for TODO
 +
 +
 +=== Setup XRRSelectInput()
 +
 +  You should call XRRSelectInput() at the same place where you are 
 +  calling XSelectInput() right now. The right place to handle the 
 +  XRandr events is the huge switch in gdkevents-x11.c:gdk_event_translate
 +  Check out how other extension events are handled there, like
 +  XKB, or XFixes.
 +
 +
 +=== Lots of variable naming issues, such as act_output and noutput
 +
 +=== Needs to select the input, and hook it up to the signal
 +
 +=== Add version markers to API
 +
 +=== API to turn monitors on and off?
 +
 +- DPMS not exposed through randr, maybe should be
 +
 +       - DPMS is presumably a property of either an
 +         output or a CRTC. Logically it's an output.
 +
 +- Need events when DPMS happens. Exposing the "screen saving on" on
 +  dbus may not be good enough.
 +
 +=== Why does init_multihead_support() start by freeing monitors and
 +outputs?
 +
 +=== Do we disable Xinerama support entirely when 1.2 is in use?
 +
 +=== We should expose information about what parts of the screen monitors
 +are viewing.
 +
 +=== Make use of the EDID information?
 +
 +
 +-- details for X server --
 +
 +In nv driver SorSetOutputProperty should return TRUE for unknown
 +properties. (Like the Intel driver does).
 +
 +Detecting plugged in
 +
 +- Periodically poll
 +  - 
 +
 +  - One ddc probe takes 5 ms, according to a comment in the intel
 +    driver. Running this twice a second would mean spending 1% of
 +    overall time doing ddc polling, which is almost certainly not
 +    acceptable.
 +
 +    1) Async I2C:
 +
 +	void I2CProbeAsync(..., callback, data);
 +        Bool I2CPending()
 +	void I2CUpdate()
 +
 +      In Dispatch, call I2CUpdate()
 +      Before going idle, do
 +
 +            while (I2CPending())
 +                 I2CUpdate()
 +
 +      Would need
 +      	    RegisterDispatchFunction()  (Is this called Wakeup?)
 +	    RegisterIdleFunction()
 +
 +      Note the idle function should have the option of saying: 
 +      "check if something else happened; if not, call me again" and
 +      "ok, I'm done - go idle". Otherwise, we would be blocking for
 +      5 ms whenever the X server went idle. So actually the idle
 +      function should be
 +
 +      	       if (I2CPending())
 +	       {
 +			I2CUpdate();
 +			return TRUE;  /* call me again */
 +               }
 +               else
 +	       {
 +			return FALSE; /* I'm done */
 +               }
 +
 +      What happens if another I2C requests come in while an async one
 +      is pending? Most likely we simply finish whatever is going on,
 +      then process the new request.
 +
 +      What happens if an X request takes so long that we get timeouts on
 +      the i2c bus? Good question. Need to read the VESA ddc spec.
 +
 +    2) Run the polling in a separate thread.
 + 
 +       Probably crack.
 +
 +    3) Run the polling less, maybe once every three seconds. 
 +
 +-- details for control panel --
 +Screen changes
 +       - Currently it is polling via rw_screen_refresh(), which will always emit
 +         a screen-changed event. In reponse to this event the capplet currently
 +	 checks whether anything changed physically about the setup. This means
 +	 the capplet can't react to external changes to modes. On the other hand
 +	 if it didn't
 +Disallow combinations that would exceed the screen ranges.
 +   - Note rotations 
 +
 +Give rw objects stable positions in memory so that they can be cached
 +across screen_changed events.
 +
 +Add Clone Mode
 +
 +Drag and drop for the monitors
 +     - 2 dimensional layout
 +
 +Store make and model in monitors.xml, then if serial numbers don't
 +match, fall back to a make and model match. Users with an nfs mounted
 +home directory should not have to reconfigure for each new system they
 +log in to.
 +
 +Make sure text is scaled correctly
 +
 +Need to sanitize naming
 +     RWOutput vs Output	- should probably be OutputInfo
 +     rate vs. freq - decide on one
 +
 +Should probably reconsider the use of null terminated arrays. 
 +Maybe lists would be better.
 +
 +Pick a fixed scale, so that two 1024x768 don't look like two 6x4.
 +     - An alternative would be to draw a checkerboard pattern
 +       below the monitors. 
 +
 +
 +
 +done:
 +
 +Add rotation
 +
 +Disable panel checkbox for now
 +
 +Patch into gnome-desktop
 +
 +Find out how to share code between gcc and gsd
 +
 +Make it assign coordinates correctly
 +     - including computing correct screen size
 +
 diff --git a/capplets/display/build.sh b/capplets/display/build.sh
 new file mode 100644
 index 0000000..4268ab7
@ -778,10 +1599,28 @@ index 0000000..59d9261
 +
 diff --git a/capplets/display/scrollarea.c b/capplets/display/scrollarea.c
 new file mode 100644
-index 0000000..5368373
+index 0000000..3d3d8b6
 --- /dev/null
 +++ b/capplets/display/scrollarea.c
-@@ -0,0 +1,1902 @@
+@@ -0,0 +1,1920 @@
 +/* Copyright 2006, 2007, 2008, Soren Sandmann <sandmann@daimi.au.dk>
 + *
 + * This library is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU Lesser General Public
 + * License as published by the Free Software Foundation; either
 + * version 2 of the License, or (at your option) any later version.
 + *
 + * This library is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the GNU
 + * Lesser General Public License for more details.
 + *
 + * You should have received a copy of the GNU Lesser General Public
 + * License along with this library; if not, write to the
 + * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 + * Boston, MA 02111-1307, USA.
 + */
 +
 +#include <gdk/gdkprivate.h> /* For GDK_PARENT_RELATIVE_BG */
 +#include "scrollarea.h"
 +#include "foo-marshal.h"
@ -2686,10 +3525,27 @@ index 0000000..5368373
 +#endif
 diff --git a/capplets/display/scrollarea.h b/capplets/display/scrollarea.h
 new file mode 100644
-index 0000000..22abc6c
+index 0000000..f043aab
 --- /dev/null
 +++ b/capplets/display/scrollarea.h
-@@ -0,0 +1,107 @@
+@@ -0,0 +1,124 @@
 +/* Copyright 2006, 2007, 2008, Soren Sandmann <sandmann@daimi.au.dk>
 + *
 + * This library is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU Lesser General Public
 + * License as published by the Free Software Foundation; either
 + * version 2 of the License, or (at your option) any later version.
 + *
 + * This library is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the GNU
 + * Lesser General Public License for more details.
 + *
 + * You should have received a copy of the GNU Lesser General Public
 + * License along with this library; if not, write to the
 + * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 + * Boston, MA 02111-1307, USA.
 + */
 +#include <cairo/cairo.h>
 +#include <gtk/gtk.h>
 +
@ -2799,10 +3655,10 @@ index 0000000..22abc6c
 +void foo_scroll_area_end_auto_scroll (FooScrollArea *scroll_area);
 diff --git a/capplets/display/xrandr-capplet.c b/capplets/display/xrandr-capplet.c
 new file mode 100644
-index 0000000..e56b9c5
+index 0000000..c003b2d
 --- /dev/null
 +++ b/capplets/display/xrandr-capplet.c
-@@ -0,0 +1,1624 @@
+@@ -0,0 +1,1676 @@
 +/* Monitor Settings. A preference panel for configuring monitors
 + *
 + * Copyright (C) 2007, 2008  Red Hat, Inc.
@ -2829,7 +3685,7 @@ index 0000000..e56b9c5
 +#include <string.h>
 +#include <stdlib.h>
 +#include "scrollarea.h"
-+#define I_KNOW_THIS_IS_UNSTABLE_AND_ONLY_IN_FEDORA
+#define GNOME_DESKTOP_USE_UNSTABLE_API
 +#include <libgnomeui/randrwrap.h>
 +#include <libgnomeui/monitor-db.h>
 +#include <gdk/gdkx.h>
@ -4273,12 +5129,64 @@ index 0000000..e56b9c5
 +}
 +
 +static void
 +compute_virtual_size_for_configuration (Configuration *config, int *ret_width, int *ret_height)
 +{
 +    int i;
 +    int width, height;
 +
 +    width = height = 0;
 +
 +    for (i = 0; config->outputs[i] != NULL; i++)
 +    {
 +	Output *output;
 +
 +	output = config->outputs[i];
 +
 +	if (output->on)
 +	{
 +	    width = MAX (width, output->x + output->width);
 +	    height = MAX (height, output->y + output->height);
 +	}
 +    }
 +
 +    *ret_width = width;
 +    *ret_height = height;
 +}
 +
 +static void
 +check_required_virtual_size (App *app)
 +{
 +    int req_width, req_height;
 +    int min_width, max_width;
 +    int min_height, max_height;
 +
 +    compute_virtual_size_for_configuration (app->current_configuration, &req_width, &req_height);
 +
 +    rw_screen_get_ranges (app->screen, &min_width, &max_width, &min_height, &max_height);
 +
 +    g_print ("X Server supports:\n");
 +    g_print ("min_width = %d, max_width = %d\n", min_width, max_width);
 +    g_print ("min_height = %d, max_height = %d\n", min_height, max_height);
 +
 +    g_print ("Requesting size of %dx%d\n", req_width, req_height);
 +
 +    if (!(min_width <= req_width && req_width <= max_width
 +	  && min_height <= req_height && req_height <= max_height))
 +    {
 +	/* FIXME: present a useful dialog, maybe even before the user tries to Apply */
 +	g_print ("Your X server needs a larger Virtual size!\n");
 +    }
 +}
 +
 +static void
 +apply (App *app)
 +{
 +    GError *err = NULL;
 +
 +    configuration_sanitize (app->current_configuration);
 +
 +    check_required_virtual_size (app);
 +
 +    foo_scroll_area_invalidate (FOO_SCROLL_AREA (app->area));
 +    
 +    if (configuration_save (app->current_configuration, &err))
--- a/gnome-control-center.changes
+++ b/gnome-control-center.changes
@ -1,3 +1,8 @@
 -------------------------------------------------------------------
 Thu May 29 20:40:32 CEST 2008 - federico@novell.com
 - Updated gnome-control-center-randr-1.2.diff with the latest fixes from upstream.
 -------------------------------------------------------------------
 Tue May 13 11:08:27 CEST 2008 - vuntz@suse.de
--- a/gnome-control-center.spec
+++ b/gnome-control-center.spec
@ -19,7 +19,7 @@ Group:          System/GUI/GNOME
 Obsoletes:      fontilus themus acme
 Provides:       fontilus themus acme
 Version:        2.22.1
-Release:        19
+Release:        27
 Summary:        The GNOME Control Center
 Source:         gnome-%{_name}-%{version}.tar.bz2
 Source1:        control-center-art.tar.bz2
@ -227,6 +227,8 @@ fi
 %{_libdir}/pkgconfig/*.pc
 %changelog
 * Thu May 29 2008 federico@novell.com
 - Updated gnome-control-center-randr-1.2.diff with the latest fixes from upstream.
 * Tue May 13 2008 vuntz@suse.de
 - Add gnome-control-center-bnc373197-layout-switch-keybinding.patch
  to change the default keyboard layout switching to