Means that the RadeonKMS module(s) are not loaded. So as not to get into an extended description of the problem and solution, I'll just suggest you do this:
Start xorg from KDM
Check whether you have a /dev/dri/card*. If you do, RadeonKMS is being used and by inverse it's not used if there is no such file.
<ctrl>+<alt>+<F*> to some tty*, login and run below to kill kdm server: # service kdm onestop
Now try running # Xorg -configure from same tty. You should be able to get your xorg.conf.
Whether your laptop is using RadeonKMS or not will be relevant if you end up having to debug your xorg.conf.
------------------------------------------------------------
hi i just had similar problems, a total bitch infact, with debian xorg on intel (is not texas instruments GL all in silicon, is the real problem: these cards are VERY needy and can't even change modes after startup w/o rebooting)
here's my mileage. my driver had depends on fb, so i install fbcon (frame buffer console, with intelfb driver). i do it all as module so i can giveoptions as i work through the bumps i know will occur
it was the worst i'd ever experienced. there were many dependancies but they weren't all shown and the modules.dep and modules.order files infact showed slighly differing order! i had onloy misleading articles from ubantu to go by, and they don't like spreading info they can get people to pay for, or laugh at people who can't ever get it done.
i got vga and only vesa X (vesa X has few 2d acceleration but otherwise i suggest it - very reliable huge time saver, if that's ok)
so i continued only to find out "what the hell is going on in driver world on newer cards"
yes - i didn't want 3D at all to tell the truth. just wondering what in THE HELL was still going on !!!
---------------------------------------------------------
i found i have to boot up in graphics mode not VGA because (linux, fbset, the driver) would DROP modeset after boot. if i remember the early days of 3D correctly it was due to cheap ass cards that didn't actually contain both VGA and GL in silicon: it was faked and could only do oneatatime.
i now have to have TWO kernels to have framebuffer graphics and accelerated 2d: one with framebuf working. because there can't be a change in video mode !
(i might be able to vbetool myself from gl mode to vga again but not back: but not wisely though, might break something)
??? LISTEN. WHAT IF I NEED TWO OR THREE KERNELS FOR EACH HARDWARE DEVICE TO WORK WITH VARYING SOFTWARE THAT NEEDS A SIMPLE OR ADVANCED MODE ??? my HD is full of kernels and i have no disk space and a huge power bill, at best !!!
SO. it was not only that. something in kernel or debian went and deleted my /dev/dri/card[n] and replaced it with /dev/dri/dri[n] !!!! s.o.a.b. so for like an hour or what i have it set up it won't boot i'm reading source code only to mistakenly "ls /dev/dri" out of frustration and see some asswipe had done that. i mean: i made a script to do the mknod and checked it. someone changed the damn thing. it was not a typo or done by hand. again: some distro hacker had moved around standard /dev names, and some other had done some black magic to delete things in /dev. it wasn't UDEV i don't run that: i do it by hand, and it always works once done, is why.
----------------------------------------
ANSWER: (was just above i'll repeat)
insure your kernel compiles in OpenGL accelerated support so you boot seeing it (not in SVGA, not using fbcon, ie, when you see kernel booting it's not VGA it's in small extended graphics mode text usu.). it's not real vga or vesa it's actaully a broken extended video mode that fakes text "till you get into desktop graphics mode"
insure you have fb support "but not too much". the intel driver uses fb but can't have the intelfb driver compiled in (it will refuse to work that way. if not use a kernel param to insure no fb hardware level driver is lothataded). you can't have two hardware level drivers NOT EVEN AS MODUle, AND YOU can't boot into graphics sub-mode if it's compiled as module: didn't we discuss that already?
don't run "UDEV" (linux) and do double check /dev/dri/card0 - even check the kernel directory / info and see if it maps the pci device (lspci?) to /dev/dri/card0
X doesn't really support the card (it's not vesa S3 card), kernel does per say - it's code was moved into kernel because "it's naughty video code" (piece of crap card). If you have your compiled in / not compiled in right and boot up in "modesetting mode" (not svga, a special graphics mode that is non standard which shows text but is a dispaly surface gl can render in)
I had to read intel's docbook, know all the asm and stuff i knew since the 1980's, read the kernel code and also about other 3d cards PLUS Xorg's drm - to figure out what was wrong. in my case: i beleived they could be modules: no that's a lie. i then thought DRM depended on intelfb, that's wrong. i had no warning. only misleading bull.
in the end you have to trace the dependancies of i915 (or what you have) insure they load, that when kernel prints it's first text it's in "non-standard graphics mode that fakes text". and X will load unless /dev/ is pooched by your friends.
X will load right up if your driver is loaded right. X isn't your problem The driver is in your kernel, that's what you need to compile / check into.
X11R6 would theoretical work just as well as Xorg if we keep in mind X doesn't have or support the hardware calls to the hardware (the driver): the kernel does.
YOUR PROBLEM IS. the kernel is setup for VGA text not X god knows why every other damn usb widget they compiled in. there is no step by step flowing instruction except misleading instruction which leads to hours or days of frustration depending on what you know and are mislead to believe. the base system (ie, /dev/) is also messed with (by udev, or by absence). ie you always see /dev/floppy even though they know no one has one anymore: but they are back stabbin you: they leave it out a core file: the video file so you can see! another sad fact is if they did enable it people would complain: it doesn't support any standard booting in "modeset mode" except graphical desktop mode: it's not vga or vesa compatible and can't be changed - and would fail if you you moved the card from one pc to another depending on kernel options !! just very very bad planing i wouldn't call it planning i'd call it "a hold up - hold your hands high"
----------------------------------------
listen. i pretty sure some people (asia? microsoft?) are making things difficult for linux (debian, bsd, any where many unkonws can hack in) intently. it's not a bsd problem. you'll spend extra time. it probably DOES work (it's intel, and they already released the driver: it works). you see allot of good work (most of X, xpdf, cairo, tk allot of linux) but there's allot of tampering now: and it's with intention to harm, to waste time, to get rid of competition (free competition not run by overpaid government workers or microsoft: that kind, ie in the usa they went and fired all the unix collegeate proffessors - to get rid of them, why you see allot less new unix advances in the usa: microsfot et al are in DC running of grant money, are enjoying programming with gov authority: and want badly to keep it that way, forever, even if you die, and i'm not kidding at all. we also have foreigners overruning the population here, and they are abusing their numbers and stealing shitloads that even china feels the debt of)
and this cheap 3D thing (non SGI, not IBM, not Texas Inst. - ati nvidia crap) where GL,VGA,PCI isn't in the product you bought but allot of it is your pc and software acting like the card is doing it? it's bull. beleive me: it can all be in silicon i have one from the mid/early 1990's. works perfect and require 0, no, nada, nothing NO DRIVERS
how's that sports fans?
(when you have all in silicon, it can boot vga, change modes and add accel 2d to that, and you open a display surface (a device context, a small window on the desktop to bitblit to) with an adde code that the GL card knows, and says: ok the desktop is 2D as usual, this new window i render in): and rendering only is done in that window: and no drivers are needed one can send most codes directly to the card at a well know address: if they pleased, if they wanted to (all they need is the pointer to the DC mentioned above as an arguement to GL functions they use). these new 3D cards cheat in allot of ways including final quality. but they ARE fast and cheap in price. but they ARE SIMPLY NOT WORTH ONE MILLION UNIX USERS WITH GRAPHICS COMPLAINTS ARE THEY?????? NO.)
