RandR 1.2 feedback
aritger at nvidia.com
Wed Nov 29 15:17:33 PST 2006
On Wed, 29 Nov 2006, Keith Packard wrote:
> On Wed, 2006-11-29 at 13:58 -0800, Andy Ritger wrote:
>> Thanks, Keith. Fair enough.
>> I think we'll just have to agree to disagree on some of these points.
>> I think the RandR 1.2 spec is workable as-is, so I'll just plan on going
>> with that. I'll look at wiring up the NVIDIA driver to RandR 1.2.
> Cool. We're busy making the RandR 1.2 support shared between Intel and
> Radeon drivers and then moving that to the common layer; let me know if
> you're interested in working with that code, it will also support
> startup configuration through the config file and will work with older X
> servers that do not have RandR 1.2 support.
Yeah, I'll be interested to see what that code looks like. I think to
ensure the most flexibility, I'll want the NVIDIA X driver to be able
to hook the RandR 1.2 requests at a very high level, but I'll look into
the code and see.
>> However, note that NVIDIA's OpenGL implementation works fine within
>> Xinerama today. I don't believe the current Xinerama implementation in
>> the X server precludes direct rendering OpenGL. Any problems we've had
>> implementing OpenGL within the current Xinerama implementation have
>> really been problems with our OpenGL implementation, rather than problems
>> interacting with the Xinerama implementation.
> I have to support heterogeneous GPU environments, which the current
> implementation precludes. For homogenous GPU systems, things are much
Agreed that heterogeneous GPU environments are more challenging.
It still seems like an OpenGL implementation problem, though.
>> Anyway, it sounds like there is a lot of interesting stuff to discuss
>> wrt the Xinerama implementation and how to either replace or improve that.
>> I'll leave the topic alone for now so we can focus on RandR 1.2.
> Sounds like we're go for launch then; I'll finish up the DIX
> implemetation and look forward to seeing it work on your video cards
> Thanks for your help; nice to know we aren't locking anyone out of
> important card features yet.
I'm still a little bit nervous about some of the corner cases, but I
think for the common case it's workable. I'll try to dig into the code
soon. The master branch is the right place to track the changes, now?
(I'm still a git noob)
> keith.packard at intel.com
More information about the xorg