Re: fbdev upstream

Benjamin Herrenschmidt wrote:

I think we need the driver to have a "detect displays" method
ultimately, that builds either an identification string, or a
modelist.

If we go to the ID string way, it could be something like

EDID,<EDID data in hex>
APPL,<Apple old style sense code>
FIXD,<fixed mode line>

(the above are random examples coming out of my mind right now)

Or we can have the driver build a modelist. Though if we are going
to move things to userland, it makes sense to move the modelist building
down there as well...
 

Sounds good.   That way if fbcon is not being used then userland can 
worry about everything and if it is used it can parse that data and 
generate a good startup mode to use.

We also want to define some hotplug events for displays

Finally, we need to extend the fbdev API (via sysfs ?) to separate
clearly the physical outputs (and detection of what they are connected
to) from the actual CRTCs and some way to setup the mapping between
outputs and CRTCs (1 CRTC routed to several outputs, 2 CRTCs on
2 different outputs, etc..)

I'm about to implement dual head in radeonfb, and the above is hell,
I want to support mirroring for example, but then, you have only one
/dev/fb entry and 2 different modes ... things like that...  Getting
the user API right isn't simple.
 

I see what you mean.  Looks like I need to do some research on sysfs and 
get more familiar with it.  I'll help out any way I can.

John




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click