> > > > So it calls gtk init and this opens a display connection, it then calls > > XOpenDisplay in another place, it createa context on the gtk inited > > connection, then creates another context on the XOpenDisplay connection > > passing the gtk context as a share. > > > > Now we don't end up with the same screen as they were inited on separate > > display connections, and thusly the contexts shared buffer objects from > > different kernel memory managers which blows up. > > > > So is this legal? I suspect we should be returning BadMatch to the > > glXCreateContext. > > glthreads also has this behavior as an option. > > gl_shared_state has a DriverData, and I'm wondering if we shouldn't be > putting just about all of our DRI screen stuff in there.
yup after talking to aar...@nvidia, their GLX does this so I suspect we do need to do something like that. Dave. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
