Re: OpenGL-based framebuffer concepts

["Jon Smirl" <jonsmirl@gmail.com>]

On 5/24/06, Dave Airlie <airlied@gmail.com> wrote:
> The current system is fixable, we've discussed how to fix it a number
> of times, however there have never been resources to do it, we
> explained to Jon on a number of occasion how we as the maintainers
> felt it should be fixed, the patches he produced didn't follow the
> direction we wanted, he stated "the writer decides", we stated "the
> maintainers don't accept it".

I have done the following things...
1) Repeatedly discussed the design of the fixes in depth on the mailing lists
2) Provided extensive documentation of a path to fix the current set of problems
3) Provided numerous patches fixing various parts of the problem

But now it is a year latter and kernel graphics sits exactly where it
was a year ago. There has been zero forward progress. The X developer
obsession of reducing all OSes to a least common denominator is
clearly holding back Linux graphics support. Merging DRM and fbdev is
a win for Linux since it eliminates one of the places where two
independent drivers are trying to control the same piece of hardware.
The merging is blocked because of issues with DRM on BSD (merging
would introduce GPL code into DRM which couldn't then be ported onto
BSD without forking).

So instead of doing a merge a complicated device driver sharing bus is
being constructed

> Okay I've put up two patches at
> http://www.skynet.ie/~airlied/patches/merge/three_tier.diff
> http://www.skynet.ie/~airlied/patches/merge/three_tier_2.diff
> Neither of these do what I wanted to do but they give a lot of ideas
> on how to do it, the device model required in the end using a bus to
> do this, I actually had some thoughts about it at the X.org developers
> conference earlier in the year while reading LDD, but I've been
> swamped since and probably won't get back to it until OLS.


I'm still sticking with my core driver principles:
1) One driver per device
2) A loaded driver must mark the device in use
3) Don't touch hardware that the driver doesn't own
4) Don't use root priv to bypass OS functions
The current graphics code violates all of these

Blocking my changes has resulted in the loss of a full time developer
from an area that is woefully understaffed. I would strongly suggest
that anyone considering doing work in this area to learn from my
experience. Since acceptance of any work you do is questionable, only
work on tiny pieces. Then when your work is blocked you won't have
lost months of effort. I would recommend doing no more that a week's
work before trying to get it merged. And don't start on other changes
while waiting on results from the first one. If the first one is
blocked (likely) you don't want your second change depending on it.

--
Jon Smirl
jonsmirl@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/