moving from https://github.com/perberos/mate-desktop-environment

1 files changed, 837 insertions, 0 deletions

diff --git a/capplets/display/TODO b/capplets/display/TODO
new file mode 100644
index 00000000..08f9e21b
--- /dev/null
+++ b/capplets/display/TODO
@@ -0,0 +1,837 @@
+Highlevel overview:
+
+Tablet rotation things
+only when there is a tablet attached.
+
+Here is the OS X Display menu:
+
+	Detect Displays
+	Turn on mirroring
+	--------------------------
+	SyncMaster
+		- 1280 x 1024, 60 Hz, Millions
+	        - 1344 x ...
+	--------------------------------
+	Color LCD
+		- 1024 x 1024 ...
+	--------------------------
+	Displays Preferences
+
+	Color LCD means "laptop panel".
+
+- 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 MateConf.
+
+	- Would probably be worthwhile to drop libmate/libmateui from
+	  the craplets.
+
+- Marco work:
+	- Marco is already Xinerama aware, but it needs to update itself
+	  when monitors come and go.
+
+- MATE 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.
+
+
+*******************  Marco
+
+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 marco 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/matecc-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 mate-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 mate-desktop
+
+Find out how to share code between gcc and gsd
+
+Make it assign coordinates correctly
+     - including computing correct screen size
+