On Tue, 03 Apr 2012 18:37:32 +0200 Michael Hampicke <gentoo-u...@hadt.biz> wrote:
> > > 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. > Here's a tip for when you go down that rabbit hole (and yes, there really is a wonderland at the other end): Don't let your prior knowledge of Windows stuff taint your headspace about graphics systems. Windows and X11 on Linux are so vastly different there's almost no common knowledge that they share. True, the hardware is the same and you still put the same data in it to light up pixels, but that's about where the similarity ends. -- Alan McKinnnon alan.mckin...@gmail.com
