Okay...
Seeing the explosion of posts relating to this and the ideological split I see
here I'm now left with the undesirable job of choosing which of two contested
paths to follow with writing the code.
The path I agree with - the "One Device - One Driver" path - seems to be
disliked by a lot of kernel developers, and would likely see my code not
being merged anytime in the future.
The other path - that asking for a mediation layer so multiple drivers can use
the same device - seems to be in large favor, will likely see the code
merged... But it requires doing something that I'm not sure is the right
thing to do.
I've spent a good portion of the past two days pondering this and trying to
figure out a good way to go about things, and it seems to me that the best
idea would be to add a "third" graphics system. However, this third graphics
system would be mostly transitional code aimed at supplanting the fbdev and
DRM kernel code.
The goal of adding said "third system" would be to provide a minimal
kernel-level API for interfacing with the hardware acceleration features and
providing a userspace library for doing most of the interfacing work.
Done properly (something I always try for) this system would supplant DRM on
Linux by providing a built-in system for accelerating all grahpics
applications. This system would be quite similar to ALSA in nature and
spirit.
I'm asking for advice from the experienced people on this list for help, since
until I have a clear picture of what the kernel needs in a "modern" graphics
system I cannot proceed.
DRH
-
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]
