[PATCH] [RFC] dix/mi: remove ChangeWindowAttributes from rendering path.

Aaron Plattner aplattner at nvidia.com
Mon Apr 4 14:37:57 PDT 2011


On Mon, Apr 04, 2011 at 02:26:42PM -0700, Dave Airlie wrote:
> On Tue, Apr 5, 2011 at 6:42 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
> > On Mon, Apr 04, 2011 at 01:24:10PM -0700, Dave Airlie wrote:
> >> > Are you planning on leaving the ChangeWindowAttrbutes screen hook there, or
> >> > is it slated for deletion?  I ask because we currently wrap CWA so we can
> >> > watch for colormap changes on PseduoColor windows.
> >> >
> >>
> >> Can you give me a why?
> >
> > ftp://download.nvidia.com/XFree86/Linux-x86/270.30/README/xconfigoptions.html#cioverlay
> >
> > When the colormap changes, we need to flush the updates through to the
> > hardware.
> 
> Okay is there a better time to do this? CWA doesn't seem like a thing
> that should be hitting hardware,

I don't think there's anything else that happens when a non-installed
colormap changes, is there?

> how many colormaps can you have in the hardware? one? one per window?
> etc. Just wondering is
> it really associated with the Screen and not the Window etc.

I know it's funky, but that overlay mode doesn't actually look at the
installed map, but rather the map associated with each window.  Updates to
the colormap take effect immediately and apply directly to the
corresponding window.  All of the windows are displayed with correct colors
simultaneously.

> > We also hook heavily into the ValidateTree series of calls because properly
> > sequencing window moves with asynchronous OpenGL clients is hard,
> > especially with Xinerama in the picture.  I guess maybe if you want to make
> > Windows opaque to the graphics driver but not to extensions, we could
> > marshal that stuff through our GLX extension module.  Still, we have more
> > than a decade's worth of bug fixes in that area and it would make me really
> > nervous to try to rearrange that stuff.
> 
> You could release your GLX implementation source code and merge it into
> the X.org GLX implementation and this would make your life a lot easier,

Negatory (and I know you know better).

> Yes so extensions would hook onto the protocol screen instead of hooking
> onto the underlying GPU screen since they are an extension of the
> protocol. It sounds like this should be done via your GLX, and I've got a
> very tiny violin playing at the thought of you guys having to spend some
> money on keeping up with us for a change.

Can you shelve the attitude, please?  I'm trying to work with you here to
make sure we can achieve what you want to do without breaking too much
stuff.


More information about the xorg-devel mailing list