On Tue, 2016-07-12 at 13:53 -0700, Keith Packard wrote: > Adam Jackson <[email protected]> writes: > > > The intent here was that fallback drivers would be at the end of the > > list in order, but if a fallback driver happened to be at the end of the > > list already that's not what would happen. Rather than open-code > > something smarter, just use qsort. > > > > Note that qsort puts things in ascending order, so somewhat backwardsly > > fallbacks are greater than native drivers, and vesa is greater than > > modesetting. > > > > v2: Use strcmp to compare non-fallback drivers so we get a predictable > > result if your libc's qsort isn't stable (Keith Packard) > > Sorry, I wasn't clear at all. I'm assuming that the original driver list > is relevant, and that what we want to do is pull the 'fallback' drivers > out of the list and stick them at the end (in a sorted order). If that > isn't right, then this patch looks great. If it is true, then we should > figure out some way of preserving the order?
The original list is just whatever readdir() gave us, filtered to match *_drv.so (although doing that bit with regex instead of glob because why not). Which is how I found the bug in the first place: if you reinstall vesa on a filesystem that gives you results in ctime order vesa would be last in the list already, and the first swap would move vesa to wherever fbdev/modesetting happened to be. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
