Re: [patch] radeonfb: FB_WAITFORVSYNC implementation

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

On Sat, 2005-03-12 at 12:56 -0500, Jon Smirl wrote:

> 
> 1) where is the list of valid modes computed? in-kernel or user space.
> Technically either will work but each has plus and minuses. Right now
> radeonfb can do both.
> 
> 1a) #1 is computing the mode list, not setting the mode. The mode is
> always set in the kernel.

At first, I would keep the current mecanism. After all, parsing the EDID
and building the modelist is quite simple. Let the kernel driver do it,
pick a default mode, and let userland optionally change that. That gives
us at least a working boot mode for splash/console before userland is
available. fbdev now has an API for userland to add/remove entries to
modelists, we can extend on that.

> 2) multiheads implies buffer management, this needs to be coordinated with DRM

Yes. That's the main issue with the merge imho. My initial version will
do like MacOS, and cut the framebuffer in 2 apertures split in the
middle. That's the simplest way to get 2 independant access swappers.
This is necessary if we want completely independant framebuffer accesses
to /dev/fbN and /dev/fbN+1 with different bit depth. It may not stay
necessary in the long run if we have some lock for fb access, like X
has, in which case we can just switch the swapper settings before each
access.
 
> 3) fbdev needs to implement hardware cursors

That isn't terribly difficult.

> 4) The fb_info struct doesn't work too well for multiple heads. It
> really should be split up into fb_device/fb_head.

Well, when I look at other OSes, they don't do that neither. They
basically behave like if there was one device per head. All we need, I
think, is the necessary infos to let userland know which heads are
"linked" to a given device, but I don't think the fbdev layer has to
care about the concept of "device". All it cares about is a "head" which
is what fb_info represents.

> 5) driver initiated secondary card reset needs to be implement via a
> user space helper.
> 
> 6) fbcon is tied way too closely to fb_info. There should be an
> interface instead of just letting it muck around in fbdev data
> structures.

It's been very significantly split already, but yes, it could probably
be separated a bit more, though there again, we can go step by step,
there is no need to rewrite the whole world at once.

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click