Subject: Re: struct videomode
To: Garrett D'Amore <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 03/04/2006 01:37:50
Content-Type: text/plain; charset=US-ASCII
> In order to implement a framebuffer driver for Radeon boards, I need a
> reasonable database of video timings. (Yes, I know I could use EDID
> and DDC, but I'm not that far yet. And not all monitors support
> these. And some folks might want to use a resolution other than what
> the monitor advertises.)
Agreed, but it should be possible to add (optional) EDID support later
on in case the monitor in question does support it - like marking the
preferred mode if the monitor defines one, probably shrink or extend the
list based on monitor capabilities and so on. Some monitors may have odd
properties that may be reported via EDID ( like some iMacs which have
built-in CRTs with a fixed 60kHz line frequency )
I have some experimental code to attach
iic* at ffb?
monitor* at iic? addr 0x80
which currently only reads the first EDID data block and then dumps some
values, maybe there should be a real userland interface for that.
So, I think we should be able to use EDID information if it's available
at some point, but not depend on it.
> Anyway, in dev/ic/ there is videomode.h, which has the structure I
> need to use.
> There are two questions here. First, anyone object to me moving this
> to dev/ic/videomode/ and placing a .c file here with a reasonable
> database (an array of struct videomode)? (Actually, the .c will be
> generated by an awk script, from a file containing a bunch of XFree86
> Modeline definitions -- such as
> xsrc/xc/programs/Xserver/hw/xfree86/etc/vesamodes.) Both the source
> file(s) and the awk script will also be in that new directory.
> Second, struct videomode has a void* member called misc_data. I want
> to replace this with a const char *, which will be a "name" for the
> mode in the form "XxYxR" where X =3D x resolution, Y =3D y resolution, and
> R =3D vertical refresh rate. So you get a string like "800x600x60" or
No objections from me, a list of canonical modes should be useful.
While here we should probably define a standard interface to tell the
console driver which video mode to use - sparc(64) and macppc so far use
whatever the firmware sets up which may be less than optimal ( like old
Apple OF that always comes up in 640x480 without a way to change that )
or on machines that don't usually come up with a graphical console.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
-----END PGP SIGNATURE-----