On Fri, 2010-11-26 at 08:44 +0100, Michel Dänzer wrote: > On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers > wrote: > > On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > > > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > > > wrote: > > > > > > > Can you see an easy solution which allows changes during X's runtime and > > > > will handle UMS transparently? > > > > > > One possibility would be an r[36]00_dri.so wrapper which can pass > > > through to the classic or Gallium drivers based on KMS vs. UMS and > > > configuration via environment variables and/or configuration files. This > > > might be appropriate for upstream as well. > > > > > That sounds an awful lot like work :). > > I've thought of a simpler possible solution: > > * Fix the Gallium drivers to bail gracefully instead of crashing > with UMS (this will need to happen anyway). > * Ship the classic and Gallium drivers in separate directories and > set the libGL search path such that the two directories will be > tried one after another. > > r300g would be in the first directory searched. With UMS, it would fail > to initialize, and libGL would pick up r300 from the second directory. > > This solution would also allow overriding the default driver with > $LIBGL_DRIVERS_PATH. > > I really hope you don't have to stick with your ugly X driver patch. :} >
That sounds like a good plan. Do you know off the top of your head how much of this is already ready?
signature.asc
Description: This is a digitally signed message part
