xresprobe drops highest available resolution on certain lcd's

I believe my theory that desktop LCD monitors not setting the digital bit in the
EDID is correct. The HP L2335 also seems to have this problem. A post on newegg
reviews shows the following:

"Once or twice when Linux boots up the monitor has auto-synced to 1600 x 1200
instead of 1920 x 1200 (which is what is being driven).". Link is here:
http://www.newegg.com/Product/Product.asp?Item=N82E16824176018

whoops my bad I miss read that statement... I wanted it to be the same problem
but it's not.

actually the problem here is just that ddcprobe's being non-specifically dumb.
only using the second-highest resolution for crts is obviously a design
decision, which I stand by utterly.

so, the options are:
a) just reverse that design decision and ignore the fact that lcds are seen as crts
b) attempt to identify every desktop lcd ever made as an lcd by id number
c) work out why lcds are seen as crts, fix that

I figured that was a design decision ... you don't really want to run a CRT at
it's highest possible setting ...ugly!
A quirk list is the best way to probably go about it.

The Nvidia Driver seems to know that the Screen is a digital flat panel. Perhaps
ddprobes is looking for the wrong thing to know that it is a digital flat
pannel. I just don't know enough about edid stuff.

So reading the Extended Edid spec on vesa.org
http://www.vesa.org/Public/EDID%20EXTENSIONS/DIEXT.pdf

It is clear that ddprobes is just out dated (way way way outdated). Reading the code
it looks like ddprobes only supports EDID 1.0 ...well in version 1.3 there have been
many additions. Page 20 clearly shows a better way to identify wheater you have
an LCD or not
by detereming if it is Fixed Pixed Format or not. So the digital identifier
currently in ddprobes is not
a good identified to tell if you have an LCD screen or not.

Sorry for the long delay...been in Vegas over the past week.

Ok the design decision in the ddcprobe.sh script to distinguish between an lcd
and crt is WRONG. The job of this script is to say what resolutions are
supported by the monitor device. Even if the design was correct Line 56 should
not be removing highest resolution supported on a crt. The user should have the
option to change to this resoultion if it is supported. So all supported
resolutions by any type monitor should be reported by ddcprobe.sh and some other
script should determine what resolution to start off with ...but all possible
resolutions should be in the xorg.conf at the end of the day. Maybe it should be
like Windows ... start off at 640x480 and the person then changes the resoultion
to what they want it to be.

What is going on with this bug? Daniel Stone has just unassigned himself from it. So if I want this fixed who is going to work on it. I sent Daniel Stone a patch via email for this. But he ignored...and I figured he just wanted nothing to do with this. I will attach the patch to this but but is anyone actually going to try to work it?

This patch fixes the problem for this bug by adding a quirk list to the xrepose script.

Someone from the X team will review this bug when they can

Can anyone test this out with a Feisty nightly and/or a currently updated Edgy so we can see if this bug still exists?

 Edgy still suffers from this problem. Noone has as of yet to address this.

Jerone, I share your emotions about fixing this bug, because I''ve seen a lot of instances of ubuntu showing the wrong resolution for both CRT and LCD displays. Other debian based linux distributions (such as knoppix) actually used get-edit|parse-edid to generate X configuration Monitor section, which seems to be better way to generate it than ddprobe, since it uses the monitors own information about the recommended resolution.

Current Xorg server (I'm using git version, but i guess 1.3 also works) has functionality for getting edid info by itself. It works for me if don't enter any monitor specific information in the Xorg.conf monitor section, so that it looks like this:

Section "Monitor"
    Identifier "Generic Monitor"
    Option "DPMS"
EndSection

 If it doesn't work, it may be that your monitor is sending data with an invalid DDC checksum, but otherwise correct. If it doesn't work, please send the output from the get-edid command (this is in the read-edid package) to xorg list and to this bug. get-edit > SM243T.edid, because we're trying to work out how to deal with bad checksum, but otherwise good edid info.

Nvidia driver & NV driver seem to read the edid just fine. Also on other distros things are fine...but when I run get-edid under Feisty I get this:

root@desktop:~# get-edid
get-edid: get-edid version 1.4.1

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
        Function supported
        Call successful

        VBE version 300
        VBE string at 0x11110 "NVIDIA"

VBE/DDC service about to be called
        Report DDC capabilities

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
        Function supported
        Call successful

        Monitor and video card combination does not support DDC1 transfers
        Monitor and video card combination supports DDC2 transfers
        0 seconds per 128 byte EDID block transfer
        Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
        Read EDID

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
        Function supported
        Call failed

The EDID data should not be trusted as the VBE call failed
EDID claims 255 more blocks left
EDID blocks left is wrong.
Your EDID is probably invalid.
��������������������������������������������������������������������������������

Yeah, the goal is that X can do this by itself, and I guess other
distros are using "get-edid|parse-edid" or something similar to make
this happen. Since your get-edid output is similar to the one I get on
my samsung syncmaster 900NF monitor, I guess that X discards your
monitors edid information too. Are you sure you don't have the monitor
section filled with data about the monitor when using the "nv" driver?
I guess that nvidia binary driver could have separate edid code, but I
doubt that "nv" has one.

I hope we'll have some code in Xorg server soon, so you'll be able to
test the fix.

On 6/9/07, Jerone Young <email address hidden> wrote:
> Nvidia driver & NV driver seem to read the edid just fine. Also on other
> distros things are fine...but when I run get-edid under Feisty I get
> this:
>
> root@desktop:~# get-edid
> get-edid: get-edid version 1.4.1
>
> Performing real mode VBE call
> Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
> Function supported
> Call successful
>
> VBE version 300
> VBE string at 0x11110 "NVIDIA"
>
> VBE/DDC service about to be called
> Report DDC capabilities
>
> Performing real mode VBE call
> Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
> Function supported
> Call successful
>
> Monitor and video card combination does not support DDC1 transfers
> Monitor and video card combination supports DDC2 transfers
> 0 seconds per 128 byte EDID block transfer
> Screen is not blanked during DDC transfer
>
> Reading next EDID block
>
> VBE/DDC service about to be called
> Read EDID
>
> Performing real mode VBE call
> Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
> Function supported
> Call failed
>
> The EDID data should not be trusted as the VBE call failed
> EDID claims 255 more blocks left
> EDID blocks left is wrong.
> Your EDID is probably invalid.
> ��������������������������������������������������������������������������������
>
> --
> Problems with xresprobe & Samsung 243T LCD
> https://bugs.launchpad.net/bugs/27667
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Actually that time I didn't :-O . But I just tried it commenting out the mode lines with the Nvidia (Proprietary) driver. Worked like a charm automatically come up at 1900x1200 . Acutally this is how Fedora Core does there X configurations. They list no mode lines for resolution and just read off the edid by default. I have done this with Fedora Core 6 in the past. I have my xorg.conf I'm using now attached.

Jerone, I've taken over the X maintainership from daniels. I am of the opinion that you are correct on this bug. Dropping the highest resolution was a bad design decision; the real problem here is that the code is using poor logic to tell the difference between an lcd and a crt, and as a result is dropping perfectly good resolutions far too often. In fact, while troubleshooting this issue, we noted 2-3 other logical errors in the CRT vs LCD code, that are probably producing weird resolution selection bugs in a number of other corner cases.

Furthermore, LCDs have grown to be much more common these days than when this design decision was made; as a consequence, the tradeoff this design took in favoring CRT niceties over LCD correctness has changed considerably. I believe that today getting things right with commonplace LCDs takes precedence over unusual CRT needs.

As well, with Gutsy we have better tools for letting users adjust resolutions. Psychologically, I think a user finding the install gave them too high of a resolution is going to simply think, "Whoa my hardware kicks ass, but I need to reign it in a bit..." whereas another user finding the install gave too low of a resolution would think, "Man, Ubuntu sucks, it can't even figure out my monitor's resolution properly." I think it's better to err to the former case than the latter, and just point them at the nice GUI tools we provide to fix up things post-install.

Besides which, as you pointed out, xresprobe is a low level tool, and it is inappropriate for it to be making the decisions about which resolutions to give the user. If this logic is in fact needed, it should be at a higher level - perhaps in the xserver postinst script, not here.

Therefore, I am dropping the CRT-specific logic, so LCDs and CRTs are treated identically, and xresprobe will return all available resolutions to the caller.

For upload:
http://people.ubuntu.com/~bryce/Uploads/xresprobe_0.4.24ubuntu5*

I absolutely agree. With the post-install giving too low a resolution it would def. give a bad impression of Ubuntu, esp. on an LCD where a lower resolution (ie non-native) tends to make fonts and such a much poorer readibility. I'm very happy w/ the work being done in Gutsy w/ the new GUI tool to change resolution and such. Fixing this issue would be the icing on the cake. ;)

xresprobe (0.4.24ubuntu5) gutsy; urgency=low

  * xorg.conf: Fix xprobe.sh failure caused by missing type1 module;
    this was dropped by Debian for xserver 1.3 since it's obsolete and
    has some security issues. (Addresses portion of fix for 127008)
  * xresprobe: Fix issue in alternate installation for Intel gfx laptops
    resulting in screen to be replaced by flashing colored blocks, by
    making xresprobe use ddcprobe instead of xprobe for laptops using
    the -intel driver. (Closes LP: #127008 and many, many duplicates)
  * ddcprobe.sh: Fix resolution detection error where LCD's would get
    configured to use one resolution less than their maximum because
    ddcprobe cannot tell the difference between an analog attached LCD
    and a CRT. (Closes LP: #27667)

 -- Bryce Harrington <email address hidden> Thu, 27 Sep 2007 17:57:22 -0700

ok something broke. When I try the daily live CD (9/28/07) with my Thinkpad T61 with intel x3100 graphics. It defaults to 1024x768 as opposed to 1400x900. Now interesting is when I run xresprobe as root I get the following output:
# xrespobe intel
id:
res: 1024x768
freq:
disptype: lcd/lvds

So but running ddcprobe. I can see that it sees the dtiming for 1400x900. Yet xresprobe is once again reporting things wrong. Xorg does a better job of detection then this thing. I say dump it and just let X detect it (though this is being a bit idealistic). Now I can go to the "screen resolution" change app and change it to 1400x900 , but things are listed in a weird order:

1024x768
1400x900
1280x800
800x600
640x480

And also in the xorg.conf .. 1024x768 is the only resolution.

Yes version xresprobe 0.4.24 is BROKEN. So the function "doprobe()" is totally .. utterly broken! It probably shouldn't even be used at all. I can't even figure out what the hack of script that is lcdsize.sh actually supposed to be doing correctly. Now replacing the call from "doprobe()" with "doddc()" ... surprise! ... works correctly and show all the correct resolutions for my Thinkpad T61 with intel x3100 card.

So you really do need another release. You need to remove all the logic from lines 139 to line 149 and just only run doddc() probe. Or just burn this POS out of existence ;-)

Oh forgot...while it's broken for my laptop .. it does not work correctly for the Samsung 243T LCD.

I see that the http://people.ubuntu.com/~bryce/Uploads/xresprobe_0.4.24ubuntu5.tar.gz has not maid it into the daily builds yet..I had assumed it was. I also see you have a specific line to have intel cards ddc probe. But really the behavior should be:

1) First try to ddcprobe
2) If you do not have a resolution from ddcprobe, then default to 800x600
    This is actually the behavior that windows follows. Then the user can change there settings later.

I like solution of Vedran Rodic very much. Juse use Xorg feature instead of out-of-date tools. Generate monitor settings in xorg.conf like this:

Section "Monitor"
 Identifier "minitor0"
 Option "DPMS"
EndSection

I suppose it'll cause problems only with very old screen devices. And these problems could be repaired directly in Xorg code, instead of hacking ubuntu-only tools.
I think it's worth considering.

On the under hand this change could lead to problems for a lots of users, especially if it's not used in any mainstream distribution.

My bug #118681 has just been marked a duplicate of this bug. That's fine of course - but I probably could have marked it myself if the description was clearer. I haven't changed it because I'm not 100% sure I understand it, but I think the description should be "xresprobe sets resolution to second highest supported on some LCDs". Could someone make the appropriate change? Thanks.

I have version 0.4.24ubuntu8 of xresprobe installed on my dual opteron (AMD64) gutsy system, and I'm still having this problem, or one just like it. I cannot get my 1600x1200 resolution display that I used to get on Feisty. I seem to be able to get no better than 1280x1024.

As you can see, xresprobe finds the 1600x1200 resolution:
[499] X11> sudo xresprobe ati
id: G201
res: 1600x1200 1280x1024 1024x768 832x624 800x600 720x400 640x480
freq: 30-95 50-76
disptype:
[500] X11>

I've attached my Xorg.0.log from a run with an empty xorg.conf file.

Running Hardy Alpha 5 with latest updates.
I am still seeing this bug or so I think...
Here is my setup : A laptop in its dock with an external monitor plugged on the DVI port of the dock. The "native" resolution of my monitor is 1280x1024@60hz
But in fact, I only get 1152x864@75Hz (I can change it using the Gnome RANDR applet for example).
Here is the output of xresprobe :
$ sudo xresprobe intel
id:
res: 1280x800
freq:
disptype: lcd/lvds

xresprobe doesn't seem to see the DVI monitor.

Here is the output of ddcprobe (seems fine) :
$ sudo ddcprobe
vbe: VESA 3.0 detected.
oem: Intel(r)GM965/PM965/GL960 Graphics Chip Accelerated VGA BIOS
vendor: Intel Corporation
product: Intel(r)GM965/PM965/GL960 Graphics Controller Hardware Version 0.0
memory: 7616kb
mode: 1280x1024x256
mode: 1280x1024x64k
mode: 1280x1024x16m
mode: 1024x768x256
mode: 1024x768x64k
mode: 1024x768x16m
mode: 640x480x16m
mode: 800x600x64k
mode: 800x600x16m
mode: 640x480x256
mode: 800x600x256
mode: 640x480x64k
edid:
edid: 1 3
id: 3514
eisa: AUO3514
serial: 00000000
manufacture: 1 2007
input: analog signal.
screensize: 26 16
gamma: 2.200000
dpms: RGB, no active off, no suspend, no standby
dtiming: 1280x800@59
monitorid: AUO
monitorid: B121EW03 V5

Here is my xorg.conf :
$ cat /etc/X11/xorg.conf
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "fr"
 Option "XkbVariant" "oss"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
EndSection

Section "Device"
 Identifier "Configured Video Device"
EndSection

Section "Monitor"
 Identifier "Configured Monitor"
EndSection

Section "Screen"
 Identifier "Default Screen"
 Monitor "Configured Monitor"
 Device "Configured Video Device"
EndSection

Here is the ouput of xrandr -q :
$ xrandr -q
Screen 0: minimum 320 x 200, current 1280 x 864, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
   1280x800 60.0*+ 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TMDS-1 connected 1152x864+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024 60.0 + 75.0 59.9
   1152x864 74.8*
   1024x768 75.1 71.9 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 75.0 72.8 66.7 60.0
   720x400 70.1
TV connected (normal left ...

Your not seeing this bug because xresprobe is no longer used in Hardy. This is why your xorg.conf does not have any specific resolutions listed .. now X does autodetection. The xrandr output is correct.. what is probably stupid is the gui tool you are using. Try logging out and restarting Xorg with your monitor connected should go to the max res. Or use "xrandr --output TMDS-1 --auto" from the command line and that will set it to it's native resolution.. xrandr show that is supports it .. so the problem you are seeing is with the dumb gui tool.

Jerone : Thanks for your help.
The command "xrandr --output TMDS-1 --auto" works but I am not really sure the problem lies in a gui tool, not even a dumb one ;-)
Indeed, if I reboot with the same monitor plugged on the VGA port instead of the DVI one, the resolution is fine. Maybe it is related to the fact that the DVI is not a primary port: BIOS messages, Grub messages and usplash graphics are not displayed on the monitor when plugged into the DVI port. Acer support (my laptop is an Acer TM6292) told me that there is no BIOS settings to change that and that it will never work.
I will keep on testing :-)

I am not sure if I am in the left field here on relevance to original post but I have an issue with Hardy Beta(8.04), using Kubuntu Beta CD, I see that for graphics card ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE], and Hanns-G JW199D LCD monitor I get display shifted to right. I have not done any resolution changes or any other investigation.

Using 7.04 It works ok using 1024x768 @60 Hz chosen automagically. I did have issues with DVI cable using 7.04 such that all the boot messages were blank. Now I am using VGA cable and I believe I got rid of boot splash and quiet and hence due to multiple tinkerings I have a basically functional set up. Which is not achieved with Hardy Beta out of box, boot up messages are ok. But not once desktop manager takes over, I think Hardy beta must be using all the latest packages, hence this report. If need to look up something please let me know.

Thanks,

Jay

@Jay
     This is not the same issue. So if you are getting the correct resolution then you are fine from that stand point. Now shifting to the right is odd.

 If you using VGA and it is shifted to the right then try auto calibrating your monitor.

If that does not help then this could be an issue with the Xorg radeon driver, do you see the same behavior when you try it with DVI?

Sorry if this is the wrong place. I am posting here about Bug #23408 (the duplicate of this Bug #27667) because I also have a Sony SDM-M51 that was detected as 'Unknown' monitor... and only allowed 800x600 at first.

Eventually it started working.

I have an eeepc 701 4g laptop that it is plugged into, running Ubuntu 9.04, with 1024x768 on the sony and 640x400 on the laptop.

I am not sure exactly how I got it to work, but i think rebooting was the key. I had tried dpkg-reconfigure xserver-xorg , ddcprobe, randr, xresprobe, and even I shut down X and did Xorg -config from textmode (but threw away the resulting config file and did not use it since it had nothing about monitors in it). I didn't really change anything with those programs. Again I think maybe all I had to do was reboot.

Here is /etc/X11/xorg.conf

Section "Monitor"
 Identifier "Configured Monitor"
EndSection

Section "Screen"
 Identifier "Default Screen"
 Monitor "Configured Monitor"
 Device "Configured Video Device"
 SubSection "Display"
  Virtual 1744 768
 EndSubSection
EndSection

Section "Device"
 Identifier "Configured Video Device"
EndSection

Attached is Xorg.0.log

As far as xrandr goes.. it is funny. Before my reboot, xrandr just showed 800x600 and 640x480 for the Sony monitor. But now, it shows:

VGA connected 1024x768+0+0 (normal left inverted right x axis y axis) 311mm x 234mm
   1360x768 59.8
   1024x768 60.0*
   800x600 60.3
   640x480 59.9
LVDS connected 640x400+1024+0 (normal left inverted right x axis y axis) 0mm x 0mm
   800x480 60.0 +
   640x480 85.0 72.8 75.0 59.9
   720x400 85.0
   640x400 85.1*
   640x350 85.1

Thank you very much and I hope this helps somebody.