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

[James S. <jsi...@tr...>]

> 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.

As pointed out their should exist a supset that EDID is apart of. I don't
want to run into a issues of some platform using something else that works
just as well. I like to think functionality. This kind of thinking will go
further.

> 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.

The reality is if you write the drivers correctly you can have drivers that 
do the timing for you. Yes you would have to supply the data for the 
monitor attached before. Their exist receipes for this.

> 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?

Don't shot me. Linus has pointed out that ioctls are to go away in 2.5.X.

> > 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.

Wrong. You create another console driver. Take a look at the STI console
code for the PARISC platform. A excellent example. Core code which has a
fbdev driver on top for graphcis modes and a sticon for using a text
mode from the ROM. Using fbdev for text modes is way to much overhead.
Using struct consw only is much lighter in weight. The aim here is to
remove bloat. Plus the console code will be removed from all low level
drivers period. The embedded industry demands it. I know since I work in
it. In the console project we have NVIDIA text console driver. For matrox
you could have a matroxcon. Very simple and very sweet.

> 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).

The struct xxx_par represents the hardware state. This encompesses the
entire board. So you would place everthing in there. struct fb_info
represents one framebuffer and its properties. Thats all. Very simple and
very clean.