rpm/gnome-control-center
SHA256
1
0
Fork 0
forked from pool/gnome-control-center
Code Pull Requests Activity

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

Browse Source
This commit is contained in:
OBS User unknown 2008-05-31 10:19:52 +00:00 committed by Git OBS Bridge
parent 313281cd01
commit 609f327b8e
3 changed files with 923 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

922
gnome-control-center-randr-1.2.diff
View File

@ -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))

5
gnome-control-center.changes
View File

@ -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

4
gnome-control-center.spec
View File

@ -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