Screen Resolution tool fails to switch between MergedFB "dualhead" and "clone" modes

Bug #41610 reported by Jiri Bajer
18
Affects Status Importance Assigned to Milestone
xserver-xorg-video-ati (Ubuntu)
Fix Released
Low
Ubuntu-X

Bug Description

possibly the same cause as bug #41607

https://launchpad.net/distros/ubuntu/+source/resapplet/+bug/41607/+index

gnome-control-center 2.14.1-0ubuntu2

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. Your bug has no detail nor useful description. Could you describe what dialog you use, what screen resolution you pick, what happens, what should happen instead, etc?

Changed in control-center:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Sebastien Bacher (seb128) wrote :

is that about "resapplet" or "gnome-display-properties" program?

Revision history for this message
Jiri Bajer (sarimak) wrote :

In a glance: if I use MergedFB for dual monitor setup the Screen resloution tool gets confused about refresh rates (in Hz) and cannot properly run xrandr backend to switch the resolutoins - even though xrandr itself can do it fine.

Since all docs are included in description of bug #41607 I didn't duplicate it here, but if it's more comfortable for you I can do it now in a separate comment... B-)

Revision history for this message
Jiri Bajer (sarimak) wrote : Configuration used to trigger the bug

configuration:
notebook HP compaq nc6000 (1400x1050) + external 19" LCD HP 1902 (1280x1024)
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
Linux sarim 2.6.15-21-686 #1 SMP PREEMPT Fri Apr 21 16:57:03 UTC 2006 i686 GNU/Linux => up-to-date Dapper Drake preview

xserver-xorg 7.0.0-0ubuntu2
resapplet 0.0.7+cvs2005
xserver-xorg-driver-ati 6.5.7.3-0ubuntu5
xrandr 1.0.1-0ubuntu1

xorg set-up using MergedFB with two available modes: 2680x1050 for "dualhead" and 1400x1050 for "clone/no external LCD" mode.

xrandr is able to switch between the modes but Screen resolution tool cannot and crashes instead. The same crash occurs when trying to do the same using resapplet from Universe.

xrandr reports invalid refresh rates (see output below) and the graphical utilities cannot handle it properly even xrandr can. I'll also file
a bug on xrandr package too and post its number here. Someone reported a bug in xrandr that could possibly have the same cause - see bug #33339...

sarim:~$ xrandr
 SZ: Pixels Physical Refresh
 0 2680 x 1050 ( 681mm x 267mm ) 6895
*1 1400 x 1050 ( 681mm x 267mm ) *-19554
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none

If I run the Screen resolution tool from commandline and try to switch the modes it crashes and I get an error like this:

sarim:~$ gnome-display-properties
The program 'gnome-display-properties' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 13128 error_code 2 request_code 157 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

sarim:~$ gnome-display-properties --sync
The program 'gnome-display-properties' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 31625 error_code 2 request_code 157 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Revision history for this message
Jiri Bajer (sarimak) wrote : xorg.conf used to trigger the bug (relevant excerpt, full dump in bug#41607)

Section "Device"
        Identifier "Radeon Mobility 9600 MergedFB"
        Driver "radeon"
        BusID "PCI:1:0:0"
        Option "MergedFB" "true"
        Option "CRT2HSsync" "30-80"
        Option "CRT2VRefresh" "59-85"
        Option "MonitorLayout" "LVDS,TMDS"
        Option "OverlayOnCRT2" "true"
        Option "MetaModes" "1400x1050-1280x1024 1400x1050"
        Option "MergedNonRectangular" "true"
        Option "CRT2Position" "RightOf"
        Option "MergedDPI" "100 100"
        Option "DynamicClocks" "true"
        Option "BIOSHotkeys" "true"
EndSection

Section "Monitor"
        Identifier "Generic LCD"
        Option "DPMS"
        Option "DDCMode" "on"
EndSection

Section "Screen"
        Identifier "MergedFB Screen"
        Device "Radeon Mobility 9600 MergedFB"
        Monitor "Generic LCD"
        DefaultDepth 24
        SubSection "Display"
                Depth 24
                Modes "1400x1050"
        EndSubSection
EndSection

Revision history for this message
Jiri Bajer (sarimak) wrote :

since xrandr shows invalid refresh rates I've also reported this as xrandr bug #42321. I'm not sure if the bug is in xrandr or xserver-xorg*. I'll try to investigate further but any help would be welcome. If you wish to receive more informations please tell me what are you interested in and I'll do my best to post them...

Revision history for this message
Jiri Bajer (sarimak) wrote :

Also see bug #34555 in xorg.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Seems to be an xorg bug to me. What do you expect from the capplet? Do you want it to workaround the xorg bug somewhat?

Revision history for this message
Jiri Bajer (sarimak) wrote :

I agree it's a xorg bug - but why xrandr tool works (is able to switch the modes even though it shows apparently bad sync values) and gui tool crashes?

If the capplet simply calls xrandr there should be no problem - and apparently is. What means a workaround for you? Simply calling xrandr with proper arguments should be no workaround... If you can arrange the code this way it would be great, thanks! (and thus resapplet could work properly too)

I tried to confirm the bug today (after dist-upgrade of course) and it still exists. Do you want me to send you some strace output or set core limit and send you a stack backtrace? If it helps, just ask...

Revision history for this message
Sebastien Bacher (seb128) wrote :

The issue is xorg returns a BadValue, should the capplet ignore them? How can it know than the call worked if xorg sent a BadValue? When the program gets a BadValue it assumes that the call has not worked. Setting as low priority, it could maybe made robust to xorg errors but most of the issue is due to xorg

Changed in control-center:
status: Needs Info → Confirmed
Revision history for this message
Andreas Leitner (aleitner) wrote :

Is there any news on this bug? I too miss the ability to switch between dual-head and clone mode very much. It gives quite a bad impression if you have to reboot or edit some config file right before a presentation just to make your notebook work with the projector... (;

Revision history for this message
Andreas Leitner (aleitner) wrote :

I just found the following in the ChanegLog of xf86-video-ati-X11R7.1-6.6.0 (the ati driver tar ball of the latest x11r7.1 release:

2006-04-01 Alex Deucher <email address hidden>

 * src/radeon.h:
 * src/radeon_driver.c: (RADEONPreInitModes), (RADEONPreInit),
 (RADEONResetDPI), (RADEONSwitchMode):
 * src/radeon_mergedfb.c: (RADEONMergedFBCalcDPI),
 (RADEONMergedFBSetDpi), (RADEONMergedFBResetDpi):
 * src/radeon_mergedfb.h:
 - Fix dpi when switching from clone to dualhead with MergedFB.
 - Add ConstantDPI option to force a particlar dpi across mode changes
 Both based on Thomas Winischhofer's sis code.

This sound pretty much like it could be the fix to the problem we experience, doesn't it? Any chances of applying this patch?

Changed in control-center:
assignee: desktop-bugs → ubuntu-x-swat
Revision history for this message
David_G (dgeorgester) wrote : patch works

I can confirm that the upstream patch works. A quick cut and paste and compile.
Perhaps someone should apply the patch to the ubuntu packages?

Revision history for this message
martin (mbvlist) wrote : Feisty works

I tested it in Feisty, and it works like a charm. xrandr returns the right refresh rates, as does the gui tool, and the resolution changes work.

However, I noticed several other resolution-related bugs, which I'll file in a fresh bug ;).

Revision history for this message
martin (mbvlist) wrote :

It was already fixed in Feisty, so Fix Released seems appropriate ;).

Changed in xserver-xorg-video-ati:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.