Re: OpenGL-based framebuffer concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/24/06, Dave Airlie <[email protected]> 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux