Re: framebuffer ioctl

[Jon Smirl <jonsmirl@gmail.com>]

On Wed, 8 Sep 2004 16:59:35 +0300, Ville Syrjälä <syrjala@sci.fi> wrote:
> I welcome you work on the drm since it appears to reduce the amount of
> unnecessary user space init code. When the drm gets easier to use other
> projects may adopt it.

Direct use of DRM will satisfy the goal of keeping all of the drivers
from stomping on each other. I would encourage you to consider using
mesa but there is no requirement to do so. There is a 300KB open
source OpenGL-ES implementation that could be ported to DRM if the
size of mesa is a problem.

I would encourage people with the skills to write video drivers to
come help with DRM instead of creating more conflicting drivers. A
short term goal for DRM is to integrate enough of fbdev in order to be
able to draw the console from kernel space. We also need help
implementing Alan's universal mode setting API since it doesn't exist
yet in any driver.

Most of the conflicts between DRM don't occur from base functionality
in fbdev and DRM, they originate in the chip specific drivers. It's
the chip specific drivers that need to be merged.

Merging DRM into fbdev instead of fbdev into DRM was also considered,
but the complexity of the DRM video memory manager made that too hard.
On the other hand, if I had known what I know now about how many
political problems merging fbdev into DRM was going to cause I would
have just rewritten the DRM memory manager for fbdev and done the
merge the other way. End result would be the same either way.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click