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

[Petr V. <van...@vc...>]

On Sat, Nov 24, 2001 at 08:52:09AM -0800, James Simmons wrote:
> >     something special that I can support. To aid in code reuse you
> >     should just provide a function that parses EDID data into an
> >     edid data structure (Something like this was discussed a few
> >     day ago)
> 
> Most defintely. That was what fbmon.c was for. Unfortunely I never had the
> time to work on it. Now that 2.5.0 is out I'm going to figure something
> out. I did see the patch sent out and I'm going to start with that. I just
> like to make monitor stuff EDID independent. I don't want to be stuck with
> this api for the next 20 years especially when the technology will change.

Are you sure that this is really needed? You are not inventing API for next
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.
  
> >   * The user api needs to move away from timings all together.
> >     The user should be able to select a refresh rate from a provided
> >     list (negotiated between monitor and driver). It won't be long
> >     before timings are no longer used in hardware, and the only thing
> >     left to adjust will be refresh.

And our monitors will do plop and disappear? We are using 12 years old 
monitors for some tasks, and we'll not throw them away before they'll 
physically stop functioning.

> /dev/gfx/card0/frame0/resolution
> 	             /endian
> 	             /frame
> 				
> To change the resolution of a framebuffer we can do a 
> 
> cat "640x480-16@70" > /dev/gfx/card0/frame0/resolution.        
> 
> As you can see with this new design we have alot more flexiablity. Lots of
> other nice features but this is down the road.

Yes. For example floating point support in the kernel. I'd like to know 
how you'll persuade driver to know that '640x480-YUV422@59.94i' should be 
NTSC 800x525 interlaced picture, and how you'll center picture on screen
then? Where do you specify virtual xres and yres?
 
> >       graphics driver and isn't appealing as a base driver to expand
> >       on.
> 
> Agree. This will change. Plus the gfx interface I mention above wil be my
> attempt to combine DRI and fbdev. 

There are drivers which support text modes - and if your new API will not
support them... well, you'll have to create another API.
 
> > #3 Don't try to wrap everything in a hardware independent API. Some
> >    hardware is going to support things that others don't. Take for
> >    instance "mirroring". The i810 can do this on the CRT + a TV or
> >    FP depending on what is connected. But the modes that can be
> >    supported are very limited and mucking up a mode API with this
> 
> This is what struct fb_info.par is for. It is the hardware dependent
> structure in struct fb_info. If you have more than one frmaebuffer on the
> graphics card then you have 2 struct fb_info that share the same par. Now
> if one attempts to set the graphics mode that both can't support at the
> same time since they share the same par they will know before hand. That
> is what fb_check_var is for. 

It is something else. You can have two CRTCs (== two /dev/fb*), four
outputs (analog VGA #1, analog VGA #2, digital FP #1 and TVOut #1) of
which 2 or 3 can be active at one time, and a scaler which can insert
third picture into one of outputs... API should at least provide
universal way for enumerating device outputs and finding dependencies
between /dev/fb* (i.e. /dev/fb0 shares memory with /dev/fb1, and
/dev/fb2 shares memory and outputs with /dev/fb3).
						Best regards,
							Petr Vandrovec
							van...@vc...