Re: [Linux-fbdev-devel] re: James's new API post

[Paul M. <le...@Ch...>]

On Sun, Nov 25, 2001 at 02:34:33AM +0100, Petr Vandrovec wrote:
> Are you sure that this is really needed? You are not inventing API for ne=
xt
> 20 years. You are inventing API now, for current products. You can change
> API anytime in future, and API will definitely change, as it already
> changed in the past. Also EDID is so universal that you can express
> almost everything using that, and also do not forget that there exist
> bidirectional channel (DDC2B+/DDC2AB) between videocard and monitor, and
> that this bidirectional communication may be required for proper operation
> (i.e. enabling) of USB/IEEE1394 ports built into monitor.
>  =20
VBE DDC is something else to consider as well..

> > /dev/gfx/card0/frame0/resolution
> > 	             /endian
> > 	             /frame
> > 			=09
> > To change the resolution of a framebuffer we can do a=20
> >=20
> > cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution.       =20
> >=20
> > As you can see with this new design we have alot more flexiablity. Lots=
 of
> > other nice features but this is down the road.
>=20
> Yes. For example floating point support in the kernel. I'd like to know=
=20
> how you'll persuade driver to know that '640x480-YUV422@59.94i' should be=
=20
> NTSC 800x525 interlaced picture, and how you'll center picture on screen
> then? Where do you specify virtual xres and yres?
> =20
Your overthinking it. For one, as long as modes are in a consistent format,
it's easy for anyone to parse. And since people are already used to the
"640x480-16@70" style format, what's the big deal?

As far as virtual xres and yres.. keep in mind this is a virtual filesystem=
..
if your driver or subsystem has additional needs, you can simply register a
new entry to deal with virtual resolution.. If you want a place for virtual
resolution.. something like:

	/dev/gfx/card0/frame0/resolution_virt

should suffice just fine. (Name pending).

Regards,

--=20
Paul Mundt <le...@ch...>