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 [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]
