Re: OpenGL-based framebuffer concepts

[D. Hazelton]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/