Clearing up some confusion on KMS (video= and nomodeset)
Aaron W. Hsu
wanted to post this up, since this seems to have become an FAQ around here.
Kernel Mode Setting is a new-ish feature of the Linux kernel that I don't
quite get. At any rate, it changes the way things are done. Basically,
this affects how the framebuffer and video modes operate on the consoles,
and it unfortunately also has an effect on how things work with X.
With certain drivers, and I'm thinking of Intel here, you *must* have the
KMS on in order for the intel drivers to work. On other drivers, like the
ATI drivers, you cannot access your consoles unless you disable KMS.
So, for the quick cheat sheet that some people will want:
Configuration #1: No video modes in the console, plain consoles with X
graphics drivers that support this:
You need to add the nomodeset keyword to your append line in lilo.conf and
then rerun lilo and reboot. Done.
Configuration #2: Lower resolution video modes for graphics drivers that
require you to have KMS on.
This one is for those people who may be unfortunate enough to need KMS on,
but who don't want to try deciphering letters made for ants and their kin.
You'll need to add a video=RESxRES to your append= line in lilo.conf,
making sure to pick a resolution that will work for you. This will
probably take some trial and error.
Some other people have mentioned some other things, but this is a good
time to also talk about how your xorg.conf can make your life easier or
harder during upgrades with this stuff. A normal xorg.conf file
traditionally contains all of the sections that you need for configuring
X. This is how you used to have to do it, and it worked well once you got
it working. However, it has the problem of hard coding the video driver
that you're using. This is okay if you know what you are doing, but the
Linux developers and the X.org developers have been going crazy with a
number of different graphics drivers for a bunch of different hardware.
This means that for things like NVidia and ATI, you have up to three
different video drivers that may or may not work for your machine. Worse,
the ones that work best are likely to change over time. The traditional
xorg.conf file hard codes the specific video driver in, meaning that the
next time you upgrade or the next time you want to adapt to a new kernel
or graphics driver, you have to remember to research what the best one is
and put that into your xorg.conf.
However, X.org has provided an option that's a little better. You now
don't have to specify everything in your Xorg.conf file, instead, you can
take pieces and sections from it that have your specific needs, such as
setting modes up for your Video, and put those into distinct files in the
xorg.conf.d directory. X.org will then use those, but it will fill in
sections that you haven't specified with its auto-generated code
automatically. This takes away yet another configuration step with X of
generating a new and fresh xorg.conf file first and then patching it up
based on your old file. You can instead just take the most important parts
that you care about and leave the rest of the stuff to be auto-detected.
This is especially helpful as the developers play with graphics drivers,
as often X.org will find at least one that works correctly, even if the
first choice doesn't.
You can also blacklist modules to make sure that certain drivers don't
show up when you don't want them to, and do other things to manage the
order in which modules and drivers are loaded. A careful combination of
the above techniques will alleviate upgrade pains.
Aaron W. Hsu
--
Programming is just another word for the lost Art of Thinking.
notbob
> I just did a couple of things on my own machine that relates to this, so I
> wanted to post this up, since this seems to have become an FAQ around here.
That FAQ would be where!!??
> Kernel Mode Setting is a new-ish feature of the Linux kernel that I don't
> quite get. At any rate, it changes the way things are done. Basically,
> this affects how the framebuffer and video modes operate on the consoles,
> and it unfortunately also has an effect on how things work with X.
A fact too painfully obvious to many of us.
> With certain drivers, and I'm thinking of Intel here, you *must* have the
> KMS on in order for the intel drivers to work. On other drivers, like the
> ATI drivers, you cannot access your consoles unless you disable KMS.
What is KNS?
> So, for the quick cheat sheet that some people will want:
>
> Configuration #1: No video modes in the console, plain consoles with X
> graphics drivers that support this:
By defualt, they are 1600x1200 res.
> You need to add the nomodeset keyword to your append line in lilo.conf and
> then rerun lilo and reboot. Done.
Be specific. What does this look like in what file?
> Configuration #2: Lower resolution video modes for graphics drivers that
> require you to have KMS on.
Details?
> This one is for those people who may be unfortunate enough to need KMS on,
> but who don't want to try deciphering letters made for ants and their kin.
Yer telling me nothing I can use.
> You'll need to add a video=RESxRES to your append= line in lilo.conf,
> making sure to pick a resolution that will work for you. This will
> probably take some trial and error.
Example, please.
> Some other people have mentioned some other things, but this is a good
> time to also talk about how your xorg.conf can make your life easier or
> harder during upgrades with this stuff. A normal xorg.conf file
> traditionally contains all of the sections that you need for configuring
> X. This is how you used to have to do it, and it worked well once you got
> it working.
Actually, seems to be working damn fine, near as I can tell!
> However, it has the problem of hard coding the video driver
> that you're using. This is okay if you know what you are doing, but the
> Linux developers and the X.org developers have been going crazy with a
> number of different graphics drivers for a bunch of different hardware.
> This means that for things like NVidia and ATI, you have up to three
> different video drivers that may or may not work for your machine. Worse,
> the ones that work best are likely to change over time. The traditional
> xorg.conf file hard codes the specific video driver in, meaning that the
> next time you upgrade or the next time you want to adapt to a new kernel
> or graphics driver, you have to remember to research what the best one is
> and put that into your xorg.conf.
What the fsck are you talking about? Be specific! Try lshw (none
slack app) lspci, etc, to discover spec'd driver.
> However, X.org has provided an option that's a little better. You now
> don't have to specify everything in your Xorg.conf file, instead, you can
> take pieces and sections from it that have your specific needs, such as
> setting modes up for your Video, and put those into distinct files in the
> xorg.conf.d directory.
Just what would the format and necessary sections be?? Gotta
template? Care to be "specific"!!?? Why aren't they there by
default? Why isn't there a new script to generate these preferred new
sub dirs?
> X.org will then use those, but it will fill in
> sections that you haven't specified with its auto-generated code
> automatically.
???????????????????????
When did that occur. Exactly what will it generate? Driver. Mode?
Depth? How would it know unless the usr is asked??
> You can also blacklist modules to make sure that certain drivers don't
> show up when you don't want them to.....
Please point out how/where these blacklist files occur and/or are
used. I found nvidiafb on the black list. What does that mean?
> the above techniques will alleviate upgrade pains.
What techniques??
I've listened to you give advice for some time, now. I know you have
a good heart and are good at generalizing, but you offer less than
spit on useable specifics. In Slackware, generalizations are useless!
nb
Aaron W. Hsu
> I know you have
> a good heart and are good at generalizing, but you offer less than
> spit on useable specifics. In Slackware, generalizations are useless!
Here's the problem, your lilo.conf file is not going to look the same as
mine. Every lilo.conf file in Slackware might be slightly different.
I'm not here to give the basics of operating and configuring Slackware.
There are some basic skills that you should already have developed or
learned to work with Slackware at the level I'm talking about. If it isn't
clear, then you need to actually work with things. I very intentionally
omit cut-and-paste examples because they almost never work, and they often
cause users to do things without first understanding what is going on. I'm
not about to give people cut and paste examples, because they aren't
necessary for this, and they will not help people who are likely to just
use them as starting templates. You *don't* use an example as a starting
template, you use what was generated on your Slackware machine as the
template, and edit to suit. If you want an example of how the sections
should be formatted in an xorg.conf.d file, then how about looking at your
xorg.conf file? It's *exactly* the same, which is obvious if you read the
xorg.conf man page.
I've also seen your responses to things thus far, and I can tell you that
I'm not going to give you what you want here, which is something that you
can type into your computer and have it work. It doesn't work like that.
You need to know what is on your system. You need to experiment and find
out what works for you. I'm just giving the tips and the necessary
information, you need to adapt this information to suit your unique
situation.
So, the sorts of specifics you are talking about are useless in Slackware.
I'm being very specific. You should already know about the append line in
your lilo.conf file because *every* installation of Slackware talks about
it when you go through the installation procedure. If you don't know what
it is, then you should read the basic Slackware documentation on that
line. It's a common line and knowing how lilo.conf works is not something
I intend to detail every time I want to mention how to tweak lilo.conf.
There is plenty of information out there already on how to work with
lilo.conf, and I don't need to repeat that information.
The same goes for xorg.conf. With respect, you repeatedly talk about your
confusion with the xorg.conf file and its format, when people have already
explicitly explained this to you, and have pointed you towards
documentation that goes into great detail about this format. How hard is
it to understand that the basic language of X.org configuration does *not*
change between xorg.conf, xorg.conf.d or anything else? It's the same
thing, and I don't need to go into specifics, because xorg.conf already
includes many examples of how things are done. There are already copious
examples on the internet about how this is done. There are already links
to the files and logs that X.org uses, their formats, and how they work.
The man page clearly explains how the auto configuration works, where it
gets its information and how that information affects things in the
hierarchy of X.org configuration files. I don't need to repeat this
information because it is already out there and it is already easy to
find. I want to illustrate and point out the important elements, not get
bogged down in the parts which are going to be different for every user. I
can't tell you how many times during my time supporting Linux users that
I've heard this, "I tried what was in <Tutorial X> but it didn't work."
Well, why didn't it work? Because they literally tried to put what they
saw into the file. That's pointless. you have to understand what settings
you are trying to change, understand what they do, and then do them only
if your situation demands it. You can't just look at some specific example
and expect it to work. The examples you need to understand how to
configure your own system are already readily available.
On the other hand, perhaps I completely miss the point with what you want.
Maybe I am doing something that is completely unhelpful to you. In that
case, take the recent problem that you had, which you have now solved, and
use that as an illustration of how I should improve my suggestions. I
certainly do want to make my advice more useful and more helpful. So,
since I obviously don't understand what you mean by being specifc, could
you please take your current solution that you have and post your
experience in a complete and specific way as you desire, as an example of
how I should do it? However, I do have a restriction for you. The
information that you provide should be helpful and applicable to the broad
range of people who work and use Slackware, and it should be written in
such a way that everyone can easily determine whether the problem that
they are having will be solved by what you mention. Put another way,
anyone who could benefit from this information should be able to use your
post to clearly and readily solve the problem on their own machine, and it
should not lead them astray --- that is, it should not cause them to do
anything to their machine that will in some way change their machine in a
way that is not essential to solving the problem.
I would be highly interested in such a post, and I'm not being sarcastic
here. I am genuinely interested in how you propose for me to be more
specific given the above constraints.
notbob
>
> here. I am genuinely interested in how you propose for me....
No. You're not.
You have a typical programmer's ego and blather on endlessly, trying
desperately to convince us all how much you know, yet saying
absolutely nothing at all. A specific example would be a starting
point. It works or it doesn't. If not, we can work/discuss from
there. You provide nothing!! I've read every post you've made on
this subject and not a single one has provided me one iota of usable
help. I get more from a piss-in-the-wind google search. Holy crap!!
....a single more-obnoxious-than-me Dan C post gave me more viable
info in one line than all your posts combined. (Thanks, Dan!)
That's ok. Nothing personal. At least you're polite. For that, I
won't KF you for being boringly useless. ;)
nb
Michael Black
> On 2011-09-01, Aaron W. Hsu <arc...@sacrideo.us> wrote:
>> I just did a couple of things on my own machine that relates to this, so I
>> wanted to post this up, since this seems to have become an FAQ around here.
>
> That FAQ would be where!!??
>
The FAQ is actually the question. "Frequently Asked Question". Thus what
we commonly refer to as "FAQs" are actually "Answers to FAQs", though I
can't remember the exact phrasing.
He's now posting the answer to what he perceives as a "FAQ", and yes, it
does seem to have come up a number of times recently.
Michael
notbob
> The FAQ is actually the question. "Frequently Asked Question". Thus what
> we commonly refer to as "FAQs" are actually "Answers to FAQs", though I
> can't remember the exact phrasing.
>
> He's now posting the answer to what he perceives as a "FAQ", and yes, it
> does seem to have come up a number of times recently.
Say what?
Michael Black
> On Thu, 01 Sep 2011 15:50:05 -0400, notbob <not...@nothome.com> wrote:
>
>> I know you have
>> a good heart and are good at generalizing, but you offer less than
>> spit on useable specifics. In Slackware, generalizations are useless!
>
> Here's the problem, your lilo.conf file is not going to look the same as
> mine. Every lilo.conf file in Slackware might be slightly different.
>
> I'm not here to give the basics of operating and configuring Slackware.
I saved your message, didn't pay attention to it, but I've got it for when
I get around to installing the latest Slackware, at which point if I have
problems, the post is bound to make sense. (I'm not saying it doesn't
make sense, only that since it's not a problem at the moment, any answer
is just abstract until the problem arises for me.)
And you're right, why something is happening makes better understanding
than simply giving a template answer to a problem. I know there are times
I've done searches for a problem, and often there is a very strict and
specific answer, that I often have to play with in order to get what I
need. More general background is better, since it applies to multiple
cases.
Michael
Robby Workman
> wanted to post this up, since this seems to have become an FAQ around here.
...
Excellent, Aaron - thanks much for the writeup!
-RW
Mikhail Zotov
notbob <not...@nothome.com> wrote:
> On 2011-09-01, Aaron W. Hsu <arc...@sacrideo.us> wrote:
...
> > With certain drivers, and I'm thinking of Intel here, you *must*
> > have the KMS on in order for the intel drivers to work. On other
> > drivers, like the ATI drivers, you cannot access your consoles
> > unless you disable KMS.
>
> What is KNS?
http://www.x.org/wiki/ModeSetting
http://kernelnewbies.org/Linux_2_6_29#head-e1bab8dc862e3b477cc38d87e8ddc779a66509d1
--
M.
Henrik Carlqvist
From http://en.wikipedia.org/wiki/FAQ
-8<------------------------------
Originally the term FAQ referred to the Frequently Answered Question
itself, and the compilation of questions and answers was known as a FAQ
list or some similar expression. Today FAQ is more frequently used to
refer to the list, and a text consisting of questions and their answers is
often called an FAQ regardless of whether the questions are actually
frequently asked (if asked at all).
-8<------------------------------
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Glyn Millington
Seconded - at least I *begin* to understand what all this stuff is about
:-)
yours from the slow lane .....
Glyn
--
RTFM http://www.tldp.org/index.html
GAFC http://slackbook.org/ The Official Source :-)
STFW http://groups.google.com/groups?hl=en&group=alt.os.linux.slackware
JFGI http://jfgi.us/
goarilla
Please visit the ubuntu forums and never return !
notbob
> Please visit the ubuntu forums and never return !
ESADA!
Ron Gibson
wrote:
>Configuration #2: Lower resolution video modes for graphics drivers that
>require you to have KMS on.
>This one is for those people who may be unfortunate enough to need KMS on,
>but who don't want to try deciphering letters made for ants and their kin.
ROTFLMAO! That was a good one - Best laugh I've had in a week.
--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943