> > 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. ------------------------------------------------------- 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 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
