Bug 81128 - radeon: X insists on using 640x480 on external CRT display
radeon: X insists on using 640x480 on external CRT display
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
http://www.morlug.org/radeon
:
Depends On:
Blocks: 82776
  Show dependency treegraph
 
Reported: 2003-01-05 02:35 EST by Aleksey Nogin
Modified: 2007-04-18 12:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-15 02:38:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XF86Config (created by redhat-config-xfree86 when docked) (3.28 KB, text/plain)
2003-01-05 02:36 EST, Aleksey Nogin
no flags Details
XFree86.0.log (when running docked) (36.48 KB, text/plain)
2003-01-05 02:44 EST, Aleksey Nogin
no flags Details
XFree86.0.log (when not docked) (26.92 KB, text/plain)
2003-01-05 02:46 EST, Aleksey Nogin
no flags Details

  None (edit)
Description Aleksey Nogin 2003-01-05 02:35:30 EST
When my Dell Lattitude C640 laptop is docked, XFree86 would insist on using the
640x480 resolution and nothing bigger (despite both ddcprobe and XF86Config
correctly identifying the monitor). When not docked, the exact same config works
fine (X would use 1400x1050). I have not tried attaching the external monitor
(instead of docking), but my 8.0 experience suggests that with external monitor
it would work exactly the same way as when docked. 

In 8.0 the radeon driver would insist on limiting the resolution at 1280x1024
when docked or when external monitor is plugged in, but with the Option
"CrtScreen" it was happy to run at 1600x1400. But since XFree86 in Phoebe has a
new radeon driver, that option no longer works.

Of course, the problem is only made worse by the fact that neither of the two
versions of the radeon driver seems to have any documentation. I considered it
OK to have to read the source code to figure out the possible options and find a
way to go from 1280x1024 to 1600x1400, but IMHO 640x480 is so bad (note that
this means that even anaconda graphics mode runs with virtual resolution >
display resolution) that things need to work better by default.

ddcprobe when docked:

Videocard DDC probe results
Description:  ATI Technologies Inc. P7
Memory (MB):  32

Monitor DDC probe results
ID: DEL5000
Name: Dell P1130
Horizontal Sync (kHZ): 30-130
Vertical Sync (HZ)  : 48-170
Width (mm): 400
Height(mm): 300

ddcprobe when not docked:

Videocard DDC probe results
Description:  ATI Technologies Inc. P7
Memory (MB):  32

Monitor DDC probe results
Monitor DDC Probe failed.

I'll attach the config file and the log files (for docked and undocked).
Comment 1 Aleksey Nogin 2003-01-05 02:36:58 EST
Created attachment 89137 [details]
XF86Config (created by redhat-config-xfree86 when docked)
Comment 2 Aleksey Nogin 2003-01-05 02:44:14 EST
Created attachment 89138 [details]
XFree86.0.log (when running docked)

A few highlights from the log:

These lines are logged in both cases:

(II) RADEON(0): CloneDisplay option not set -- defaulting to auto-detect
(II) RADEON(0): Primary Display == Type 2
(II) RADEON(0): Panel ID string: SHARP LQ14F1LH02
(II) RADEON(0): Panel Size from BIOS: 1400x1050

Does this mean that "auto-detect" is not quite working? Or that it does not
realize what "primary display" should be used when docked?

The following lines are present only when docked:

(II) RADEON(0): Clone modes validation ------------
(II) RADEON(0): DDC detection (type 3) for clone modes
(WW) RADEON(0): Monitor0: Using default hsync range of 28.00-33.00kHz
(WW) RADEON(0): Monitor0: using default vrefresh range of 43.00-72.00Hz

after that it quickly decides that all hi-res modes have too big hsync and ends
up with 640x480 as the only available mode.
Comment 3 Aleksey Nogin 2003-01-05 02:46:46 EST
Created attachment 89139 [details]
XFree86.0.log (when not docked)

This log is produced using the exact same config as the previous one.
Comment 4 Aleksey Nogin 2003-01-06 00:53:58 EST
Status update:

If I just add 

        Option "CloneDisplay" "0"

to the "Device" section, X gives up on trying to do anything special for the
external monitor and just uses the snandard "1400x1050" resolution on both LCD
and  external CRT. This is much better than 640x480, but still not as good as
1600x1200 I used to have. I tried using 

        Option      "CloneMode" "1600x1200"
        Option      "CloneHSync" "30.0 - 130.0"
        Option      "CloneVRefresh"  "48.0 - 170.0"

and this had an effect of increasing the virtual size to 1600x1200, but I still get

(WW) RADEON(0): Monitor0: Using default hsync range of 28.00-33.00kHz
(WW) RADEON(0): Monitor0: using default vrefresh range of 43.00-72.00Hz

Comment 5 Aleksey Nogin 2003-01-06 01:36:31 EST
Ah, I found documentation for the driver - see http://www.morlug.org/radeon

Also turned out that I almost got it last time - the only issue was that there
can be no spaces in CloneHSync and CloneVRefresh, so

        Option      "CloneMode" "1600x1200"
        Option      "CloneHSync" "30.0-130.0"
        Option      "CloneVRefresh"  "48.0-170.0"

worked perfectly.

--------

Based on the above, the suggested solutions are:

1) (quick fix) Modify redhat-config-xfree86 (and anaconda) to add the
appropriate CloneMode/CloneHSync/CloneVRefresh options to the "Device" section
whenever the radeon driver is used (it should just use the same hsync and
vrefresh value ranges as in "Monitor" section, just w/o spaces). The CloneMode
should probably have the highest resolution (or can also be omitted).
2) Teach the radeon driver to do the DDC on the external monitor (after all,
ddcprobe does list the correct hsync/vrefresh, so the information is accessible)
to figure out the CloneHSync/CloneVRefresh automatically
3) It would probably be best to do both (1) and (2)

CCing bfox@redhat.com for the redhat-config-xfree86 part.

------

P.S. Is redhat-config-xfree86 capable of doing two-headed setups? If so, it
would be really great if it knew how to do it for the radeon cards that support
it (now that the driver is capable of it).
Comment 6 Brent Fox 2003-01-14 17:33:42 EST
No, redhat-config-xfree86 cannot currently do dual-head setups.  There have been
many requests so it's on my plans for the future, but not this release.  (I had
no idea so many people ran dual-head setups)
Comment 7 Aleksey Nogin 2003-01-14 18:10:21 EST
OK, then it's just down to choices 1-3 in comment #5. Does that sounds reasonable?
Comment 8 Mike A. Harris 2003-01-24 01:48:56 EST
No, it does not sound reasonable.  Any such changes like this must not
break _existing_ working setups.  This problem most likely is not going
to change unless it is changed upstream.  There are known workarounds
as you've indicated above also.
Comment 9 Mike A. Harris 2003-01-24 01:50:28 EST
*** Bug 81149 has been marked as a duplicate of this bug. ***
Comment 10 Aleksey Nogin 2003-01-24 04:58:59 EST
First, clarification - this is only about the resolution on external CRT. The
LCD always works correctly (even when CRT is plugged in!). Sorry if I confused
you - I was confused at first myself, since I did not realized that the new 4.3
driver (as opposed to the old 4.2 driver) now *by default* tries running LCD and
CRT at *separate* resolutions (while showing the same image).

Second,  your comment #8 make very little sense to me.

> Any such changes like this must not break _existing_ working setups.

What do you mean by "existing setups"? The new XFree86 has a completely
different (compared to Red Hat 8.0/ Xfree86 4.2) radeon driver. The mere fact of
upgrading from previous versions of RedHat would break existing setups. This bug
is about making sure that does not happen.

> This problem most likely is not going to change unless it is changed upstream.

What upstream? My suggested solution "1" is to extend redhat-config-xfree86 to
better support the quirks of the new driver. Also, I never suggested that
solution "2" should be implemented by Red Hat.  I only asked which solution
appears the most reasonable, and if consensus will be that "2" is a reasonable
choice, then of course I will report it upstream, 

Basically, I am not completely sure whether this is a configuration issue or a
driver issue - it seems to me that this is more of a configuration issue than a
driver issue (and quite possibly a combination of the two),  Right now I first
want to get an expert *opinion* on how this should be best solved.
Comment 11 Mike A. Harris 2003-01-24 06:41:23 EST
>Right now I first want to get an expert *opinion* on how this should be best
>solved.

By mailing a tech support forum such as xfree86@xfree86.org.

I don't know what the best solution to the problem is.  I don't consider
it a high priority (like the severity field suggests) to determine that
however either.

Bugzilla is not a tech support forum, and the more questions and discussions
that occur in bugzilla, that could/should be occuring on public mailing
lists (IMHO), then the more time I'm spending in bugzilla, and the less
time I'm spending fixing real bugs that get reported - perhaps even this
one.

I have no laptop hardware in any case, so I'm totally unlikely to be
running X in a debugger on a non-laptop to solve a problem that happens
on one laptop (or any laptop), especially if there is a workaround.

Query bugzilla for the total number of bugs open right now against XFree86,
realizing there is one person on the other side of the fence.  I hope
you understand that all 200 bugs wont be fixed before the final OS release.

Unless this one gets fixed upstream, it probably will remain as-is unless
some patch turns up on a mailing list somewhere that fixes it or something.

Sorry, but I don't have a lot of time to invest in a problem that could
be very difficult to solve without hardware.

Comment 12 Aleksey Nogin 2003-05-15 02:38:48 EDT
This seems to be working correctly in Cambridge alpha1

Note You need to log in before you can comment on or make changes to this bug.