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

[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.)

-- 
:wq