GUI screen config tool should generate an randr 1.2 configuration where possible

Bug #144641 reported by James Henstridge
246
This bug affects 1 person
Affects Status Importance Assigned to Milestone
displayconfig-gtk (Ubuntu)
Critical
Bryce Harrington
Nominated for Hardy by sibidiba

Bug Description

Binary package hint: displayconfig-gtk

Where possible, displayconfig-gtk should generate an xorg.conf file that uses RandR 1.2 rather than the older xinerama server code, as it makes better use of the card's features (e.g. sharing a single framebuffer for multiple monitors), and allows runtime reconfiguration of the displays.

There is some information on configuring an initial RandR 1.2 layout available on the Intel Linux Graphics website:

    http://www.intellinuxgraphics.org/dualhead.html

The instructions there worked when configuring dual head on my Radeon 9200SE, modulo different naming of the outputs. To configure the "DVI-0" and "VGA-0" outputs on my system, I used the following configuration fragment:

  Section "Device"
          Identifier "ATI Technologies Inc RV280 [Radeon 9200 SE]"
          Driver "ati"
          BusID "PCI:1:0:0"
          Option "monitor-DVI-0" "Sony SDM-S74 [1]"
          Option "monitor-VGA-0" "Sony SDM-S74 [2]"
  EndSection

  Section "Monitor"
          Identifier "Sony SDM-S74 [1]"
          Option "DPMS"
          HorizSync 30-65
          VertRefresh 50-75
          Option "LeftOf" "Sony SDM-S74 [2]"
  EndSection

  Section "Monitor"
          Identifier "Sony SDM-S74 [2]"
          Option "DPMS"
          HorizSync 30-65
          VertRefresh 50-75
  EndSection

  Section "Screen"
          Identifier "Default Screen"
          Device "ATI Technologies Inc RV280 [Radeon 9200 SE]"
          Monitor "Sony SDM-S74 [1]"
          DefaultDepth 16
          SubSection "Display"
                  Modes "1280x1024" "1024x768" "800x600" "640x480"
                  Virtual 2560 1024
          EndSubSection
  EndSection

One quirk I noticed was that I could not specify the position of the VGA-0 monitor relative to the DVI-0 monitor -- I needed to do the opposite. From a look at the "xrandr" command line tool output, this is probably because the VGA-0 output is the first one, and they set up the outputs in order so it doesn't know how to process the positioning option.

---

GNOME control center folks have said they prefer a C-based solution to this, so rather than add xrandr to displayconfig-gtk, they suggested merging efforts with Soren's work.

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

I am already working (planing phase) on integrating xrandr into guidance. But it requires a lot of code refractoring. The goal of displayconig-gtk is to support both worlds.

I will use this bug as a duplicate collection for all xrandr feature requests in the future.

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

The xrandr bindings for python would be a field of working too.

Changed in displayconfig-gtk:
status: New → In Progress
Revision history for this message
Bryce Harrington (bryce) wrote :

Sebastian, can you outline some of the tasks required for implementing this, if there are things others could help with?

Revision history for this message
Xvani (fredrile+launchpad) wrote :

In my opinion, this should recieve more priority. It is FAR too difficult for a new user to select dual screen, or even use this tool at all. (It just doesn't work for 2 monitors....)

At work, this is one of the main arguments against using ubuntu.

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

Be sure that it has got the priority that it deserves.

Revision history for this message
Thom Pischke (thom-pischke) wrote :

Also eagerly watching this issue, hoping this will help me manage dual montors with the intel x3100

Revision history for this message
Thom Pischke (thom-pischke) wrote :

This bug is marked as 'In Progress', but has had no updates in two weeks, and is assigned to nobody. Maybe this should be set back to 'Confirmed'?

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

It won't be fixed for weeks or monthes and perhaps never for Gutsy. We started to work on the Python bindings for XRandR 1.2. As soon as they are done I am going to port guidance (the backend of displayconfig-gtk) to the new code.

See https://edge.launchpad.net/python-xrandr

Revision history for this message
Thom Pischke (thom-pischke) wrote :

Thanks for the update! Always nice to know there's a roadmap.

Revision history for this message
Brian Pitts (bpitts) wrote :

When this is finished I hope it will have all the functionality of grandr.

http://gitweb.freedesktop.org/?p=xorg/app/grandr.git;a=summary

Revision history for this message
Motin (motin) wrote :

So do I!

The integration of grandr functionality and xrandr-based configuration file generation should IMO have far greater priority for Hardy! Basically "everything" that we have been longing for in terms of dynamic display configuration is already possible in Gutsy using xrandr cli and adjusting the "Virtual" setting in xorg.conf,

It is really time for this to become available for the common user!

Revision history for this message
Thom Pischke (thom-pischke) wrote :

Yes, curious to know if and when this might land in Hardy.

Bryce Harrington (bryce)
Changed in displayconfig-gtk:
importance: Undecided → Critical
Revision history for this message
Thom Pischke (thom-pischke) wrote :

Three Cheers for Importance -> Critical! Having this in Hardy would finally squelch one of the last significant shortcomings of Ubuntu on my Dell 1420n.

Revision history for this message
Bryce Harrington (bryce) wrote :

I've been working on a different approach to solving this bug, but adding xrandr 1.2 support to the existing Screen Resolution tool: http://bryceharrington.org/files/screenrez_a.png

Changed in displayconfig-gtk:
assignee: nobody → bryceharrington
Revision history for this message
unggnu (unggnu) wrote :

It looks great. I would appreciate this. Is there a version for testing purposes?
Btw. is displaconfig-gtk needed anymore with xorg.conf free configuration? I am not sure if all graphic/monitor configuration work with autodedection and xrandr but maybe it could be a fall back option which could be installed.

Revision history for this message
Motin (motin) wrote :

@unggnu: Despite fewer mandatory configuration items in xorg.conf there are some things that are suited to remain in it. For instance, desired RandR defaults can be specified therein, making it unnecessary to run xrandr-based scripts upon login to get that extended desktop configured etc.

But whether or not displayconfig-gtk is needed or can be replaced by some other application - I'd say probably. But, of the three major apps in this area: grandr, urandr and displayconfig-gtk, it seems that displayconfig-gtk is the most active for the moment and most likely to remain the default screen configuration application - granted that it will solve this bug... Also I think displayconfig-gtk is the only one that actually modifies xorg.conf, but I am not sure on that point.

@Bryce Harrington: I am curious to know if you are adding the possibility to write the RandR-configuration into xorg.conf as well or making a wrapper around xrandr? I too would love to try a test version btw...

Cheers,

Fredrik

Revision history for this message
Bryce Harrington (bryce) wrote : Re: [Bug 144641] Re: displayconfig-gtk should generate an randr 1.2 configuration where possible
Download full text (3.2 KiB)

I'm working on getting the apply button working before uploading a test
version.

displayconfig-gtk is probably going to still be needed for non-xrandr
enabled drivers, and probably also for bulletproof-x mode. But
otherwise, that's correct that for xrandr-enabled drivers,
displayconfig-gtk will not be required.

On Fri, Feb 15, 2008 at 12:09:46AM -0000, unggnu wrote:
> It looks great. I would appreciate this. Is there a version for testing purposes?
> Btw. is displaconfig-gtk needed anymore with xorg.conf free configuration? I am not sure if all graphic/monitor configuration work with autodedection and xrandr but maybe it could be a fall back option which could be installed.
>
> --
> displayconfig-gtk should generate an randr 1.2 configuration where possible
> https://bugs.launchpad.net/bugs/144641
> You received this bug notification because you are a bug assignee.
>
> Status in Source Package "displayconfig-gtk" in Ubuntu: In Progress
>
> Bug description:
> Binary package hint: displayconfig-gtk
>
> Where possible, displayconfig-gtk should generate an xorg.conf file that uses RandR 1.2 rather than the older xinerama server code, as it makes better use of the card's features (e.g. sharing a single framebuffer for multiple monitors), and allows runtime reconfiguration of the displays.
>
> There is some information on configuring an initial RandR 1.2 layout available on the Intel Linux Graphics website:
>
> http://www.intellinuxgraphics.org/dualhead.html
>
> The instructions there worked when configuring dual head on my Radeon 9200SE, modulo different naming of the outputs. To configure the "DVI-0" and "VGA-0" outputs on my system, I used the following configuration fragment:
>
> Section "Device"
> Identifier "ATI Technologies Inc RV280 [Radeon 9200 SE]"
> Driver "ati"
> BusID "PCI:1:0:0"
> Option "monitor-DVI-0" "Sony SDM-S74 [1]"
> Option "monitor-VGA-0" "Sony SDM-S74 [2]"
> EndSection
>
> Section "Monitor"
> Identifier "Sony SDM-S74 [1]"
> Option "DPMS"
> HorizSync 30-65
> VertRefresh 50-75
> Option "LeftOf" "Sony SDM-S74 [2]"
> EndSection
>
> Section "Monitor"
> Identifier "Sony SDM-S74 [2]"
> Option "DPMS"
> HorizSync 30-65
> VertRefresh 50-75
> EndSection
>
> Section "Screen"
> Identifier "Default Screen"
> Device "ATI Technologies Inc RV280 [Radeon 9200 SE]"
> Monitor "Sony SDM-S74 [1]"
> DefaultDepth 16
> SubSection "Display"
> Modes "1280x1024" "1024x768" "800x600" "640x480"
> Virtual 2560 1024
> EndSubSection
> EndSection
>
> One quirk I noticed was that I could not specify the position of the VGA-0 monitor relative to the DVI-0 monitor -- I needed to do the opposite. From a look at the "xrandr" command line tool output, this is probably because the VGA-0 output is the first one, and they set up the outputs in order so ...

Read more...

Revision history for this message
Patrice Vetsel (vetsel-patrice) wrote : Re: displayconfig-gtk should generate an randr 1.2 configuration where possible

Are you sure that #178061 is a duplicate of this bug. Waiting GABOR CZIGOLA explanations i remove the duplicate.

Revision history for this message
Bastiaan Wakkie (bwakkie) wrote :

Standard Hardy start-up doesn't start xrandr correctly (I get a copy of my laptop monitor on the external screen) the top screen is also in a lower resolution than the maximum available. (I guess xorg doesnt detect it well enough)

So with the attached code (got it from somewhere I cant remember) I do the following (and it meight be usefull for others)

./external-monitor.sh off (I also kill awn in this command as it isnt working well with screen changes yet)
./external-monitor.sh on above 1280x1024

I guess this is also very handy if you are using a projector (as you can change the resolution appropriately)

Cheers,

Revision history for this message
Bryce Harrington (bryce) wrote :

I suspect the reason for duplicating to this was because of the plans stated above to switch to a new tool. However, I think the better plan would be to wait until this tool is in place and displayconfig-gtk has been removed from the System menu, and then go through and mark appropriate bugs as 'wontfix'.

But there are some situations where we are still using displayconfig-gtk (bulletproof-x in particular) so we need to take care not to close bugs too aggressively, because some may still need to be fixed anyway.

Revision history for this message
Brian Pitts (bpitts) wrote :

It seems like there are two bugs here

1) displayconfig-gtk writes an xorg.conf that prevents xrandr from working properly
2) displayconfig-gtk does not use xrandr to perform operations like adding/removing displays, rotating the screen, etc.

Bryce's work on a new tool is a reasonable fix for #2, but no one has said if #1 is fixed yet.

Bryce Harrington (bryce)
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

#1 is unfixable by design - displayconfig-gtk only understands xinerama style layouts, and since xrandr and xinerama are completely incompatible, this will always cause breakage on drivers which use xrandr.

Revision history for this message
sibidiba (sibidiba) wrote :

@Bryce Harrington: What do you mean by "unfixable by design"? This bug is exactly about displayconfig-gtk having a bug in it's "design". Xinerama is no longer available at all, not because of a driver issue, but because the whole X.org architecture changed in version 7.2. All legal drivers have to use xrandr by now.

Revision history for this message
Bryce Harrington (bryce) wrote :

Closing as fix committed - we've uploaded a patch to remove displayconfig-gtk from the system menu. It will still be available on the system for the few people still limited to Xinerama, but the new Screen Resolution tool is now the supported X configuration tool.

Changed in displayconfig-gtk:
status: In Progress → Fix Committed
Bryce Harrington (bryce)
Changed in displayconfig-gtk:
status: Fix Committed → Fix Released
Revision history for this message
Motin (motin) wrote :

So this means that a RandR 1.2 configuration is generated after the resolution / screen orientation / extended desktop settings are adjusted so that we can expect not to have to readjust the settings after every login? Also - will we be able to store profiles like with displayconfig-gtk so that we easily can switch between certain predefined setups?

Revision history for this message
Bryce Harrington (bryce) wrote :

Correct. These settings are now stored in your ~/.gnome2/monitors.xml rather than xorg.conf, so will be per-user settings rather than system-wide as with displayconfig-gtk. They are applied during login by gnome-settings-daemon. (A useful debugging tip to note, is that if your system gets messed up, deleting ~/.gnome2/monitors.xml will restore it to defaults.)

Regarding profiles, the long term design approach is that you'd be able to specify multiple configurations in monitors.xml, and the system would evaluate them based on what displays are connected, and automatically select between them. This includes hotplug detection of monitor plugin, so switching between predefined setups would be as simple as plugging/unplugging the monitors. Hotkey support is also in progress of implementation. So yeah, not only will it have profiles, but it should be even easier to make use of them. I expect most of these to hit for Intrepid (it's pretty late for any new features in hardy unfortunately).

If anyone is interested in coding on these or any other features, we'd be very interested in taking patches. The code's fairly straightforward C, mostly in gnome-desktop, with some UI stuff done in gnome-control-center, and the backend daemon interface in gnome-settings-daemon. I'd be happy to provide mentoring for anyone wishing to put more good ideas into the tool.

Revision history for this message
Motin (motin) wrote :

Sounds awesome Bryce! Good job anyone involved in these matters!

What of this, if anything, will be included in Hardy? I understand that the profiles part is more for Intrepid, but will the enhanced randr-enabled resolution tool land in (has already landed?) in Hardy?

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

The resolution tool is there already, it has replaced the old GNOME's Screen Resolution tool in System->Preferences.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers