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.) -- :wq
