And it's really ridiculous how--Those steps should really have been part of the installation phase of the xorg packages.
(I did try to install Gentoo, but I bit off more than I could chew by jumping straight into a minimal CD with the intent of building the whole OS from the get-go. Not a good idea; While I'm sure their walkthrough documentation is pretty good, it's not very readable under Links, and having to use screen locally because virtual terminals were disabled was annoying, to say the least.)
The fix for Ubuntu? I ran
and
a couple times, hoping in vain it might offer me some configuration options. When they didn't, I started looking for read-edid and a modeline builder. When I couldn't find them quickly and without Internet access, I shut down the system and put it off for a bit. The next time I booted it up, it booted straight into my monitor's native resolution. Apparently, dpkg-reconfigure has a read-edid step in it that was forgotten during the upgrade process.
My approach harkens back to the days on Debian when X didn't autodetect your screen's vertical and horizontal refresh rates and build modelines accordingly--I think the last version of XFree86 that behaved that way was 3.3.6. So if you knew the model of your monitor, there were websites out on the Internet that might have the vertical and horizontal refresh rates for your CRT.
If you didn't know the physical limits of your CRT, you could guess at different settings--and risk destroying your hardware--or you could try to read your monitor's EDID block. The EDID block is a chunk of data you could get back from your monitor along your video cable (and this was before the days of HDMI, where two-way communications along your video cable are assumed) if you sent the right DDC commands. DDC is a wire protocol related to I2C. If you want to know what those are, google them. In monitors that support EDID properly, the EDID block contains all the information that a computer needs to figure out the resolutions and refresh rates the monitor supports. Back in the early days of EDID, laptop displays rarely supported it correctly, but that hasn't been a common problem in over ten years; Modularization has led to broader support for hardware standards even within laptops. (I can't vouch for netbooks, though; The drive to reduce cost and size even further has resulted in more custom and SOC-type silicon, and the first thing that gets dropped from custom silicon is unnecessary features.)
I figured that Ubuntu wasn't checking the EDID block, or it would have had a decent idea what my display was capable of. Turned out, I was only half-right; Ubuntu had all the logic in there to check it, but it wasn't being called at the right point during the upgrade process.
Still considering switching to a different distribution, but it's not as urgent an interest at this point.
(I did try to install Gentoo, but I bit off more than I could chew by jumping straight into a minimal CD with the intent of building the whole OS from the get-go. Not a good idea; While I'm sure their walkthrough documentation is pretty good, it's not very readable under Links, and having to use screen locally because virtual terminals were disabled was annoying, to say the least.)
The fix for Ubuntu? I ran
dexconf
and
dpkg-reconfigure xserver-xorg
a couple times, hoping in vain it might offer me some configuration options. When they didn't, I started looking for read-edid and a modeline builder. When I couldn't find them quickly and without Internet access, I shut down the system and put it off for a bit. The next time I booted it up, it booted straight into my monitor's native resolution. Apparently, dpkg-reconfigure has a read-edid step in it that was forgotten during the upgrade process.
My approach harkens back to the days on Debian when X didn't autodetect your screen's vertical and horizontal refresh rates and build modelines accordingly--I think the last version of XFree86 that behaved that way was 3.3.6. So if you knew the model of your monitor, there were websites out on the Internet that might have the vertical and horizontal refresh rates for your CRT.
If you didn't know the physical limits of your CRT, you could guess at different settings--and risk destroying your hardware--or you could try to read your monitor's EDID block. The EDID block is a chunk of data you could get back from your monitor along your video cable (and this was before the days of HDMI, where two-way communications along your video cable are assumed) if you sent the right DDC commands. DDC is a wire protocol related to I2C. If you want to know what those are, google them. In monitors that support EDID properly, the EDID block contains all the information that a computer needs to figure out the resolutions and refresh rates the monitor supports. Back in the early days of EDID, laptop displays rarely supported it correctly, but that hasn't been a common problem in over ten years; Modularization has led to broader support for hardware standards even within laptops. (I can't vouch for netbooks, though; The drive to reduce cost and size even further has resulted in more custom and SOC-type silicon, and the first thing that gets dropped from custom silicon is unnecessary features.)
I figured that Ubuntu wasn't checking the EDID block, or it would have had a decent idea what my display was capable of. Turned out, I was only half-right; Ubuntu had all the logic in there to check it, but it wasn't being called at the right point during the upgrade process.
Still considering switching to a different distribution, but it's not as urgent an interest at this point.
No comments:
Post a Comment