Re: fbdev upstream

[John Zielinski <grim@undead.cc>]

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