Re: fbdev upstream

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Then a standard generic way to retrieve this information from the fbdev 
> might be an idea.   At the very least you should get the bare modelist 
> but if the other info is available (manufacturer, model number, serial 
> number, raw edid data) then that can be returned as well.   Again this 
> is 2.7 material.

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

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.

> That's why I'm putting a lot of my stuff into fbcon as it's console 
> related.   Is X the only other system to use fbdev other than fbcon?

No. There is an implementation of Mesa/DRI on top of fbdev (witout X),
there is MacOnLinux virtual machine (running Linux, MacOS or MacOS X)
that uses fbdev, there is directfb, at least...

One thing we discussed a while ago with Jon Smirl was to move the actual
console engine out of the kernel. That's a possibility though may not be
necessary as long as things are properly split. But I'd like to get rid
of the accel ops in the kernel and shove all that in userland libs that
can make use of CCE engines when available etc... and provide more APIs
like surfaces overlay etc.. (useful for full screen set-top-box type
applications).

Ben.




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