Re: [gentoo-user] Re: Advice about ati-drivers? [50% SOLVED]

[Michael Hampicke]

Am 03.04.2012 17:37, schrieb Michael Mol:
> On Tue, Apr 3, 2012 at 9:54 AM, Michael Hampicke <gentoo-user@××××.biz> wrote:
>>
>>
>> Am 03.04.2012 13:28, schrieb Nikos Chantziaras:
>>> On 03/04/12 03:16, Michael Hampicke wrote:
>>>>> However, now that the firmware loading problem is fixed, my screen still
>>>>> goes
>>>>> black on bootup.  But now it's instantaneous instead of 60 seconds
>>>>> delayed :(
>>>>>
>>>>> I'm back to functioning vesa mode if I boot with radeon.memset=0, but
>>>>> that's
>>>>> not really my goal...yet :p
>>>>
>>>> Last time I reinstalled gentoo, I tried kms too (with my Radeon HD2600
>>>> card). And I had lots of problems with it - in combination with
>>>> ati-drivers fglrx module (blank on boot, freeze while starting X,
>>>> generell crashes and kernel panics, low performence...,...). So I
>>>> finally decided not to use kms disable everything related to kms. Since
>>>> then everything is running smoothly. Two weeks ago, I purchased an new
>>>> video card (Radeon HD7770) and gave kms another shot. And again,
>>>> everything went down the crapper. So disabled it. I can live without it
>>>> for the time being. But still, I would be interested in the "why?".
>>>
>>> You cannot use two drivers at once.  Either use the kernel driver (which
>>> does KMS), or ati-drivers.  You cannot mix drivers.  Not in Linux, and
>>> not in any other OS I'm aware of.
>>>
>>>
>>
>>        Seems like there have been some changes on that subject in time. Keep
>> in mind, up until a few months ago I was running Windows7 on my
>> workstation. I'm not new to linux, as I've been using linux on servers
>> since a very long time, but the whole X stuff is kinda new for me.
>>
>> In the past I always experimented with linux in dual boot, and I vaguely
>> recall that there were (or are?) different kinds of video drivers on
>> linux. You had the drivers provided by the kernel, the drivers of Xorg -
>> like xf86-video-ati - and third party drivers like ati-drivers fglrx.
>> And now there's kms too, which I understand is not a driver, but a means
>> for the kernel to setup the driver itself (resolution, color depth).
>>
>> So, if I now use the kernels radeon driver, i could use kms, but cannot
>> use xf86-video-ati or fglrx, if I use xf86-video-ati or fglrx, I cannot
>> use kms?
>>
>> It would be great if someone could link me to some reading material on
>> that subject. Something that explains, the difference between kernel
>> video drivers, framebuffer console, Xorg video drivers and 3rd party
>> drivers.
>>
>
> Just noticed this, and thought of you and this thread:
>
> https://www.osadl.org/Single-View.111+M5afc75f7e68.0.html
>
> Also, if you really want to be able to dig in and do interesting
> things without the aid of GNOME, KDE or XFCE, I highly recommend X
> Power Tools. The book predates KMS, but then so will anything
> resembling a thorough treatment.
>
> http://shop.oreilly.com/product/9780596101954.do
>
> But a quick rundown regarding the difference between kernel video
> drivers, framebuffer, Xorg and 3rd-party drivers:
>
> There are two halves to the story. The kernel and userland. Both sides
> have their own halves of drivers for whatever functionality you need.
>
> Kernel:
>
> 1) Console drivers. These typically access the video adapter's
> built-in text display mode. They don't provide for graphics outside
> the glyphs built into the video cards. These are typically
> *incredibly* fast for text-mode usage, in comparison to framebuffer
> drivers. Enough that if you don't silence build output, you can
> measure differences in compile times of a large program that come from
> the compiler waiting to flush its stdout stream buffer.
>
> 2) Framebuffer drivers. These are simple drivers taking advantage of
> basic raster graphics capabilities in the video adapter. The kernel
> framebuffer drivers treat the display as a giant image, and draw text
> glyphs and other graphics onto them.
>
> 3) Direct Rendering Management (DRM) drivers. These have traditionally
> been how X has been allowed low-level access to 3D graphics
> accelerators. (I'm simplifying here a bit). The DRM subsystem has
> undergone at least two major revisions. It's also specific to Linux,
> and isn't available (AFAIK) on other systems which can run X. DRM in
> this context has nothing to do with 'Digital Rights Management'.
>
> 4) Kernel Mode Setting (KMS). Historically, once X launched, X used
> its own hardware drivers (unless you had it talk to a kernel
> framebuffer driver) to talk to video devices. Once X started, the
> kernel gave control over graphics hardware to X, and depended on X to
> hand it back if you wanted to switch to a virtual terminal for a plain
> console. That meant that if X crashed, your video setup was left
> pretty much in complete disarray, and you had to use a SysRq sequence
> to get it back. (I swear, I'll need to add that to my email signature
> before I'll remember it...) KMS is supposed to keep that
> responsibility with the kernel, with the kernel telling the video
> adapter which display modes to use.
>
> 3rd-party drivers from AMD and NVidia have generally hung out in the
> DRM area. I don't know if either AMD or NVidia have been adding
> support for KMS to their drivers.
>
> And that's just the kernel side of the story. The userland side mostly
> involves extensions to the X protocol. The big ones you should care
> about are the Xv extension and the GLX extension.
>
> The Xv extension is used for basic acceleration of 2D operations,
> especially blitting and stretching of images. That's particularly
> useful in video playback. The Xv extension needs to be implemented by
> the X11 half of the video drivers.
>
> The GLX extension implements OpenGL (more correctly,
> OpenGL-like...there's a trademark thing going on there, but it's more
> a legal thing than a technical thing.) for X11, giving X applications
> access to standard definitions and methods for manipulating 3D
> primitives like textures, meshes, polygons, viewpoints, lighting. Some
> time in the last decase, on-GPU programs called pixel shaders and
> vertex shaders also became available. (This have more recently been
> generalized, which is what's driving the whole thing behind CUDA and
> OpenCL.)
>

Thank you for your little tour around the kernel- and userspace-side of
video drivers and protocols. I think now I have a general idea on what's
going on, and what does what. But I'm gonna investigate this further the
next time a have a bit freetime. I guess there are some pretty
interesting storries in this area.