| 1 |
"Dmitri Pogosyan" <pogosyan@×××××××××××××.ca> posted |
| 2 |
200906171919.n5HJJ7007690@×××××××××××××××××××××.ca, excerpted below, on |
| 3 |
Wed, 17 Jun 2009 13:19:07 -0600: |
| 4 |
|
| 5 |
> I wonder, what are the negatives of moving modesetting to kernel from |
| 6 |
> userspace ? Will we be loosing some functionality (at least temperarily) |
| 7 |
> ? How will, say, choosing mode on external distplay work ? |
| 8 |
|
| 9 |
The biggest negative for the Intel users has been the rough ride, and |
| 10 |
yes, some functionality is certainly lost during the transition. It's |
| 11 |
about done for the Intel users but just starting for Radeon users. Let's |
| 12 |
see if I can find the (Intel dev) blog I read on that... |
| 13 |
|
| 14 |
http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ |
| 15 |
|
| 16 |
The date posted was April 24, 2009 |
| 17 |
|
| 18 |
Excerpts... |
| 19 |
|
| 20 |
Because all of these changes cross multiple projects (X/Mesa/Linux), |
| 21 |
we’ve tried to make sure we supported all of the possible combinations. |
| 22 |
Let’s see what options we’ve got: |
| 23 |
|
| 24 |
Mode Setting |
| 25 |
1 User Mode |
| 26 |
2 Kernel Mode |
| 27 |
|
| 28 |
Direct Rendering |
| 29 |
1 None |
| 30 |
2 DRI1 |
| 31 |
3 DRI2 |
| 32 |
|
| 33 |
Memory Management |
| 34 |
1 X server + Old-style DRI |
| 35 |
2 GEM |
| 36 |
|
| 37 |
2D acceleration |
| 38 |
1 None |
| 39 |
2 XAA |
| 40 |
3 EXA |
| 41 |
4 UXA |
| 42 |
|
| 43 |
Pick One From Each [Category] |
| 44 |
|
| 45 |
With 2 × 3 × 2 × 4 = 48 combinations, you can imagine that: |
| 46 |
Some of them can’t work together |
| 47 |
Some of them haven’t been tested |
| 48 |
Some of them haven’t been tuned for performance |
| 49 |
Some work well on i915, and poorly on 965GM |
| 50 |
Others work well on 965GM and poorly on 855 |
| 51 |
None of them (yet) work perfectly well everywhere |
| 52 |
|
| 53 |
The obvious result here is that we’re at a point where application |
| 54 |
performance goes all over the map, depending on the hardware platform and |
| 55 |
particular set of configuration options selected. |
| 56 |
|
| 57 |
Light at Tunnel’s End |
| 58 |
|
| 59 |
The good news is that our redesign is now complete, and we have the |
| 60 |
architecture we want in place throughout the system — global graphics |
| 61 |
memory management, kernel mode setting and per-window 3D buffers. This |
| 62 |
means that the rate of new code additions to the driver has dropped |
| 63 |
dramatically; almost to zero. Going forward, users should expect this |
| 64 |
‘perfect’ combination to work more reliably, faster and better as time |
| 65 |
goes by. |
| 66 |
|
| 67 |
End excerpts... |
| 68 |
|
| 69 |
As I said, it was quite the rough ride. But that was nearing the end of |
| 70 |
April, and things have been better since. Hopefully Radeon won't be |
| 71 |
quite as bad. We'll see I guess. |
| 72 |
|
| 73 |
As for the last question, the example of external display mode, at |
| 74 |
minimum, it shouldn't regress (except for temporary regressions of the |
| 75 |
type Keith explained in his blog). The xorg folks have put an enormous |
| 76 |
amount of work into hotplug, and they won't be letting that go just for |
| 77 |
this. I'm not entirely sure on this, but from my understanding, X will |
| 78 |
still be in control of the modes. It'll simply use the kernel's EDID/DDC |
| 79 |
detection instead of its own to see what modes are there (and whether any |
| 80 |
additional modes as configured will work within the detected card and |
| 81 |
monitor parameters) and to do the actual mode switches, but it'll be |
| 82 |
telling the kernel what mode to use, tho the default will be native/ |
| 83 |
primary mode for both the CLI/text framebuffer and X initially, thus no |
| 84 |
mode change switching between them. |
| 85 |
|
| 86 |
-- |
| 87 |
Duncan - List replies preferred. No HTML msgs. |
| 88 |
"Every nonfree program has a lord, a master -- |
| 89 |
and if you use the program, he is your master." Richard Stallman |
Archives