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