[Linux-fbdev-devel] Resource management.

[Dave Airlie]

> 
> 1. Lots of work that would take lots of time. To my knowledge all fbdev
>    developers work in there spare free time. No one does this for a
>    living.

So do most of the drm developers, I know I do and Jon Smirl does, and
Eric Anholt does and I think us three have been the largest
contributers apart from new driver submissions...

> 2. Sharing of headers. The dri headers are isolated in the drm directory.
>    I totally understand why :-) It makes merging easier for them. The
>    disadvantage is no one in the fbdev can use them easily :-(

I plan to move them in 2.6.12 maybe .. it might be 2.6.13 by the time
I get around to it, just some minor issues.. Arjan asked me for this
ages ago as well...
 
> 3. DRM has way to much functionality for most embedded devices. I have
>    talked to embedded guys before and they want a simple api to work with.
>    By default DRM builds in everything. A simple api mean alot to those
>    guys. Plus the extra built in code bloat takes up to much space which
>    is precious on embedded devices. If a devices doesn't support dma then
>    the dma code doesn't need to be built in.

Well crap on that, the old DRM didn't build everything in people
complained aw this code is too messy, build everything in, now you
want to revert? damn you all!!! :-), I understand I'm just saying we
can't have it both ways.. and too be honest I'm an embedded person and
I just want it to work, with a Linux kernel you rarely get to an every
byte counts embedded env, of if you are you aren't using the stock
Linus kernel....

> 
> 4. Which comes to the next point. The code is not modular enough. Take
>    drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
>    One is the fbdev layer couldn't just link into it so fbcon could use
>    it. The second is it's not easy to take advantage of things like sysfs.
>    If you could untangle the code somewhat it would make life so much
>    easier. That would include making life easier for OS ports.

the reason we can't take advantage of sysfs or anything like it is
that we can't bind to the PCI device as we break things.. this is the
root of a lot of our problems...

> 
> 5. The license issue. The DRI code is GPL and additional rights. What is that?
Nope the drm code is BSD... there should be no GPL anywhere near it...
it is GPL in the kernel as of course it is imported into a GPL work..
but the code is available for BSD uses....

Jon's last plan - was like to have a radeon basic module, with fb and
drm personalities and in fact any number of personalities..taking
radeon as example:
base module : hotplug, reset, monitor probing, memory management, CP
programming and locking.
fb: adds accelerated fb functions using CP locking.
drm: adds drm functionality on top of base module, drm ioctl interfaces etc..

I've looked at Alans ideas on a vga_class driver and have decided they
are unworkable due to the massive initial changes they involve in
*every* fb/drm driver in the kernel, I cannot undertake a work of that
magnitude without fb people being involved and the chances of breaking
a lot of stuff.. maybe a 2.7 thing but I don't think we'll ever have a
2.7 for this stuff...

What I do think though is that ideas of a the vga class driver could
be made into a helper module that the base graphics driver uses to do
some standard things, like reset and stuff..

I'm hoping to get a better handle on these ideas and write something
up.. but they are mostly Jons ideas better presented :-)

Dave.