On Tue, Jan 08, 2008, [EMAIL PROTECTED] wrote:
> Is there a command that tells you the dimensions of your monitor in pixels.
Yes. Sometimes. :)
> I've asked around and received some extraordinary responses, including
>
> 1. Of course not, what a fatuous question.
> 2. Dunno, the dimensions are a function of the refresh rate.
> 3. Dunno, but it can't be a constant, because I read somewhere that the
> pixels can be stretched.
Wow. ok, 1 is a stupid answer; 2 is somewhat true. 3 is almost true,
but its more due to how CRTs work and how LCDs pretend. :)
> This last one threw me, but I think it meant that a single pixel can be
> replaced by, say, four of the same character (= stretched).
>
> Can anyone give me an answer?
Sure. Background time.
LCDs? There are discrete pixels, which are then broken up into RGB elements.
You don't get "more" or "less" pixels; although some monitors do something
called interpolation which is a fancy way of taking resolution X and
mapping it onto a larger resolution Y, "figuring out" what the colour/intensity
of the pixels in between should be. Google for it, there's probably better
descriptions out there.
In short with LCDs: don't rely on interpolation to give you -any- great colour
images; its just there for the times where the graphics resolution != the native
LCD resolution (eg, when the BIOS is starting up the computer.)
Now, there's a funny way that graphics cards interface with some monitors and
can "ask politely" for information. I think its called "DDC".
CRTs? CRTs, especially monochrome ones, don't have a specific resolution per se.
Its just an electron beam scanning over the phosophorus in the front of the
monitor,
and that phosphorus is what displays the picture.
The resolution depends on a few things:
* there's generally a granularity to the phosphorous, so if you make the beam
too narrow
you end up with "bleeding" between pixels;
* there's generally some kind of metallic mask sitting there somewhere, which
limits
the resolution in one or the other direction; and
* colour monitors (which I guess you're thinking about!) do have discrete
pixels at least
in one direction (horizontally or vertically); again, google for how colour
CRTs work
to get an idea.
* And finally, yes, the refresh rate does affect the CRT resolution.
Next - refresh rate. Its a fun one. refresh rate affects CRTs by just
overtaxing what
the electronics and the tube itself can do. Refresh rates can limit LCD
resolutions
by trying to push too much data over DVI. DVI has a fixed upper speed and
doesn't
fail gracefully like VGA (read: blurring and artifacts.) This is why you need
>1 DVI
connector to drive those enormous apple monitors - because one DVI connector
couldn't
support the data rate needed to drive that resolution at the refresh rate.
Ok, so enough of the background. There's this funny protocol called DDC. Its a
plug and play type protocol, which generally means "pray that everything
supports
it right." It lets a VESA-compatible VGA card probe the monitor for its
capabilities.
Under Ubuntu there's a package called read-edid. It installs 'get-edid' and
'parse-edid'.
Here's what it shows for my setup, a dual-head radeon card with a VGA and DVI
LCDs.
One monitor didn't report anything, one monitor reported its info. The monitors
are
recentish, and this PnP protocol has been around since mid last century iirc, so
its probably a quirk somewhere..
[EMAIL PROTECTED]:/var# get-edid | parse-edid
parse-edid: parse-edid version 1.4.1
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 0x11110 "ATI RADEON 9200"
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 successful
parse-edid: EDID checksum passed.
# EDID version 1 revision 3
Section "Monitor"
# Block type: 2:0 3:fd
# Block type: 2:0 3:fc
Identifier "L1910S "
VendorName "GSM"
ModelName "L1910S "
# Block type: 2:0 3:fd
HorizSync 30-83
VertRefresh 56-75
# Max dot clock (video bandwidth) 140 MHz
# Block type: 2:0 3:fc
# Block type: 2:0 3:fc
# DPMS capabilities: Active off:yes Suspend:yes Standby:yes
Mode "1280x1024" # vfreq 60.020Hz, hfreq 63.981kHz
DotClock 108.000000
HTimings 1280 1328 1440 1688
VTimings 1024 1025 1028 1066
Flags "+HSync" "+VSync"
EndMode
# Block type: 2:0 3:fd
# Block type: 2:0 3:fc
# Block type: 2:0 3:fc
EndSection
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
