1 |
On Tue, 03 Apr 2012 18:37:32 +0200 |
2 |
Michael Hampicke <gentoo-user@××××.biz> wrote: |
3 |
|
4 |
> |
5 |
> |
6 |
> Am 03.04.2012 17:37, schrieb Michael Mol: |
7 |
> > On Tue, Apr 3, 2012 at 9:54 AM, Michael Hampicke |
8 |
> > <gentoo-user@××××.biz> wrote: |
9 |
> >> |
10 |
> >> |
11 |
> >> Am 03.04.2012 13:28, schrieb Nikos Chantziaras: |
12 |
> >>> On 03/04/12 03:16, Michael Hampicke wrote: |
13 |
> >>>>> However, now that the firmware loading problem is fixed, my |
14 |
> >>>>> screen still goes |
15 |
> >>>>> black on bootup. But now it's instantaneous instead of 60 |
16 |
> >>>>> seconds delayed :( |
17 |
> >>>>> |
18 |
> >>>>> I'm back to functioning vesa mode if I boot with |
19 |
> >>>>> radeon.memset=0, but that's |
20 |
> >>>>> not really my goal...yet :p |
21 |
> >>>> |
22 |
> >>>> Last time I reinstalled gentoo, I tried kms too (with my Radeon |
23 |
> >>>> HD2600 card). And I had lots of problems with it - in |
24 |
> >>>> combination with ati-drivers fglrx module (blank on boot, freeze |
25 |
> >>>> while starting X, generell crashes and kernel panics, low |
26 |
> >>>> performence...,...). So I finally decided not to use kms disable |
27 |
> >>>> everything related to kms. Since then everything is running |
28 |
> >>>> smoothly. Two weeks ago, I purchased an new video card (Radeon |
29 |
> >>>> HD7770) and gave kms another shot. And again, everything went |
30 |
> >>>> down the crapper. So disabled it. I can live without it for the |
31 |
> >>>> time being. But still, I would be interested in the "why?". |
32 |
> >>> |
33 |
> >>> You cannot use two drivers at once. Either use the kernel driver |
34 |
> >>> (which does KMS), or ati-drivers. You cannot mix drivers. Not |
35 |
> >>> in Linux, and not in any other OS I'm aware of. |
36 |
> >>> |
37 |
> >>> |
38 |
> >> |
39 |
> >> Seems like there have been some changes on that subject in |
40 |
> >> time. Keep in mind, up until a few months ago I was running |
41 |
> >> Windows7 on my workstation. I'm not new to linux, as I've been |
42 |
> >> using linux on servers since a very long time, but the whole X |
43 |
> >> stuff is kinda new for me. |
44 |
> >> |
45 |
> >> In the past I always experimented with linux in dual boot, and I |
46 |
> >> vaguely recall that there were (or are?) different kinds of video |
47 |
> >> drivers on linux. You had the drivers provided by the kernel, the |
48 |
> >> drivers of Xorg - like xf86-video-ati - and third party drivers |
49 |
> >> like ati-drivers fglrx. And now there's kms too, which I |
50 |
> >> understand is not a driver, but a means for the kernel to setup |
51 |
> >> the driver itself (resolution, color depth). |
52 |
> >> |
53 |
> >> So, if I now use the kernels radeon driver, i could use kms, but |
54 |
> >> cannot use xf86-video-ati or fglrx, if I use xf86-video-ati or |
55 |
> >> fglrx, I cannot use kms? |
56 |
> >> |
57 |
> >> It would be great if someone could link me to some reading |
58 |
> >> material on that subject. Something that explains, the difference |
59 |
> >> between kernel video drivers, framebuffer console, Xorg video |
60 |
> >> drivers and 3rd party drivers. |
61 |
> >> |
62 |
> > |
63 |
> > Just noticed this, and thought of you and this thread: |
64 |
> > |
65 |
> > https://www.osadl.org/Single-View.111+M5afc75f7e68.0.html |
66 |
> > |
67 |
> > Also, if you really want to be able to dig in and do interesting |
68 |
> > things without the aid of GNOME, KDE or XFCE, I highly recommend X |
69 |
> > Power Tools. The book predates KMS, but then so will anything |
70 |
> > resembling a thorough treatment. |
71 |
> > |
72 |
> > http://shop.oreilly.com/product/9780596101954.do |
73 |
> > |
74 |
> > But a quick rundown regarding the difference between kernel video |
75 |
> > drivers, framebuffer, Xorg and 3rd-party drivers: |
76 |
> > |
77 |
> > There are two halves to the story. The kernel and userland. Both |
78 |
> > sides have their own halves of drivers for whatever functionality |
79 |
> > you need. |
80 |
> > |
81 |
> > Kernel: |
82 |
> > |
83 |
> > 1) Console drivers. These typically access the video adapter's |
84 |
> > built-in text display mode. They don't provide for graphics outside |
85 |
> > the glyphs built into the video cards. These are typically |
86 |
> > *incredibly* fast for text-mode usage, in comparison to framebuffer |
87 |
> > drivers. Enough that if you don't silence build output, you can |
88 |
> > measure differences in compile times of a large program that come |
89 |
> > from the compiler waiting to flush its stdout stream buffer. |
90 |
> > |
91 |
> > 2) Framebuffer drivers. These are simple drivers taking advantage of |
92 |
> > basic raster graphics capabilities in the video adapter. The kernel |
93 |
> > framebuffer drivers treat the display as a giant image, and draw |
94 |
> > text glyphs and other graphics onto them. |
95 |
> > |
96 |
> > 3) Direct Rendering Management (DRM) drivers. These have |
97 |
> > traditionally been how X has been allowed low-level access to 3D |
98 |
> > graphics accelerators. (I'm simplifying here a bit). The DRM |
99 |
> > subsystem has undergone at least two major revisions. It's also |
100 |
> > specific to Linux, and isn't available (AFAIK) on other systems |
101 |
> > which can run X. DRM in this context has nothing to do with |
102 |
> > 'Digital Rights Management'. |
103 |
> > |
104 |
> > 4) Kernel Mode Setting (KMS). Historically, once X launched, X used |
105 |
> > its own hardware drivers (unless you had it talk to a kernel |
106 |
> > framebuffer driver) to talk to video devices. Once X started, the |
107 |
> > kernel gave control over graphics hardware to X, and depended on X |
108 |
> > to hand it back if you wanted to switch to a virtual terminal for a |
109 |
> > plain console. That meant that if X crashed, your video setup was |
110 |
> > left pretty much in complete disarray, and you had to use a SysRq |
111 |
> > sequence to get it back. (I swear, I'll need to add that to my |
112 |
> > email signature before I'll remember it...) KMS is supposed to keep |
113 |
> > that responsibility with the kernel, with the kernel telling the |
114 |
> > video adapter which display modes to use. |
115 |
> > |
116 |
> > 3rd-party drivers from AMD and NVidia have generally hung out in the |
117 |
> > DRM area. I don't know if either AMD or NVidia have been adding |
118 |
> > support for KMS to their drivers. |
119 |
> > |
120 |
> > And that's just the kernel side of the story. The userland side |
121 |
> > mostly involves extensions to the X protocol. The big ones you |
122 |
> > should care about are the Xv extension and the GLX extension. |
123 |
> > |
124 |
> > The Xv extension is used for basic acceleration of 2D operations, |
125 |
> > especially blitting and stretching of images. That's particularly |
126 |
> > useful in video playback. The Xv extension needs to be implemented |
127 |
> > by the X11 half of the video drivers. |
128 |
> > |
129 |
> > The GLX extension implements OpenGL (more correctly, |
130 |
> > OpenGL-like...there's a trademark thing going on there, but it's |
131 |
> > more a legal thing than a technical thing.) for X11, giving X |
132 |
> > applications access to standard definitions and methods for |
133 |
> > manipulating 3D primitives like textures, meshes, polygons, |
134 |
> > viewpoints, lighting. Some time in the last decase, on-GPU programs |
135 |
> > called pixel shaders and vertex shaders also became available. |
136 |
> > (This have more recently been generalized, which is what's driving |
137 |
> > the whole thing behind CUDA and OpenCL.) |
138 |
> > |
139 |
> |
140 |
> Thank you for your little tour around the kernel- and userspace-side |
141 |
> of video drivers and protocols. I think now I have a general idea on |
142 |
> what's going on, and what does what. But I'm gonna investigate this |
143 |
> further the next time a have a bit freetime. I guess there are some |
144 |
> pretty interesting storries in this area. |
145 |
> |
146 |
|
147 |
Here's a tip for when you go down that rabbit hole (and yes, there |
148 |
really is a wonderland at the other end): |
149 |
|
150 |
Don't let your prior knowledge of Windows stuff taint your headspace |
151 |
about graphics systems. Windows and X11 on Linux are so vastly different |
152 |
there's almost no common knowledge that they share. True, the hardware |
153 |
is the same and you still put the same data in it to light up pixels, |
154 |
but that's about where the similarity ends. |
155 |
|
156 |
|
157 |
-- |
158 |
Alan McKinnnon |
159 |
alan.mckinnon@×××××.com |