Re: config X under woody -- SOLVED... and yet...
i'm still trying to get enough pixels displayed on my monitor so
that if i decide to start up mozilla, i can see the entire
window. :) 1024x768 doesn't seem to be in the X-app designer's
lexicon! (and i *know* i had more pixels in X when i was running
potato.)
alas...
On Sat, Dec 14, 2002 at 04:23:25PM +1100, Rob Weir wrote:
> On Thu, Dec 12, 2002 at 02:44:59PM +0000, Pigeon wrote:
> > It would be useful to pure Linux users - possibly including the OP -
> > if there was some Linux tool that did this, so xf86config et al. could
> > say "Your monitor appears to be an ADI MS-5P+, accept/change" or
> > something like that, combined of course with a file listing many
> > different monitors' capabilities.
>
> Install 'discover', 'mdetect' and 'read-edid' before X and debconf will
> be able to autodetct most things for your X config. This is noted in
> both the xserver-xfree86 Suggests:, and the install documentation.
OP here... i tried "get-edid" from the "read-edid" package and
this shows up on screen*:
>>>>>
# 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 200
VBE string at 0xc7659 "Matrox Graphics Inc."
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 does not support 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.
<<<<<
*i say "on screen" because i saw it flash by briefly before my
screen went whole-hog dead -- i can run it from a remote ssh
session and i can see (and cut and paste) the whole thing.
(this is generated on stderr, of course); i try piping get- into
parse- like so
# get-edid | parse-edid > edid.out
and it yields very suspicious stuff:
>>>>>
# EDID version 255 revision 255
Section "Monitor"
Identifier "___:ffff"
VendorName "___"
ModelName "___:ffff"
# DPMS capabilities: Active off:yes Suspend:yes Standby:yes
Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz
DotClock 655.350000
HTimings 4095 4350 4605 8190
VTimings 4095 4158 4221 8190
Flags "Interlace" "+HSync" "+VSync"
EndMode
Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz
DotClock 655.350000
HTimings 4095 4350 4605 8190
VTimings 4095 4158 4221 8190
Flags "Interlace" "+HSync" "+VSync"
EndMode
Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz
DotClock 655.350000
HTimings 4095 4350 4605 8190
VTimings 4095 4158 4221 8190
Flags "Interlace" "+HSync" "+VSync"
EndMode
Mode "4095x4095" # vfreq 9.770Hz, hfreq 80.018kHz
DotClock 655.350000
HTimings 4095 4350 4605 8190
VTimings 4095 4158 4221 8190
Flags "Interlace" "+HSync" "+VSync"
EndMode
EndSection
<<<<<
this most aggravating thing is that IT BORKS MY SYSTEM,
including locking up the monitor (all x displays gone, sometimes
i get a blinking text/console cursor at top left, sometimes not)
and my keyboard (typing "reset" or "ctl-alt-backspace" or
"ctl-alt-del" do nothing)... i can generate new ssh sessions and
do an orderly shutdown, but killing various processes (such as
X) do no good. reboot seemed the only salve to put on the wound.
much frown, here.
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 7
model name : AMD-K6tm w/ multimedia extensions
stepping : 0
cpu MHz : 267.276
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 10 mmx
bogomips : 532.48
any ideas how i can probe my hardware without killing may
hardware? (the aforementioned 'mdetect' is for mice, and i've
got no troubles there; also 'discover' as mentioned above
makes no sense to me -- i need to know in advance which device
to have it scan, and i'm not much of a hardware guy...)
--
I use Debian/GNU Linux version 3.0;
Linux server 2.2.17 #1 Sun Jun 25 09:24:41 EST 2000 i586 unknown
DEBIAN NEWBIE TIP #127 from Sam Varghese <sam@gnubies.com>
:
Curious about the ONLINE BOOK "LEARNING DEBIAN/GNU LINUX"?
Here you go:
http://www.oreilly.com/catalog/debian/chapter/
Also see http://newbieDoc.sourceForge.net/ ...
Reply to: