Newsgroups:  gmane.linux.distributions.grml.user
Date:        Fri, 4 Aug 2006 11:02:36 +0200

> > As far i understand the issue, your hardware doesn't support DDC,
> > which is used to find out which sync rates your monitor uses. As a
> > consequence X tries to guess some common frequencies, and obviously
> > took the wrong ones. ;-)

> But, of course, it does - that is why I am perplexed.

> edid recognises it immediately - there are almost no monitors in current
> use that do not support ddc, and the dell certainly does.

> Somewhere, some information is failing to go somewhere.

> So the question is why, when edid knows what the monitor is, and every
> other distro I try certainly does, where the script is not pulling down
> the id.

Well, grml-x currently does not use "get-edid | parse-edid" but uses just hwinfo and the mechanisms of X-server itself.

The main problem is: who can you trust? To give you an example how unreliable all the X-server stuff is take a look at my box:

# get-edid | parse-edid
[...]
The EDID data should not be trusted as the VBE call failed Error: output
block unchanged
parse-edid: IO error reading EDID

=> nothing I could use. So next step:

# hwinfo --monitor
30: None 00.0: 10000 Monitor
  [Created at fb.70]
  Unique ID: rdCR.EY_qmtb9YY0
  Hardware Class: monitor
  Model: "Generic Monitor"
  Vendor: "Generic"
  Device: "Monitor"
  Resolution: 1024x768@76Hz
  Driver Info #0:
    Max. Resolution: 1024x768
    Vert. Sync Range: 50-90 Hz
    Hor. Sync Range: 31-61 kHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

=> well, lying as well. See what I'm really using and what my laptop
   supports:

% xdpyinfo | grep dim
  dimensions:    1400x1050 pixels (356x267 millimeters)

So: I can't trust BIOS, nor edid, nor hwinfo. X guesses the possibilites at its best on my box (providing some basic information of course). But that's just one box out of several thousand different types of hardware combinations. And therefore grml-x does work better on some boxes than other X-configuration tools and sometimes not. The module causing most problems and headache is BTW radeon. And often it helps running something like "xrandr -s '1024x768'" as soon as X has been started (bound to ctrl-alt-d in fluxbox on grml BTW).

BTW: I'm planning to rewrite grml-x when grml 0.8 is out. All options should stay the same, but in the background I'll try to improve certain stuff. Especially because I'd like to provide (basic) dualhead-support with the new grml-x version.

-mika-

> > Well, grml-x currently does not use "get-edid | parse-edid" but uses
> > just hwinfo and the mechanisms of X-server itself.

> > The main problem is: who can you trust? To give you an example how
> > unreliable all the X-server stuff is take a look at my box:

> > # get-edid | parse-edid
> > [...]
> > The EDID data should not be trusted as the VBE call failed Error:
> > output block unchanged
> > parse-edid: IO error reading EDID

> May I suggest that if "get-edid | parse-edid" can return valid results,
> use it as the first choice? I just run it and found that it is much
> meaningful them my current xorg.conf result, which uses screen[0] and
> device[0].

 > FYI, what is automatically detected from my system:
[...]