dear m and friends,
just for fun, i tried the rc on an older pc without the need for wireless card.
grml-x issue - no screen found
now, if I copy the xorg.conf that I always use for that machine, then issue grml-x fluxbox, it is gorgeous, screen, colous, resolution.
I am attaching the corresponding files, the ln one and grml one, but the most interesting thing is that get-edid | parse-edid provides the correct information, matching exactly the one in my own file, to wit:
Section "Monitor" VendorName "Dell" ModelName "Dell M781p" Identifier "Dell M781p" HorizSync 30-85 VertRefresh 50-160 Option "DPMS" EndSection
whilst, in spite of edid being correct, in se et sine alium, the grml generated file remains:
Section "Monitor" Identifier "Monitor0" # ModelName "Old Monitor (no DDC)" Option "DPMS" "true" # HorizSync 28.0 - 78.0 # Warning: This may fry very old Monitors # HorizSync 28.0 - 96.0 # Warning: This may fry old Monitors HorizSync 30.0 - 85.0 30.0 - 85.0 30.0 - 85.0 30.0 - 85.0 # VertRefresh 50.0 - 76.0 # Very conservative. May flicker. # VertRefresh 50.0 - 60.0 # Extreme conservative. Will flicker. TFT default. VertRefresh 50.0 - 160.0 50.0 - 160.0 50.0 - 160.0 50.0 - 160.0 # Need more information? # http://xtiming.sourceforge.net/cgi-bin/xtiming.pl # http://en.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/ EndSection
I hope it is my own inability to figure out what is wrong, but whether I use -module vesa or -module radeon, or no options, there is something wrong.
Sorry to bother you all, but hope this may be of interest.
Best,
martin
On Thu, Aug 03, 2006 at 01:33:01PM -0400, Martin Yazdzik wrote:
# ModelName "Old Monitor (no DDC)"
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. ;-)
cheers, Wernfried
On Thursday 03 August 2006 15:14, Wernfried Haas wrote:
On Thu, Aug 03, 2006 at 01:33:01PM -0400, Martin Yazdzik wrote:
# ModelName "Old Monitor (no DDC)"
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. ;-)
cheers, Wernfried
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.
Best, M
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.
On Thu, Aug 03, 2006 at 10:32:43PM -0400, Martin Yazdzik wrote:
But, of course, it does - that is why I am perplexed.
Oh, whoops. Never mind my comment then ;-)
cheers, Wernfried
* Martin Yazdzik yazdzik@nyct.net [20060804 05:15]:
On Thursday 03 August 2006 15:14, Wernfried Haas wrote:
On Thu, Aug 03, 2006 at 01:33:01PM -0400, Martin Yazdzik wrote:
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.
regards, -mika-
On Fri, 04 Aug 2006 11:02:36 +0200, Michael Prokop wrote:
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:
----------------------------- VBE version 200 VBE string at 0x11110 "ATI RADEON 9200"
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
Section "Monitor" # Block type: 2:0 3:fd # Block type: 2:0 3:fc Identifier "SyncMaster" VendorName "SAM" ModelName "SyncMaster" # Block type: 2:0 3:fd HorizSync 30-71 VertRefresh 50-160 # Max dot clock (video bandwidth) 110 MHz # Block type: 2:0 3:fc # Block type: 2:0 3:ff # DPMS capabilities: Active off:yes Suspend:no Standby:no
Mode "1024x768" # vfreq 84.997Hz, hfreq 68.677kHz DotClock 94.500000 HTimings 1024 1072 1168 1376 VTimings 768 769 772 808 Flags "+HSync" "+VSync" EndMode # Block type: 2:0 3:fd # Block type: 2:0 3:fc # Block type: 2:0 3:ff EndSection -----------------------------
T
* T mlist4suntong@yahoo.com [20060805 17:15]:
On Fri, 04 Aug 2006 11:02:36 +0200, Michael Prokop wrote:
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].
Yes, I will consider 'get-edid | parse-edid' for inclusion in the rewrite of grml-x.
FYI, what is automatically detected from my system:
[...]
Thanks.
regards, -mika-
Hi, * Martin Yazdzik yazdzik@nyct.net [2006-08-03 23:08]: [...]
whilst, in spite of edid being correct, in se et sine alium, the grml generated file remains:
Section "Monitor" Identifier "Monitor0" # ModelName "Old Monitor (no DDC)" Option "DPMS" "true" # HorizSync 28.0 - 78.0 # Warning: This may fry very old Monitors # HorizSync 28.0 - 96.0 # Warning: This may fry old Monitors HorizSync 30.0 - 85.0 30.0 - 85.0 30.0 - 85.0 30.0 - 85.0 # VertRefresh 50.0 - 76.0 # Very conservative. May flicker. # VertRefresh 50.0 - 60.0 # Extreme conservative. Will flicker. TFT default.
[...] I also have this bug with rc1, reported to mika. regards Nico
* Martin Yazdzik yazdzik@nyct.net [20060803 20:15]:
grml-x issue - no screen found
Ok.
now, if I copy the xorg.conf that I always use for that machine, then issue grml-x fluxbox, it is gorgeous, screen, colous, resolution.
Ok.
I am attaching the corresponding files, the ln one and grml one, but the most interesting thing is that get-edid | parse-edid provides the correct information, matching exactly the one in my own file, to wit:
Section "Monitor" VendorName "Dell" ModelName "Dell M781p" Identifier "Dell M781p" HorizSync 30-85 VertRefresh 50-160 Option "DPMS" EndSection
Ok.
whilst, in spite of edid being correct, in se et sine alium, the grml generated file remains:
[...]
Section "Monitor" Identifier "Monitor0" # ModelName "Old Monitor (no DDC)" Option "DPMS" "true" # HorizSync 28.0 - 78.0 # Warning: This may fry very old Monitors # HorizSync 28.0 - 96.0 # Warning: This may fry old Monitors HorizSync 30.0 - 85.0 30.0 - 85.0 30.0 - 85.0 30.0 - 85.0
=> there's something going wrong here.
# VertRefresh 50.0 - 76.0 # Very conservative. May flicker. # VertRefresh 50.0 - 60.0 # Extreme conservative. Will flicker. TFT default. VertRefresh 50.0 - 160.0 50.0 - 160.0 50.0 - 160.0 50.0 - 160.0
=> and here too. The 3 additional lines are definitely not ok, but I'm not yet sure where they might come from. :-/
How are you running grml-x? (I mean the commandline switches to grml-x.)
Does running:
% grml-x -hsync 30-85 -vsync 50-160 -mode 1024x768 $WINDOW_MANAGER
help?
I hope it is my own inability to figure out what is wrong, but whether I use -module vesa or -module radeon, or no options, there is something wrong.
Can you please provide me the output of 'get-edid | parse-edid' too?
Sorry to bother you all, but hope this may be of interest.
It definitely helps debugging a problem I wasn't aware of. :)
regards, -mika-
* Martin Yazdzik yazdzik@nyct.net [20060803 20:15]:
just for fun, i tried the rc on an older pc without the need for wireless card.
grml-x issue - no screen found
[...]
HorizSync 30.0 - 85.030.0 - 85.0 30.0 - 85.0 30.0 - 85.0
Thanks to Nico for helping investigate the problem. He had the same problem on his box too. grml-x (0.3-11) should fix the problem now.
regards, -mika-
Teilnehmer (5)
-
Martin Yazdzik -
Michael Prokop -
Nico Golde -
T -
Wernfried Haas