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

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

> #1 Monitor timings/ mode setting is quite poor in 2.4.x. I haven't
> looked at what you have so far but here are some points that
> should be considered.
>   * Monitor timings are something that should be determined between
>     the driver and the monitor. Users and higher level api's should
>     not have anything to do with this. The driver I am working on
>     now has a fixed set of timings that it supports. When set_var
>     requests a new mode the closest match is found. It is key to
>     let the driver have it's own mode table.  I also will eventually
>     parse EDID to add modes to my tables is the monitor needs
>     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.
 
>   * 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.
> 
> #2 Complete separation of data structures. The var and fix structures
>    need rework badly. All things that are not explicitly needed by
>    a higher level api should not be in there. Those things belong
>    in the driver private data structures (It doesn't matter that
>    nearly everyone will have an mmio pointer, it doesn't belong in
>    a public data structure)

First I plan to cleanup the framebuffer layer. Then with the new device
filesystems coming up in 2.5.X plan to create a new interface for all
this. So the current inteface will go away. I plan to make something like

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

>     * The software fallback functions should be set up in a more
>       explicit way to keep these pointers out of other people's hands.
>       For example, the console functions (putc, putcs etc) should
>       be done something like this.
>       fb->console_ops = create_generic_console_ops(base,pitch,depth);
>         or use a hardware specific set as you would today.

Those will be hidden from the fbdev driver writer. Then will all be
managed in fbcon.c. 

>     * I've seen mention of this in some posts but clearly the fb
>       driver should not be tied in any way to the console. My driver
>       has all the hardware functions totally independent of the
>       interface. The fbcon is an interface provided on top of a
>       graphics driver. They are currently way too connected, and
>       in my opinion this is one reason that a lot of the X & DRI
>       developers are not interested in combining efforts. The
>       result of console + graphics driver looks nothing like a
>       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. 

> #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
>    type of thing only makes a mess for everyone. Better to allow
>    a hardware specific switch to alter the output device and just
>    allow the driver to limit the available modes based on this
>    hardware specific switch. 

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. 

> #4 It would certainly be nice to combine the drm code into the fb
>    code. NOTE: I wouldn't want to do this until the drivers are
>    organized like graphics drivers instead of consoles. 

Agree.