Am 03.04.2012 17:37, schrieb Michael Mol: > On Tue, Apr 3, 2012 at 9:54 AM, Michael Hampicke <gentoo-u...@hadt.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.
