Re: OpenGL-based framebuffer concepts

["Dave Airlie" <airlied@gmail.com>]

> 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).

It has absolutely nothing to do with the GPL vs BSD licensing on the
code it has to do with the belief that fbdev isn't a complete enough
model to do what needs to be done and merging it into the DRM is just
going to make things worse rather than better, I've no idea where you
ever came up with it being a licensing thing at all... the FreeBSD ppl
have on interest in taking fbdev code anyways...

Having a shared layer allows the two drivers to at least discuss the
ownership of the hardware, we have two stacks of software, merging
them into one stack isn't going to solve any magical problems, it just
means we have one larger mess, my belief is once the two can
communicate, the DRM can disable fbdev if a proper solution on top of
the DRM becomes available...  merging fbdev into the DRM is always the
wrong answer, so please stop talking.

> 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

And that's nice for you, it isn't nice in the real world where we have
two drivers driving the device and need to fix it without breaking it
first.
> 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.

That's called working in the kernel, it's always been like that, you
seemed to think your code wasn't going to require re-writes, it did,
you didn't agree with the maintainers suggestions stating you had all
those code depending on it working like you stated.. I could go on,
but I'm just wasting more of the small amounts of time I have to work
on this stuff.

Dave.
-
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/