4
only when there is a tablet attached.
6
Here is the OS X Display menu:
10
--------------------------
12
- 1280 x 1024, 60 Hz, Millions
14
--------------------------------
17
--------------------------
20
Color LCD means "laptop panel".
24
Allow applications to be notified whenever monitors are added
25
or removed. Allow applications to get more detailed
26
information about the connected monitors.
28
The main complication is that XRRGetScreenResources() is very
29
slow. We could call it only when the X server sends an event,
30
but it's not desirable to have every application freeze for
31
half a second. And certainly not desirable to have the X
32
server block for n * 0.5 seconds.
34
With the X server work below we should be fine just calling
35
XRRGetScreenResources on startup and in response to events.
39
X server needs to poll for whether a monitor is plugged
40
in. Whenever it detects a change, it should do an EDID query,
41
and cache the resulting information. That way XRRGetScreenResources()
42
can be the speed of a normal roundtrip. It's desirable that
43
normal client requests can still be processed during the EDID
44
querying, but only a nice-to-have.
46
Drivers need to work reliably. There could be substantial work
47
here. For F9, possibly only the Intel driver can be made to
50
Interrupts and events must be generated whenever something changes
51
about the outputs, if necessary by polling.
53
Events must be emitted whenever something changes, including when
54
the reason for the change is a manual change.
56
The maximum framebuffer must be dynamically changable.
59
Capplet needs to be written. The main complications:
61
- It needs to pay attention to events from the X server
62
and update itself, ie., add show new monitors if they become
63
available when the applet is shown.
65
- It needs to store information under a key computed
66
from a monitor identifier. The complication here is that
67
it's not completely clear how to do this in GConf.
69
- Would probably be worthwhile to drop libgnome/libgnomeui from
73
- Metacity is already Xinerama aware, but it needs to update itself
74
when monitors come and go.
77
- Is already Xinerama aware, but needs to listen and update itself
81
- Make sure it deals sensibly with multiple monitors
84
- Make sure it deals sensibly with multiple monitors
86
- An Xlib call to just return all the available information would be
87
useful. At the moment we have to do a bunch of roundtrips to
88
get the information. This is a would-be-nice though.
90
- A dbus service could be written that pops up the applet whenever a
91
monitor. It should only pop up if the new monitor is unknown. This
92
is at best a nice-to-have, and low priority in my opinion.
95
******************* Metacity
99
> I was just talking to bryan about this and "helping" him design it ;-)
101
> But I wanted to be sure and lobby for a fix window managers
102
> need. Basically right now the WM can't tell "physical" from
103
> "logical" monitors.
105
> A "logical" monitor is a desktop; it has its own panel, windows
106
> maximize to it, etc.
108
> A "physical" monitor is a piece of hardware.
110
> Sometimes people want to combine physical monitors into a video wall
111
> or just two monitors treated as one. Or at least a couple of noisy
112
> people in bugzilla want to do this.
114
> When people talk about a "Xinerama aware" app or WM they usually
115
> mean that all physical monitors are treated as logical monitors,
116
> while lack of Xinerama-aware means treating the entire X screen (all
117
> physical monitors) as one logical monitor.
119
> The problem is that the setting for "ignore Xinerama" or "don't be
120
> Xinerama aware" should be global to the desktop (GTK, all apps, WM)
121
> and should not be a window manager setting.
123
> Bryan thought people who wanted non-Xinerama-aware should just use
124
> fvwm, which may be right, but what I'd say is that if there is any
125
> setting for this, it should be desktop-global and in this monitor
128
> It should not be a metacity or Compiz option, but in some way an X
129
> option in short. The implementation could be either an X server
130
> feature or an EWMH hint or whatever, but it should be controlled by
131
> the monitor config dialog and used by apps, GTK, etc. in addition to
134
> People tend to insist this should be a WM option, but that's just
135
> busted, since GTK and apps also have Xinerama-awareness features.
138
******************* EDID
140
edid-decode enhancements:
142
- Rejects years <= 0x0f for all versions, but this should only be done
143
for monitors claiming conformance to 1.4 (since 1.4 was released in
144
2006). A monitor produced in 2005 should have 0x0f - it's the only
145
reasonable thing to do.
147
- Uses 0x80 as the conformance mask for 1.4, should be 0
149
- Should read from stdin
151
- Should parse xrandr -verbose output more robustly
153
- Color depth computation is wrong. It uses the formula
155
(edid[0x14] >> 3) + 2
157
The correct formula to use is
159
(edid[0x14] & 0x70) >> 3 + 4
164
Computing a display name from EDID information:
166
vendor = lookup_vendor (code);
168
if (dsc_product && !is_gobbledigook (dsc_product))
170
if (vendor && !fuzzy_string_search (vendor, dsc_product))
185
append (" %d\"", inches)
188
(Does this internationalize at all)?
190
We also need the ability to get laptop names. The laptop panel may report
191
a manufacturer that has nothing to do with the laptop manufacturer.
193
Needed XRandr output properties:
195
- Modes that the monitor supports, or enough information that the
196
client can go throught the list of modes for the relevant
197
CRTC/Outputs and filter those out that the monitor can't support.
199
- The preferred mode, if any. Also useful if we could get a "strongly
200
preferred" indication if it's an LCD with a fixed resolution.
202
- Sufficient information that a fairly specific identifier can be
203
computed. The algorithm the client should use is:
205
1 Have we seen exactly this monitor before? If yes, use
208
2 Have we seen a monitor with similar specs before? If yes,
209
use settings for that. (But don't save, unless the user
210
changes the settings).
212
3 Otherwise, use some reasonable default for the monitor and
215
A setting should only be used if the CRTC/Output allows it. Ie,. if
216
a user has installed a new video card, then previously-used settings
217
may no longer apply, so this must be checked every time.
219
(1) Implies that we really need a globally unique identifier for
220
monitors. (2) is useful in an enterprise setting, but not absolutely
221
critical, since (3) would still handle the majority of cases.
223
There is a question here: Where are machine specific preferences
224
stored? Havoc mentions three possibilities here:
226
http://mail.gnome.org/archives/gnomecc-list/2001-October/msg00023.html
228
I'm not sure if any of them are implementable at this point. Also
229
(1) may mostly take care of the problem.
234
1. Fixed setup with some number of monitors.
235
- They should be set to the correct mode on login.
236
Note that this involves setting the right position in the
239
What if someone swaps two monitors? Users are going to expect
240
that the images will switch position.
242
2. Laptop being moved between home and work
243
- Setups should be detected and the correct mode set, at least on
244
login, but ideally when you put the laptop into the docking
247
3. Laptop gets projector plugged in.
249
Note the same model monitor can be used in two different ways. Ie.,
250
at home, it's being used at one resolution, at work the same type of
251
monitor is used at a different resolution.
255
- The on-disk database is just a list of monitors. Each monitor has an
256
associated mode. This has these problems:
257
- If someone uses the same monitor model in two different ways.
258
- If someone swaps the monitors around
262
- The on-disk database is a list of configurations, where a
263
configuration is a list of monitors and what outputs they are
264
connected to, and the position in the framebuffer.
266
- Picking a default configuration is then a matter of selecting the
267
closest existing configuration from the database.
269
- If the stored configuration is a subset of the existing,
270
then use that - then pick the best mode available for the
273
- If the stored configuration is a superset of the existing,
274
then use the projection of the configuration onto the monitors.
276
- Pick the configuration with the most overlap in monitors.
277
Although, if a configuration differs only in what outputs
278
they are connected to, then those outputs should probably
279
get their original modes set.
283
- If there is an exact match, use it, if not, pick a default.
285
- Picking a new default must never change the mode of any existing
288
******************* Capplet
290
Somehow the applet will find out that a new monitor is plugged in
291
(either through notification, or through a refresh button). When this
292
happens, this monitor is looked up in a database and if it is found,
293
some suitable mode is set.
295
Restrictions on the modes:
297
- Monitors that are already plugged in should not get their mode
298
changed just because a new monitor is plugged in.
300
- If the exact configuration of monitors is known, and all the old
301
monitors have the same mode as the known configuration, then just use
302
the known configuration. Also do this, if the configuration is a
303
subset of something known.
305
- Otherwise, if the configuration is a subset of a known configuration
306
where the only difference is that existing monitors have different
307
modes, then try and convert that mode to something we can know
308
about. Maybe configurations should be stored in terms of edges that
311
- Otherwise, just pick some good default for the mode, probably based
312
on the EDID prferred mode if possible. By default cloning is
315
- How do virtual desktops interact with this?
322
- It reads the configuration file into memory
326
- It gathers the existing configuration from randr
328
- If the existing config is in the file, set that mode
330
- On changes, including changes to the config file [this is crack]
332
- Reread configuration file
334
- Compare new configuration to database, if it is there, set the
337
- If a monitor was added, pop up a bubble
339
capplet --show-bubble
349
- When user changes something,
351
- Write configuration to file
356
- configuration file changes
357
- randr code will have to be shared between gcc and gsd
359
- binary installed by gcc
360
- something will still have to listen for changes to pop
361
up the notification bubble.
363
Structure of capplet:
365
- There is a database on disk with monitors and their corresponding
368
- On startup, this database is read into memory. When the user accepts
369
new settings, it is written back to disk.
371
- When something changes about the settings
373
- If new configuration is in the database, use that mode
375
- Else, find all outputs that are now connected but weren't before,
376
and set a default mode for them.
378
- If GUI is running, update graphics.
381
- Notification thing:
384
- if the new configuration is found in the database, use it
386
and added if they are not already there. Initial settings are
387
1 what the output is already doing, if anything
388
2 based on an existing sufficiently similar monitor, if possible
389
3 some reasonable default.
391
- When the user changes settings in the GUI, the corresponding monitor
392
in the database is updated.
394
- Whenever the GUI settings change, for all displayed monitors the
395
possible modes are recomputed.
397
- Whenever a new monitor is selected in the GUI, it first gets all its
398
possible modes computed based on the selections on other
399
outputs. Then, if the possible modes include the existing choice of
400
resolution, that is selected.
404
- initially, the settings are copied from the current settings
406
- whenever a gui setting changes for a monitor, all the other
407
monitors get their list of choices set to whatever is possible
408
given the chocie for the current monitor. A 'desired mode' is
409
maintained, and the closest choice to that is displayed. Whenever
410
the user actively selects something, that becomes the desired mode
415
- Generate all outputs that are newly connected
417
foreach_newly_connected (Configuration *before, Configuration *after,
420
- A way to generate the best mode for a connected output
422
existing best_mode() can probably be used
424
- Given a list of modes, pick the one closest to a given mode.
426
(a possibility here is: pick an exact match, if that's
427
impossible, then pick the best one with the same
428
width/height, if that's impossible, then just pick the
429
best mode on the list).
431
- For a configuation, fix the mode for a subset of the outputs, then
432
list the combinations for the rest of the outputs.
434
An obvious possibility here is to simply list all possibilities,
435
then weed out those that don't work. Is this too expensive?
438
Structure of login time program:
440
- The configuration database is read
442
- The current hardware configuration is generated
444
- If the current configuration is found in the database, that mode is set.
446
- If it isn't found, then nothing changes.
448
This could just be gnome-screen-resolution-capplet --reset
450
******************* Things that need to be done to the xrandr.patch:
454
XRRGetScreenResources() is a roundtrip and very slow (~0.5 s). GTK+
455
needs to keep information up-to-date by tracking events rather than
456
calling this function. In fact we probably can't call it at all unless
457
its performance improves significantly.
459
If EDID processing really has to be this slow, and we can't get
460
interrupts when monitors are plugged in, then we have a problem,
461
because we can't do anything this expensive once per second.
464
Detailed notes (but most of the patch should be rewritten):
467
=== FIXME in gdkscreen-x11.c in get_width_mm()
469
/* monitor pixel width / screen pixel width * screen_physical width */
473
=== Check for 1.2 library
475
The patch should check that the 1.2 version of the XRandR library is
476
available before using the functions. A possibility is to not use any
477
RandR unless 1.2 is available, another is to conditionalize the code.
479
The most sane thing is probably to just require 1.2.
481
On the other hand, installing a newer gtk+ on a system with older X is
482
probably not that unusual, so maybe it's better to do the full 1.0,
483
vs. 1.1 vs 1.2 check.
485
For now it just requires 1.2.
487
Actually, this might be fine because the only place where we make use
488
of a 1.1 library is in the _gdk_x11_screen_size_changed() function,
489
but there we have a fallback that just updates the variables in the
490
Screen struct itself.
492
So, only defining HAVE_RANDR if we detect 1.2 should be ok.
494
=== Monitor information available
496
- Subpixel information. This should be set automatically for the fonts and
497
store under the name of the monitor. If the user changes the font
498
configuration, that change should also be stored under the monitor name.
500
- When a monitor we don't know about is plugged in, a configuration should
503
- Screen size, computed based on the location of the screens
507
- Whether the screen has a panel on it
509
- If there is a conflict between stored information and EDID,
510
the stored information wins
516
(* monitors_changed) signal
517
gdk_screen_get_monitor_width_mm()
518
gdk_screen_get_monitor_height_mm()
519
gdk_screen_get_monitor_name() => Note this is the output (eg. "DVI-0")
521
We should probably also have
528
Should there be a GdkMonitor object that would correspond to an
529
output? Or maybe GdkOutput?
531
screen_list_monitors()
534
*************************** Issues XRandR/Xserver
536
- We need polling in the X server, whenever something changes, X must
537
recompute the information and cache it, then send an event. Note the
538
situation where the user disconnects and reconnects a monitor within
539
the polling interval. The event could missed in that case since the polling
540
cannot do a full EDID query. Difficult to see a way around this.
542
Actually, DDC allows random access, so it should be possible to just
543
read theq vendor id and manufacturer codes. This can be done once a
544
second without a problem. The polling should be turned off in power
551
- EDID information is not reported for VGA when the output is not
552
turned on (i945 laptop).
554
- Screen size must be dynamically changable. (No xorg.conf changes
557
- Make use of ACPI information when possible.
559
Adam has code on his freedesktop page.
561
- i830 laptop can be put in a state where XRandr reports that no
562
outputs are connected to a CRTC, but the panel is on.
566
- xrandr --output VGA --off
568
- xrandr --verbose will now not report any outputs as turned on
569
- run chk again - all screens will be turned off
571
- Small Sun monitor - an 1152x921 mode is generated, but the
572
monitor doesn't handle that. The monitor itself only claims to
573
handle 1152x920. It doesn't look to me like there is anything
574
in the EDID information that would indicate that it could handle
577
This happens with a radeon as wellso it may be a bug in the
578
generic X server EDID parsing. The X server apparently
579
interpretes the standard timing 1152x920 as 1152x921.
581
This happens because the X server uses
585
which gives 921 for 1152. By using
589
you get 920. The 66 Hz version can bet set, the 76 Hz mode gets
590
sync out of range. (Would be interesting to find out whether the
591
1152x920 ModeLine would allow the 76 Hz version to be set).
593
This is for the ATI driver as shipped in F8:
595
- XRRGetScreenResources() takes half a second.
597
- Adam has now removed a workaround that caused some of the slowdown.
599
- If a DVI monitor is disconnected, you get "Unknown" for connection
602
- If a VGA monitor is plugged in, then EDID information is not
603
available, even after running xrandr --verbose. The monitor has
604
to be plugged in at driver startup time, apparently.
606
- Logging out and logging back in often results in some random mode being
607
set. We need mode selection to not be completely screwed up.
610
- The set up at server startup needs to be fixed. *If* randr actually works,
611
then we might be able to do something sensible.
613
- We need to revisit the idea that many monitors have broken EDID data.
614
This may be less widespread than previously believed.
616
- It may be useful to return the connector names as identifiers instead
617
of relying on UTF-8 strings. Ie., have an enum
619
{ UNKNOWN, OTHER, DVI, VGA, HDMI, ..., }
621
in addition to the string. The difference between UNKNOWN and OTHER is that
622
UNKNOWN means the driver doesn't know, whereas OTHER means it is something
623
not listed in the enum (which could be listed in a later version).
625
- Mouse cursor should be confined to the visible area. (It is already, I think)
627
- It looks like EDID information is only available for one output
628
even though it is actually read according to the log file.
632
*********************************
640
- i830 laptop incorrectly reports BadMatch when you configure the
641
CRTC to drive both VGA and LVDS with the 1024x768 mode that both
642
outputs can handle. (It should return 'failed' if it can't do
643
that). Same for i945 laptop. It seems as if the same CRTC can't
644
drive more than one output at the same time on Intel.
646
This was a client bug, but the documentation for SetCrtcConfig
647
should say that BadMatch will be returned if the outputs aren't
650
GTK+ patch is in now.
652
=== Add helper function
655
+ if (screen_x11->randr12)
657
+ XRRScreenResources *sr;
658
+ XRROutputInfo *output;
661
+ sr = XRRGetScreenResources ( screen_x11->xdisplay,
662
+ screen_x11->xroot_window );
664
+ output = XRRGetOutputInfo ( screen_x11->xdisplay,
666
+ (RROutput)screen_x11->act_outputs[monitor_num]
669
Might be worthwhile to factor this out into a
670
gdk_screen_get_output_info (screen, monitor_num)
673
Instead of cutting and pasting all over creation
675
* Calling XRRGetScreenResources all the time is not going to fly. It
676
takes hundreds of milliseconds ... Even if it didn't, it wouldn't
677
be acceptable to do all those roundtrips.
680
=== Some g_prints left
685
Should be (maj > 1) || (maj == 1 && min >= 2)
691
=== Setup XRRSelectInput()
693
You should call XRRSelectInput() at the same place where you are
694
calling XSelectInput() right now. The right place to handle the
695
XRandr events is the huge switch in gdkevents-x11.c:gdk_event_translate
696
Check out how other extension events are handled there, like
700
=== Lots of variable naming issues, such as act_output and noutput
702
=== Needs to select the input, and hook it up to the signal
704
=== Add version markers to API
706
=== API to turn monitors on and off?
708
- DPMS not exposed through randr, maybe should be
710
- DPMS is presumably a property of either an
711
output or a CRTC. Logically it's an output.
713
- Need events when DPMS happens. Exposing the "screen saving on" on
714
dbus may not be good enough.
716
=== Why does init_multihead_support() start by freeing monitors and
719
=== Do we disable Xinerama support entirely when 1.2 is in use?
721
=== We should expose information about what parts of the screen monitors
724
=== Make use of the EDID information?
728
In nv driver SorSetOutputProperty should return TRUE for unknown
729
properties. (Like the Intel driver does).
736
- One ddc probe takes 5 ms, according to a comment in the intel
737
driver. Running this twice a second would mean spending 1% of
738
overall time doing ddc polling, which is almost certainly not
743
void I2CProbeAsync(..., callback, data);
747
In Dispatch, call I2CUpdate()
748
Before going idle, do
754
RegisterDispatchFunction() (Is this called Wakeup?)
755
RegisterIdleFunction()
757
Note the idle function should have the option of saying:
758
"check if something else happened; if not, call me again" and
759
"ok, I'm done - go idle". Otherwise, we would be blocking for
760
5 ms whenever the X server went idle. So actually the idle
766
return TRUE; /* call me again */
770
return FALSE; /* I'm done */
773
What happens if another I2C requests come in while an async one
774
is pending? Most likely we simply finish whatever is going on,
775
then process the new request.
777
What happens if an X request takes so long that we get timeouts on
778
the i2c bus? Good question. Need to read the VESA ddc spec.
780
2) Run the polling in a separate thread.
784
3) Run the polling less, maybe once every three seconds.
787
- Currently it is polling via rw_screen_refresh(), which will always emit
788
a screen-changed event. In reponse to this event the capplet currently
789
checks whether anything changed physically about the setup. This means
790
the capplet can't react to external changes to modes. On the other hand
792
Disallow combinations that would exceed the screen ranges.
795
Give rw objects stable positions in memory so that they can be cached
796
across screen_changed events.
800
Drag and drop for the monitors
801
- 2 dimensional layout
803
Store make and model in monitors.xml, then if serial numbers don't
804
match, fall back to a make and model match. Users with an nfs mounted
805
home directory should not have to reconfigure for each new system they
808
Make sure text is scaled correctly
810
Need to sanitize naming
811
RWOutput vs Output - should probably be OutputInfo
812
rate vs. freq - decide on one
814
Should probably reconsider the use of null terminated arrays.
815
Maybe lists would be better.
817
Pick a fixed scale, so that two 1024x768 don't look like two 6x4.
818
- An alternative would be to draw a checkerboard pattern
827
Disable panel checkbox for now
829
Patch into gnome-desktop
831
Find out how to share code between gcc and gsd
833
Make it assign coordinates correctly
834
- including computing correct screen size
added
removed
capplets/display/TODO
