Forums » Linux
How to edit your XF86Config file correctly
For some odd reason the Readmes that come with most Linux drivers all mention "make your changes... while not in X..." but they never mention how to actually do this. Hopefully this lil post will help clarify the process some.
It is best to follow this process for editing any driver-level file in Linux. Editing from within X (i.e. editing with KWrite) can produce some really nasty results.
----------------------------------------
1. Log out and hit CTRL+ALT+1 or, depending on your flavor, CTRL+ALT+F1 to switch to a console.
2. Log in as root.
3. # init 3 (to kill the X server softly)
4. # emacs /etc/X11/XF86Config-4 (substitute the path for wherever your XF86Config-4 file is)...(vi can also be used to edit but Emacs is a lot friendlier)
5. Make your changes using normal keystrokes (i.e. arrows move around in the document, delete button deletes, etc.).
7. Hit CTRL+X, then hit S and then Y (this saves the buffer).
8. Hit CTRL+X, then CTRL+C to exit Emacs.
9. # init 5 (to start the X server again normally)
If X doesn't start properly then something has gone wrong either in your config or in the process of the load. Look at /var/log/XFree86.0.log for clues as to where it went wrong.
It is best to follow this process for editing any driver-level file in Linux. Editing from within X (i.e. editing with KWrite) can produce some really nasty results.
----------------------------------------
1. Log out and hit CTRL+ALT+1 or, depending on your flavor, CTRL+ALT+F1 to switch to a console.
2. Log in as root.
3. # init 3 (to kill the X server softly)
4. # emacs /etc/X11/XF86Config-4 (substitute the path for wherever your XF86Config-4 file is)...(vi can also be used to edit but Emacs is a lot friendlier)
5. Make your changes using normal keystrokes (i.e. arrows move around in the document, delete button deletes, etc.).
7. Hit CTRL+X, then hit S and then Y (this saves the buffer).
8. Hit CTRL+X, then CTRL+C to exit Emacs.
9. # init 5 (to start the X server again normally)
If X doesn't start properly then something has gone wrong either in your config or in the process of the load. Look at /var/log/XFree86.0.log for clues as to where it went wrong.
Firstly, never do this without setting default boot to console. I used to have TONS of AGP problems, and I would have to kill stuff off via ssh before I could do anything. Before I had another comp available, I had to restart, but when it restarted into graphical mode, it broke! I was reduced to using the gentoo install CD to fix it. So make sure to set default initlevel to 3. Also, I reccommend vim over emacs. It's much less complex. And editing in X has 0 results, because the XFConfig isn't sampled until X is restarted. Duh.
Sorry to bump an old thread, but I just noticed soemthing you mentioned in your post, roguelazer...
Emacs does have an X interface, but it also has a console version. If you call Emacs outside of an X environment it automatically runs in console mode.
That's why you see the switch to init 3 before emacs is called, then the switch back to init 5 to check the functionality of X. You'd likely never need to reboot doing it this way, as you can just keep flipping between init modes until you get X where you want it to be, so you probably don't need to change your default init (I don't).
Additionally, whether vi or Emacs is "friendlier" or "less complex" is a pure matter of opinion. For quick edits I still use vi but for anything large or lengthy I've found the "natural" editing features of Emacs to be very useful. Hence, Emacs has become my most commonly used editor, as it has for several people I know.
Emacs does have an X interface, but it also has a console version. If you call Emacs outside of an X environment it automatically runs in console mode.
That's why you see the switch to init 3 before emacs is called, then the switch back to init 5 to check the functionality of X. You'd likely never need to reboot doing it this way, as you can just keep flipping between init modes until you get X where you want it to be, so you probably don't need to change your default init (I don't).
Additionally, whether vi or Emacs is "friendlier" or "less complex" is a pure matter of opinion. For quick edits I still use vi but for anything large or lengthy I've found the "natural" editing features of Emacs to be very useful. Hence, Emacs has become my most commonly used editor, as it has for several people I know.
Yeah, but the problem is that if you mess up your XF86 config and have it in "init 5" (you use either RedHat or Mandrake...), you'll be booting into X when you hard reboot. And back into X. And on and on until you insert your Knoppix or Gnoppix disk.
You should never need to reboot just to tweak your X. That's what the init levels are for. If you start X and it's all hosed up just switch out to another console and call init 3 again. Do your edits and call init 5. Repeat as necessary, and get your X where you want it before you ever reboot.
Obviously you've never used accelerated drivers much. Especially old ones. The first switch from nv to nvidia has a tendency to crash the system.
/sigh
I knew you'd eventually pop off with something like this.
Allow me to retort.
Obviously, you've never learned how to rescue your Linux box without rebooting, or you've been using gimp flavors of Linux or gotten your hands on some off-mainstream and crappy drivers that don't allow you to do these things.
I've been working with Linux for several years now, and I have never, in all that time, on all those distros and across all that hardware, had X trash so bad that I had to reboot my system. Even if it did I've always backed up my X config before I've tweaked on it so it wouldn't have been any more work than renaming the backup file and starting X again, or at the most loading into a failsafe mode and doing it from there before calling a new init level.
Just because YOU can't get it to work doesn't mean it doesn't work.
If you disagree with me so much, then how about you write your own guide, your way? Then you won't have to worry about mine.
I knew you'd eventually pop off with something like this.
Allow me to retort.
Obviously, you've never learned how to rescue your Linux box without rebooting, or you've been using gimp flavors of Linux or gotten your hands on some off-mainstream and crappy drivers that don't allow you to do these things.
I've been working with Linux for several years now, and I have never, in all that time, on all those distros and across all that hardware, had X trash so bad that I had to reboot my system. Even if it did I've always backed up my X config before I've tweaked on it so it wouldn't have been any more work than renaming the backup file and starting X again, or at the most loading into a failsafe mode and doing it from there before calling a new init level.
Just because YOU can't get it to work doesn't mean it doesn't work.
If you disagree with me so much, then how about you write your own guide, your way? Then you won't have to worry about mine.
Why do you have the init 3 and init 5 stuff? On my debian and my gentoo system, the starting of X isn't controlled by an init level...
As for that, well, sometimes I don't have another system handy to ssh in and reboot the computer. And if your entire comp locks up (keyboard stops responding to everything, little lights all go off and don't go back on), there's not much to do...
Besides, you bumped the thread. :D
As for that, well, sometimes I don't have another system handy to ssh in and reboot the computer. And if your entire comp locks up (keyboard stops responding to everything, little lights all go off and don't go back on), there's not much to do...
Besides, you bumped the thread. :D
Just FYI: C-z doesn't exit emacs. It suspends it, leaving the process in memory as a stopped job. To exit emacs, do: C-x C-c
While I'm at it, to save do: C-x C-s
While I'm at it, to save do: C-x C-s
Actually, we're both off ont he emacs shortcuts.
You're right about C-z only suspending it. I never realized that.
However, C-x C-s only saves it, it doesn't close it.
From the Emacs manual:
C-x C-c
Exit (Close emacs)
roguelazer:
You may not be used to working with init levels but they are present in Debian just like they are in all Unix/Linux flavors. I verified that Debian 3 (Woody) has them and they operate identical to the levels in RH/MDK. If calling init 5 or 3 doesn't bring up your X server then you probably didn't install X at build time. If you did install X at build time and init 5 or init 3 don't start X then your inits are freaky. heh
http://www.linuxman.com.cy/rute/node35.html for more information.
You're right about C-z only suspending it. I never realized that.
However, C-x C-s only saves it, it doesn't close it.
From the Emacs manual:
C-x C-c
Exit (Close emacs)
roguelazer:
You may not be used to working with init levels but they are present in Debian just like they are in all Unix/Linux flavors. I verified that Debian 3 (Woody) has them and they operate identical to the levels in RH/MDK. If calling init 5 or 3 doesn't bring up your X server then you probably didn't install X at build time. If you did install X at build time and init 5 or init 3 don't start X then your inits are freaky. heh
http://www.linuxman.com.cy/rute/node35.html for more information.
Debian != Gentoo
Gentoo uses the /etc/init.d directory and rc-update to control all boot processes. rc-update del xdm, for example, removes X from boot (XDM is the name of the /etc/init.d entry, but it controls all X startup). rc-update add xdm default re-inserts it.
Emacs. Bah. Gimme vi[m] any day.
However, you are probably right for Debian. I don't know because I've never had to exit the XF86Config file for Debian.
Gentoo uses the /etc/init.d directory and rc-update to control all boot processes. rc-update del xdm, for example, removes X from boot (XDM is the name of the /etc/init.d entry, but it controls all X startup). rc-update add xdm default re-inserts it.
Emacs. Bah. Gimme vi[m] any day.
However, you are probably right for Debian. I don't know because I've never had to exit the XF86Config file for Debian.
slackware is superior. You will be assimilated.
/me agrees with romikq
though slackware has a problem with stability...
the problem is that it is soo stable and it never slows down no matter how much you load up the hard drive... so next thing you know you've got a folder titled /Lesbian_porn that is 100gb and you have do put it all on cds so you can have space back on your computer... thank god for 120gb hd's
though slackware has a problem with stability...
the problem is that it is soo stable and it never slows down no matter how much you load up the hard drive... so next thing you know you've got a folder titled /Lesbian_porn that is 100gb and you have do put it all on cds so you can have space back on your computer... thank god for 120gb hd's