"Dmitri Pogosyan" <pogos...@phys.ualberta.ca> posted 200906171919.n5hjj7007...@webmail.phys.ualberta.ca, excerpted below, on Wed, 17 Jun 2009 13:19:07 -0600:
> I wonder, what are the negatives of moving modesetting to kernel from > userspace ? Will we be loosing some functionality (at least temperarily) > ? How will, say, choosing mode on external distplay work ? The biggest negative for the Intel users has been the rough ride, and yes, some functionality is certainly lost during the transition. It's about done for the Intel users but just starting for Radeon users. Let's see if I can find the (Intel dev) blog I read on that... http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ The date posted was April 24, 2009 Excerpts... Because all of these changes cross multiple projects (X/Mesa/Linux), we’ve tried to make sure we supported all of the possible combinations. Let’s see what options we’ve got: Mode Setting 1 User Mode 2 Kernel Mode Direct Rendering 1 None 2 DRI1 3 DRI2 Memory Management 1 X server + Old-style DRI 2 GEM 2D acceleration 1 None 2 XAA 3 EXA 4 UXA Pick One From Each [Category] With 2 × 3 × 2 × 4 = 48 combinations, you can imagine that: Some of them can’t work together Some of them haven’t been tested Some of them haven’t been tuned for performance Some work well on i915, and poorly on 965GM Others work well on 965GM and poorly on 855 None of them (yet) work perfectly well everywhere The obvious result here is that we’re at a point where application performance goes all over the map, depending on the hardware platform and particular set of configuration options selected. Light at Tunnel’s End The good news is that our redesign is now complete, and we have the architecture we want in place throughout the system — global graphics memory management, kernel mode setting and per-window 3D buffers. This means that the rate of new code additions to the driver has dropped dramatically; almost to zero. Going forward, users should expect this ‘perfect’ combination to work more reliably, faster and better as time goes by. End excerpts... As I said, it was quite the rough ride. But that was nearing the end of April, and things have been better since. Hopefully Radeon won't be quite as bad. We'll see I guess. As for the last question, the example of external display mode, at minimum, it shouldn't regress (except for temporary regressions of the type Keith explained in his blog). The xorg folks have put an enormous amount of work into hotplug, and they won't be letting that go just for this. I'm not entirely sure on this, but from my understanding, X will still be in control of the modes. It'll simply use the kernel's EDID/DDC detection instead of its own to see what modes are there (and whether any additional modes as configured will work within the detected card and monitor parameters) and to do the actual mode switches, but it'll be telling the kernel what mode to use, tho the default will be native/ primary mode for both the CLI/text framebuffer and X initially, thus no mode change switching between them. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
