https://wiki.archlinux.org/api.php?action=feedcontributions&user=Rquesada&feedformat=atomArchWiki - User contributions [en]2024-03-28T16:58:32ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=User:Rquesada&diff=54451User:Rquesada2008-12-01T16:30:54Z<p>Rquesada: </p>
<hr />
<div>[http://www.roqz.net Rodolfo Quesada]<br />
<br />
I am a computer science engineer from [http://en.wikipedia.org/wiki/Costa_Rica Costa Rica] specialized in open source software and development, I started using Linux in high school back in 1998, and started the migration from Windows 98 to Linux in 1999 with RedHat 6.1.<br />
<br />
Then in [http://www.itcr.ac.cr/ college] I began toying with Slackware until ArchLinux appeared, currently I have it installed in two desktop computers, a small personal server and my notebook. <br />
<br />
ArchLinux simply rocks, it is amazingly fast and customizable, many people believe that my computers run at about 5Ghz with 16GB RAM when they see them booting in under 20s.</div>Rquesadahttps://wiki.archlinux.org/index.php?title=User:Rquesada&diff=54450User:Rquesada2008-12-01T16:29:21Z<p>Rquesada: New page: [http://www.roqz.net| Rodolfo Quesada] I am a computer science engineer from [http://en.wikipedia.org/wiki/Costa_Rica| Costa Rica] specialized in open source software and development, I s...</p>
<hr />
<div>[http://www.roqz.net| Rodolfo Quesada]<br />
<br />
I am a computer science engineer from [http://en.wikipedia.org/wiki/Costa_Rica| Costa Rica] specialized in open source software and development, I started using Linux in high school back in 1998, and started the migration from Windows 98 to Linux in 1999 with RedHat 6.1.<br />
<br />
Then in [http://www.itcr.ac.cr/| college] I began toying with Slackware until ArchLinux appeared, currently I have it installed in two desktop computers, a small personal server and my notebook. <br />
<br />
ArchLinux simply rocks, it is amazingly fast and customizable, many people believe that my computers run at about 5Ghz with 16GB RAM when they see them booting in under 20s.</div>Rquesadahttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=54417Xorg Input Hotplugging2008-12-01T04:11:27Z<p>Rquesada: /* How cat I get the correct keyboard layout? */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tying X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
== Current XInput status upstream ==<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
== Current status in Arch ==<br />
Input hotplugging is enabled in the 1.5.x series of the xorg-server package. The old 1.4.x versions don't have it enabled, which is not going to change.<br />
<br />
== Requirements ==<br />
To use input hotplugging, the "xf86-input-evdev" package is required. This module handles both keyboard and mouse configuration by default. Other drivers, like "xf86-input-vmmouse" and "xf86-input-synaptics", also contain hotplugging configuration files, which will cause these drivers to be used instead of evdev when your hardware supports them.<br />
Besides installing a supported driver, both dbus and hal have to be running. Add the hal daemon to the DAEMONS array in /etc/rc.conf before anything related to X.Org is started. The hal daemon will load the dbus daemon automatically.<br />
<br />
== Configuration ==<br />
Though input devices are hotplugged, especially keyboards need configuration. Currently there is no way to autoconfigure keymaps for hotplugged keyboards. The default keyboard layout has to be configured in a hal .fdi file. The keymap defaults to a standard US keyboard and is configured in "/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi", a configuration file included in the hal package.<br />
As this file is overwritten on every hal upgrade, this file should be copied to /etc/hal/fdi/policy/. Files placed inside this directory will override the files in /usr/share. The things you want to change are "input.xkb.layout" and "input.xkb.variant". Other options, which are not listed in this file, are "input.xkb.rules", "input.xkb.model" and "input.xkb.options". These options resemble the options you used to put in xorg.conf.<br />
<br />
Other files worth looking at are "10-x11-input.fdi", which configures the default keyboard and mouse driver and "11-x11-synaptics.fdi", which configures your synaptics touchpad in case you have xf86-input-synaptics installed.<br />
<br />
Note that hal needs a restart after changing .fdi files, it will not autodetect any changes. X does not require any restart for this, it will keep listening for signals from hal. Reconfiguring devices that were already added before hal was reconfigured will keep running with the old configuration. To reconfigure these devices, X needs a restart afterall, but removing and adding the devices to the system will also reconfigure them. This is not very useful for laptops with an integrated keyboard or devices that don't support hotplugging (PS/2 mice and keyboards) though.<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
===I configured my mouse and/or keyboard in xorg.conf, but X will not use it===<br />
When input hotplugging is enabled, X will purge any devices setup in xorg.conf that are using the kbd and mouse driver.<br />
<br />
===After upgrading to xorg-server 1.5.3, X appears to freeze, I can no longer press keys or move my mouse===<br />
This is related to the problem above. Install the xf86-input-evdev driver, configure hal to use the kbd/mouse drivers anyways or disable input hotplugging.<br />
<br />
===I don't want this crap, how do I turn it off?===<br />
To disable input hotplugging, add Option "AutoAddDevices" "False" to ServerFlags in /etc/X11/xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
<br />
This will skip devices detected by hal and will use your keyboard/mouse configuration from xorg.conf<br />
<br />
===My mouse is jerky/uncontrollable in SDL apps/games! WTF?===<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
===How can I make mouse button XYZ do FOO?===<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.<br />
<br />
===Arrow / special keys don't work===<br />
If you use Gnome, and you've followed the instructions in this page (ie. you're using the evdev driver for your keyboard), you may experience problems with the special keys on your keyboard. In the Gnome system/preferences/keyboard dialog, set your "keyboard model" to Generic/Evdev-managed keyboard. This should fix most of your problems. At least it fixed mine!<br />
<br />
===Tapping and sliding doesn't work anymore with my touchpad!===<br />
Assuming you have configured X to use the synaptics driver, you have to manually tell it to enable the tapping functions (it wasn't necessary before). See http://bbs.archlinux.org/viewtopic.php?pid=456689#p456689 for a sample configuration file that works.<br />
<br />
===How cat I get the correct keyboard layout (keymap)?===<br />
<br />
Edit the file: "/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi<br />
<br />
And set your keyboard layout (substitute NEW_LAYOUT with your layout):<br />
<br />
<merge key="input.xkb.layout" type="string">NEW_LAYOUT</merge><br />
<br />
If previously something like the following snippet of the xorg.conf would deliver your keyboard layout (Option "XkbLayout" "<xkb_layout>"):<br />
<br />
Section "InputDevice"<br />
Identifier "keyboard"<br />
Driver "kbd"<br />
...<br />
Option "XkbLayout" "<xkb_layout>"<br />
EndSection<br />
<br />
Then in a terminal test the following command:<br />
<br />
setxkbmap <xkb_layout><br />
<br />
With the same layout as previously configured in the xorg.conf, and type some letters to see if it works correctly. A simple trick, instead of editing the policy file is to add a line to your $HOME/.xinitrc like this:<br />
<br />
exec setxkbmap <xkb_layout> &<br />
<br />
That is, assuming that xinit is being used to start X, it will work nice.</div>Rquesadahttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=54416Xorg Input Hotplugging2008-12-01T04:10:59Z<p>Rquesada: /* How cat I get the correct keyboard layout? */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tying X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
== Current XInput status upstream ==<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
== Current status in Arch ==<br />
Input hotplugging is enabled in the 1.5.x series of the xorg-server package. The old 1.4.x versions don't have it enabled, which is not going to change.<br />
<br />
== Requirements ==<br />
To use input hotplugging, the "xf86-input-evdev" package is required. This module handles both keyboard and mouse configuration by default. Other drivers, like "xf86-input-vmmouse" and "xf86-input-synaptics", also contain hotplugging configuration files, which will cause these drivers to be used instead of evdev when your hardware supports them.<br />
Besides installing a supported driver, both dbus and hal have to be running. Add the hal daemon to the DAEMONS array in /etc/rc.conf before anything related to X.Org is started. The hal daemon will load the dbus daemon automatically.<br />
<br />
== Configuration ==<br />
Though input devices are hotplugged, especially keyboards need configuration. Currently there is no way to autoconfigure keymaps for hotplugged keyboards. The default keyboard layout has to be configured in a hal .fdi file. The keymap defaults to a standard US keyboard and is configured in "/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi", a configuration file included in the hal package.<br />
As this file is overwritten on every hal upgrade, this file should be copied to /etc/hal/fdi/policy/. Files placed inside this directory will override the files in /usr/share. The things you want to change are "input.xkb.layout" and "input.xkb.variant". Other options, which are not listed in this file, are "input.xkb.rules", "input.xkb.model" and "input.xkb.options". These options resemble the options you used to put in xorg.conf.<br />
<br />
Other files worth looking at are "10-x11-input.fdi", which configures the default keyboard and mouse driver and "11-x11-synaptics.fdi", which configures your synaptics touchpad in case you have xf86-input-synaptics installed.<br />
<br />
Note that hal needs a restart after changing .fdi files, it will not autodetect any changes. X does not require any restart for this, it will keep listening for signals from hal. Reconfiguring devices that were already added before hal was reconfigured will keep running with the old configuration. To reconfigure these devices, X needs a restart afterall, but removing and adding the devices to the system will also reconfigure them. This is not very useful for laptops with an integrated keyboard or devices that don't support hotplugging (PS/2 mice and keyboards) though.<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
===I configured my mouse and/or keyboard in xorg.conf, but X will not use it===<br />
When input hotplugging is enabled, X will purge any devices setup in xorg.conf that are using the kbd and mouse driver.<br />
<br />
===After upgrading to xorg-server 1.5.3, X appears to freeze, I can no longer press keys or move my mouse===<br />
This is related to the problem above. Install the xf86-input-evdev driver, configure hal to use the kbd/mouse drivers anyways or disable input hotplugging.<br />
<br />
===I don't want this crap, how do I turn it off?===<br />
To disable input hotplugging, add Option "AutoAddDevices" "False" to ServerFlags in /etc/X11/xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
<br />
This will skip devices detected by hal and will use your keyboard/mouse configuration from xorg.conf<br />
<br />
===My mouse is jerky/uncontrollable in SDL apps/games! WTF?===<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
===How can I make mouse button XYZ do FOO?===<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.<br />
<br />
===Arrow / special keys don't work===<br />
If you use Gnome, and you've followed the instructions in this page (ie. you're using the evdev driver for your keyboard), you may experience problems with the special keys on your keyboard. In the Gnome system/preferences/keyboard dialog, set your "keyboard model" to Generic/Evdev-managed keyboard. This should fix most of your problems. At least it fixed mine!<br />
<br />
===Tapping and sliding doesn't work anymore with my touchpad!===<br />
Assuming you have configured X to use the synaptics driver, you have to manually tell it to enable the tapping functions (it wasn't necessary before). See http://bbs.archlinux.org/viewtopic.php?pid=456689#p456689 for a sample configuration file that works.<br />
<br />
===How cat I get the correct keyboard layout?===<br />
<br />
Edit the file: "/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi<br />
<br />
And set your keyboard layout (substitute NEW_LAYOUT with your layout):<br />
<br />
<merge key="input.xkb.layout" type="string">NEW_LAYOUT</merge><br />
<br />
If previously something like the following snippet of the xorg.conf would deliver your keyboard layout (Option "XkbLayout" "<xkb_layout>"):<br />
<br />
Section "InputDevice"<br />
Identifier "keyboard"<br />
Driver "kbd"<br />
...<br />
Option "XkbLayout" "<xkb_layout>"<br />
EndSection<br />
<br />
Then in a terminal test the following command:<br />
<br />
setxkbmap <xkb_layout><br />
<br />
With the same layout as previously configured in the xorg.conf, and type some letters to see if it works correctly. A simple trick, instead of editing the policy file is to add a line to your $HOME/.xinitrc like this:<br />
<br />
exec setxkbmap <xkb_layout> &<br />
<br />
That is, assuming that xinit is being used to start X, it will work nice.</div>Rquesadahttps://wiki.archlinux.org/index.php?title=Xorg&diff=54415Xorg2008-12-01T03:53:16Z<p>Rquesada: /* Keyboard Settings */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|Dansk|Xorg (Dansk)}}<br />
{{i18n_entry|English|Xorg}}<br />
{{i18n_entry|Ελληνικά|Xorg (Ελληνικά)}}<br />
{{i18n_entry|Español|Configurando Xorg (Español)}}<br />
{{i18n_entry|Polski|Xorg_(Polski)}}<br />
{{i18n_entry|Русский|Xorg (Русский)}}<br />
{{i18n_entry|Česky|Xorg (Česky)}}<br />
{{i18n_entry|Italiano|Xorg (Italiano)}}<br />
{{i18n_entry|简体中文|Xorg (简体中文)}}<br />
{{i18n_entry|Türkçe|Xorg (Türkçe)}}<br />
{{i18n_links_end}}<br />
<br />
== Introduction ==<br />
<br />
'''Xorg''' is the public, open-source implementation of the X11 X Window System. (See the [http://en.wikipedia.org/wiki/X.Org_Server X.org Wikipedia Article] or [http://wiki.x.org/wiki/ X.org] for details.) Basically, if you want a GUI atop Arch, you will want xorg.<br />
<br />
==Installing Xorg==<br />
<br />
Before beginning, make sure you do the following:<br />
#Make sure that [[pacman]] is configured and refreshed.<br />
#If you are running another X server you can close it now. <code>ctrl+alt+backspace</code><br />
#Make a note about third-party drivers (e.g., nVidia or ATI drivers). <br />
<br />
First let us install the complete 'xorg' group:<br />
<br />
# pacman -S xorg<br />
<br />
The default 'vesa' driver is merely a fallback (not accelerated and doesn't support many resolutions), so you will need a proper video driver too. You can type this command to list all the video drivers available:<br />
<br />
# pacman -Ss xf86-video<br />
<br />
(However, if you have a nvidia card, install the package "nvidia" instead.)<br />
<br />
Look for the appropriate driver for your card and install it with pacman -S. To check your card, if hwd is installed, run:<br />
hwd -s<br />
or run :<br />
lspci | grep "VGA"<br />
<br />
If Xorg installed OK, it's time to make <code>xorg.conf</code><br />
<br />
==Configuring xorg==<br />
<br />
Before you can run xorg, you need to configure it so that it knows about your graphics card, monitor, mouse and keyboard. There are several methods of automating the process:<br />
<br />
===hwd===<br />
<br />
Perhaps the easiest way of getting Xorg up and running quickly is to use <tt>hwd</tt>, a tool written by users in the Arch Linux community. It's basically a hardware-detection tool that has multiple uses, one of which is setting up an X server. Fortunately, hwd is much more streamlined than <code>xorgconf</code> and doesn't require any input at all.<br />
<br />
First, install the <tt>hwd</tt> package:<br />
# pacman -S hwd<br />
<br />
Now simply run the following command as root to generate a default <code>xorg.conf</code> file:<br />
# hwd -xa<br />
<br />
This will overwrite any existing /etc/X11/xorg.conf file with a practical set of defaults, based on what <tt>hwd</tt> detected for your hardware.<br />
<br />
Alternatively, you can generate a sample Xorg config (/etc/X11/xorg.conf.hwd) without overwriting your existing settings. To do so, run <tt>hwd</tt> with the '''-x''' flag instead:<br />
# hwd -x<br />
<br />
Sample result:<br />
/etc/X11/xorg.conf.ati<br />
/etc/X11/xorg.conf.vesa<br />
<br />
Your sample file(s) ready, rename 'xorg.conf'.<br />
If unsure first try 'vesa' (default).<br />
<br />
To use the sample config(s), you must manually rename it. Sample:<br />
# mv /etc/X11/xorg.conf.vesa /etc/X11/xorg.conf<br />
<br />
AD: In my experience hwd creates XF86Config-4 file and if there is not xorg.conf present Xorg uses it automatically.<br />
<br />
===xorgconfig===<br />
<br />
To start up <tt>xorgconfig</tt>:<br />
<br />
# xorgconfig<br />
<br />
or<br />
<br />
# xorgcfg -textmode<br />
<br />
These will generate a new <tt>xorg.conf</tt>.<br />
<br />
Answer the questions, and the program will make the file for you.<br />
This program is not really good but it's a start, and you can fill in special stuff manually afterwards.<br />
<br />
===Xorg -configure===<br />
You can also use<br />
# Xorg -configure<br />
or<br />
# X -configure<br />
<br />
===nvidia-xconfig===<br />
nVidia users can also use<br />
# nvidia-xconfig<br />
when they have official nvidia drivers [[NVIDIA|installed]].<br />
<br />
Comment the line<br />
<br />
Load "type1"<br />
<br />
in the Module section since recent versions of xorg-server do not include the type1 font module (completely replaced by freetype).<br />
<br />
==Editing xorg.conf==<br />
<br />
You may wish to edit the config after it's been generated. To open in your favourite text-editor, such as Vim (you need root privileges):<br />
<br />
# vim /etc/X11/xorg.conf<br />
<br />
or use Xorg Configuration toolkit:<br />
<br />
# xorgcfg -textmode<br />
<br />
If you want to set up mouse wheel support, see [[Get All Mouse Buttons Working]].<br />
<br />
===Monitor Settings===<br />
<br />
Depending on your hardware, Xorg may fail to detect your monitor capabilities correctly, or you may simply wish to use a lower resolution than your monitor is capable of. You might want to look up the following values in your monitor's manual before setting them.<br />
The following settings are specified in the Monitor section:<br />
<br />
====Horizontal Sync====<br />
<br />
HorizSync 28-64<br />
<br />
====Refresh Rate====<br />
<br />
VertRefresh 60<br />
<br />
The following are specified in the Screen section:<br />
<br />
====Color Depth====<br />
<br />
Depth 24<br />
<br />
====Resolution====<br />
<br />
Modes "1280x1024" "1024x768" "800x600"<br />
<br />
====Multi-monitor setups====<br />
<br />
The easiest way to achieve a working multi-monitor setup is using xrandr after X starts. First, run (from any account):<br />
<br />
xrandr -q<br />
<br />
This will list all your available video outputs, with some information about them. Assume your output names are VGA-0, DVI-0 and S-video. Then, to merge screens connected to DVI-0 and VGA-0 outputs, you just need to run:<br />
<br />
xrandr --output DVI-0 --right-of VGA-0<br />
<br />
If this command works for you, just add it to your [[xinitrc]] file.<br />
<br />
=== Keyboard Settings ===<br />
<br />
Xorg may fail to detect your keyboard correctly. This might give problems with your keyboard layout or keyboard model not being set correctly.<br />
<br />
To see a full list of keyboard models, layouts, variants and options, open:<br />
<br />
/usr/share/X11/xkb/rules/xorg.lst<br />
<br />
==== Input hotplugging with xorg-server 1.5 ====<br />
<br />
Normally xorg-server 1.5 tries to configure your keyboard using the new xf86-input-evdev driver (which in turn uses dbus and HAL) instead of using your configuration settings in xorg.conf. This may result in an undesired auto-configured keyboard layout. The fastest workaround is to disable the hotplugging mechanism by adding the following section to your xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
<br />
{{Box Note|This will disable Xorg hotplugging for '''all''' input devices and revert to the same behavior as xorg-server 1.4.}}<br />
<br />
For more information see [[Xorg input hotplugging]].<br />
<br />
==== Keyboard Layout ====<br />
<br />
{{Box Note|If you are using the xorg-server 1.5 series, please see the keyboard layout section in [[Xorg input hotplugging]].}}<br />
<br />
To change the keyboard layout, use the XkbLayout option in the keyboard InputDevice section. For example, if you have a keyboard with English layout:<br />
<br />
Option "XkbLayout" "gb"<br />
<br />
To be able to easily switch keyboard layouts, for example between a US and a Swedish layout use this instead:<br />
<br />
Option "XkbLayout" "us, se"<br />
Option "XkbOptions" "grp:caps_toggle"<br />
<br />
This makes your Caps Lock key switch between the different layouts. This is mainly useful if you run don't run a Desktop Environment which takes care of keyboard layouts for you.<br />
<br />
==== Keyboard Model ====<br />
<br />
To change the keyboard model, use the XkbModel option in the keyboard <br />
InputDevice section. For example, if you have a Microsoft Wireless Multimedia Keyboard:<br />
<br />
Option "XkbModel" "microsoftmult"<br />
<br />
==== Problem with your Apple Keyboard? ====<br />
More information can be found [[Apple Keyboard|here]].<br />
<br />
===Display Size/DPI===<br />
<br />
In order to get correct sizing for fonts, the display size must be set for your desired DPI.<br />
<br />
<br />
One way to set it up is to pass an argument directly to the X (Xorg) binary.<br><br />
In <code>/etc/X11/xinit/xserverrc</code> add the "-dpi 96" part as follows:<br />
exec /usr/bin/X -nolisten tcp '''-dpi 96'''<br />
<br />
<br />
Alternatively, going back to the <code>/etc/X11/xorg.conf</code> file, in the section <code>"Monitor"</code> put in your display size in mm:<br />
<br />
Section "Monitor"<br />
...<br />
DisplaySize 336 252 # 96 DPI @ 1280x960<br />
...<br />
EndSection<br />
<br />
<br />
The formula for calculating the DisplaySize values is Width (in inches) x 25.4 / DPI and Height (in inches) x 25.4 / DPI. If you're running Xorg with a resolution of 1024x768 and want a DPI of 96, use 1024 x 25.4 / 96 and 768 x 25.4 / 96. Round numbers down. (xorg.conf expects width/height specifications to be given in milimeters. There are 25.4 milimeters per inch, thus the need to multiply by 25.4)<br />
<br />
# calc: (x|y)pixels * 25.4 / dpi<br />
# DisplaySize 168 126 # 96 DPI @ 640x480<br />
# DisplaySize 210 157 # 96 DPI @ 800x600<br />
# DisplaySize 269 201 # 96 DPI @ 1024x768<br />
# DisplaySize 302 227 # 96 DPI @ 1152x864<br />
# DisplaySize 336 252 # 96 DPI @ 1280x960<br />
# DisplaySize 336 210 # 96 DPI @ 1280x800 (non 4:3 aspect)<br />
# DisplaySize 339 271 # 96 DPI @ 1280x1024 (non 4:3 aspect)<br />
# DisplaySize 370 277 # 96 DPI @ 1400x1050<br />
# DisplaySize 380 238 # 96 DPI @ 1440x900<br />
# DisplaySize 420 315 # 96 DPI @ 1600x1200<br />
# DisplaySize 444 277 # 96 DPI @ 1680x1050<br />
# DisplaySize 506 315 # 96 DPI @ 1920x1200 (non 4:3 aspect)<br />
<br />
<br />
In case X ignores your DisplaySize setting ([https://bugs.freedesktop.org/show_bug.cgi?id=9758 known bug]) add the following line in the Device section.<br />
Option "NoDDC" "true"<br />
<br />
For nVidia drivers you may have to disable automatic detection of DPI to set it manually. There is also an easier way to set DPI on these cards. Either or both of the following lines can be set in the device section for your nVidia card.<br />
<br />
Option "UseEdidDpi" "false"<br />
Option "DPI" "96 x 96"<br />
<br />
<br />
Results can be checked by issuing the following command, which should return 96x96 dots per inch if you set DPI @ 96.<br />
<br />
$ xdpyinfo | grep -B1 dot<br />
<br />
===Proprietary Drivers===<br />
<br />
If you wish to use third-party graphics drivers, do check that the X server runs OK first. Xorg should run smoothly without official drivers, which are typically needed only for advanced features such as 3D-accelerated rendering for games, dual-screen setups, and TV-out. Refer to the [[NVIDIA]] and [[ATI]] wikis for help with driver installation.<br />
<br />
===Fonts===<br />
<br />
There some tips for setting up fonts in [[Xorg Font Configuration]].<br />
<br />
=== Sample Xorg.conf Files ===<br />
Anyone who has an Xorg.conf file written up that works, go ahead and post a link to it here for others to look at! Please don't inline the entire conf file; upload it somewhere else and link. Thanks!<br />
* raskolnikov (via unichrome and synaptics drivers): http://athanatos.free.fr/Arch/xorg.conf<br />
* Mr.Elendig (nvidia with composite and "stuff") http://arch.har-ikkje.net/configs/etc/X11/xorg.conf<br />
<br />
==Running Xorg==<br />
<br />
This is done simply by typing:<br />
<br />
$ startx<br />
or<br />
$ xinit<br />
The default X environment is rather bare, and you will typically seek to install window managers or desktop environments to supplement X. <br />
<br />
To test the config file you have created:<br />
<br />
$ X -config ''<your config file>''<br />
<br />
If a problem occurs, then view the log at <tt>/var/log/Xorg.0.log</tt>. Be on the lookout for any lines beginning with ''(EE)'' which represent errors, and also ''(WW)'' which are warnings that could indicate other issues.<br />
<br />
'''*Please Note*'''<br />
Using startx or xinit requires a ''[[xinitrc | ~/.xinitrc ]]'' file, so that X knows what to run when it starts. Your best option is to copy ''/etc/skel/.xinitrc'' to your home directory and edit it. Comment out the 'exec' lines you don't want, and add or uncomment one for the WM you want to use. If you are using GNOME it is best to start GNOME through gdm to avoid HAL permission problems.<br />
<br />
In addition, you can also install twm and xterm (via pacman), which will be used as a fallback if ~/.xinitrc does not exist (as stated in /etc/X11/xinit/xinitrc).<br />
<br />
==X startup (/usr/bin/startx) tweaking==<br />
For X's option reference see<br />
<br />
$ man Xserver<br />
<br />
The following options have to be appended to the variable "defaultserverargs" in the /usr/bin/startx file:<br />
<br />
<br />
* prevent X from listening on tcp:<br />
-nolisten tcp<br />
'''Note:''' this seems to be the default option now in <code>/etc/X11/xinit/xserverrc</code><br />
<br />
<br />
* getting rid of the gray weave pattern while X is starting and let X set a black root window:<br><br />
-br<br />
'''Note:''' there seems to be no need for that in recent releases of Xorg.<br />
<br />
<br />
* enable deferred glyph loading for 16 bit fonts:<br />
-deferglyphs 16<br />
<br />
<br />
Note: If you start X with kdm, the startx script does not seem to be executed. X options must be appended to the variable "ServerCmd" in the /opt/kde/share/config/kdm/kdmrc file. By default kdm options are<br />
<br />
ServerCmd=/usr/bin/X -br -nolisten tcp<br />
<br />
== Changes with modular Xorg ==<br />
<br />
=== Most Common Packages ===<br />
<br />
Make sure you install drivers for mouse, keyboard and videocard. For mouse and keyboard, '''xf86-input-keyboard''' and '''xf86-input-mouse''' should get installed. Other '''xf86-input-*''' packages are available for different input devices.<br />
<br />
For the videocard, find out which driver is required and install the right '''xf86-video-*''' package. ATI and Nvidia users may wish to install the non-free drivers for their hardware instead ([[NVIDIA]], [[ATI]]).<br />
<br />
To install all drivers in one run, the '''xorg-input-drivers''' and '''xorg-video-drivers''' are available.<br />
<br />
=== OpenGL 3D Acceleration ===<br />
<br />
X.Org 7.0 on Arch Linux uses a modular design for mesa, the OpenGL rendering system. Several implementations are available:<br />
* libgl-dri: Open-source DRI OpenGL implementation. Falls back to software rendering when no DRI driver is installed<br />
* some other driver providing libGL (ati, nvidia)<br />
<br />
When pacman installs an application that needs mesa, it will install one of these packages. To be sure about the right library for your setup, install the library you want prior to installing Xorg. Installing the right package afterwards is also possible, though this gives some dependency errors sometimes, which can be ignored with the -d switch.<br />
<br />
=== Glxgears and Glxinfo ===<br />
<br />
These apps are included in the mesa package.<br />
<br />
=== Changed paths (and configuration) ===<br />
<br />
'''See this entry for additional upgrade info:''' http://www.archlinux.org/blog/2006/01/02/how-to-upgrade-xorg/<br />
<br />
Modular X.Org 7 installs everything in <code>/usr</code>, where the older versions installed in <code>/usr/X11R6</code>. Several configuration files need updates:<br />
* ''/etc/X11/xorg.conf''<br />
** Fontpaths live in /usr/share/fonts now<br />
** RGB database is in /usr/share/X11/rgb<br />
** module path is /usr/lib/xorg/modules<br />
<br />
Also note that some X configuration tools might stop working. The easiest way to configure X.org is by installing the correct driver packages and running ''Xorg -configure'', which results in a <code>/root/xorg.conf.new</code> which only needs modification in the resolutions, mouse configuration and keyboard layouts.<br />
<br />
Some packages have hard-coded references to <code>/usr/X11R6</code>. These packages need fixing. In the meantime, look what packages install files in <code>/usr/X11R6</code>, uninstall those, make a symlink from <code>/usr</code> to <code>/usr/X11R6</code> and reinstall the affected packages. Another option is to move the contents of <code>/usr/X11R6</code> to <code>/usr</code> and make the symlink.<br />
<br />
Or you can just add a second module path via <code/>ModulePath "/usr/X11R6/lib/modules"</code> <br />
This works e.g. for Nvidia 76.76<br />
<br />
== Desktop Effects ==<br />
To set up and enable fancy desktop effects, see the [[Compiz Fusion]] article.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Xorg "can't see" the resolutions your monitor supports ===<br />
I found myself in a situation where if I used one of my monitors (a gnr ts902), Xorg would only present me with the options 640x480 and 320x480 which of course was less than I desired. After a lot of research I found through read-edid (in [[AUR]]) that part of my EDID was corrupt and so I could only read my HorizSync with read-edid. This fortunately was enough and after adding the right HorizSync line to the xorg.conf's Monitor section (I didn't have to add VertRefresh) I restarted X to see the right resolution :)<br />
<br />
note: I'm not sure if<br />
<br />
Option "ModeValidation" "NoEdidModes"<br />
Option "UseEdid" "false"<br />
<br />
in Device section of xorg.conf are needed as well; too lazy now to test without them :)<br />
<br />
=== Keyboard Problems ===<br />
<br />
Auto-generated xorg.conf files may cause you problems. If you cannot get to tty1 by holding CTRL-ALT and pressing F1 or cannot get the £ sign for gb people, check to see if the following entries are in your /etc/X11/xorg.conf:<br />
<br />
Option "XkbLayout" "uk" #"uk" is not a real layout, look in /usr/share/X11/xkb/symbols/ for a list of real ones.<br />
Option "XkbRules" "xfree86" #this should be "xorg"<br />
Option "XkbVariant" "nodeadkeys" #This line is also known to cause the problems described, try commenting it out.<br />
<br />
To switch between layouts with Alt+Shift:<br />
Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"<br />
<br />
===A Quick Fix for the Bitstream-Vera Conflict===<br />
If you see a message that ttf-bitstream-vera conflicts with xorg:<br />
#Exit the pacman session by answering no.<br />
#Run <code>pacman -Rd xorg</code><br />
#Run <code>pacman -Syu</code><br />
#Run <code>pacman -S xorg</code><br />
#Update your paths in /etc/X11/xorg.conf<br />
<br />
===A Quick Fix for file conflicts in /usr/include===<br />
If you see messages about file conflicts in /usr/include/X11 and /usr/include/GL:<br />
#Run <code>rm /usr/include/{GL,X11}</code><br />
#Run <code>pacman -Su</code><br />
The symlinked directories removed by this operation are replaced by real directories in the new xorg package, causing these file conflicts to appear.<br />
<br />
=== libgl-dri conflicts ===<br />
<br />
(Note below, that nvidia-legacy has been replaced by nvidia-71xx or nvidia-96xx. See [[NVIDIA | here]] for further details of which driver to use.)<br />
<br />
If you get a message similar to:<br />
:: libgl-dri conflicts with nvidia-legacy. Remove nvidia-legacy? [Y/n]<br />
this is due to the multiple OpenGL implementations explained in the OpenGL section above - pacman is attempting to install libgl-dri to satisfy this dependency, but also trying to upgrade your existing video driver, and they conflict. To solve, try:<br />
<br />
* Updating your video driver before a full system update: <br />
# pacman -S nvidia-legacy<br />
# pacman -Syu<br />
<br />
Or, if that doesn't work,<br />
* Remove your existing video driver, do the update, then reinstall your driver:<br />
# pacman -Rd nvidia-legacy<br />
# pacman -Syu<br />
# pacman -S nvidia-legacy<br />
:: nvidia-legacy conflicts with libgl-dri. Remove libgl-dri? [Y/n] '''Y'''<br />
<br />
=== Mouse wheel not working ===<br />
The "Auto" protocol doesn't seem to work properly in Xorg 7 any more. In the InputDevice section for your mouse, change:<br />
Option "Protocol" "auto"<br />
to<br />
Option "Protocol" "IMPS/2"<br />
or<br />
Option "Protocol" "ExplorerPS/2"<br />
<br />
=== Extra mouse buttons not working ===<br />
USB Mice users should read [[Get_All_Mouse_Buttons_Working]].<br />
<br />
Intellimouse (ExplorerPS/2) users might find their scroll and side buttons aren't behaving as they used to. Previously xorg.conf needed:<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "6 7"<br />
and users also had to run xmodmap to get the side buttons working with a command like:<br />
xmodmap -e "pointer = 1 2 3 6 7 4 5"<br />
Now xmodmap is no longer required. Instead, make xorg.conf look like this:<br />
Option "Buttons" "5"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
and the side buttons on a 7-button Intellimouse will work like they used to, without needing to run xmodmap.<br />
<br />
===Keyboard problems===<br />
Some keyboard layouts have changed. I wondered why:<br />
* I wasn't able to Ctrl+Alt+Fx to switch to console<br />
* I wasn't able to use layouts<br />
The problem was that the ''sk_qwerty'' layout doesn't exist anymore. I had to replace<br />
Option "XkbLayout" "us,sk_qwerty"<br />
with<br />
Option "XkbLayout" "us,sk"<br />
Option "XkbVariant" ",qwerty"<br />
<br />
Another thing to look for if your keyboard isn't properly functioning is the XkbRules option:<br><br />
You'll need to change<br />
Option "XkbRules" "xfree86"<br />
to<br />
Option "XkbRules" "xorg"<br />
<br />
==== AltGR (Compose Key) not working properly ====<br />
<br />
If, after the update, you can't use the AltGr key as expected any more, try adding this to your keyboard section:<br />
Option "XkbOptions" "compose:ralt"<br />
<br />
This is not the correct way to activate the AltGr Key on a German keyboard (for example, to use the '|' and '@' keys on German keyboards).<br />
Just choose a valid keyboard variant for it to work again, for example (the example is for a German keyboard):<br />
Option "XkbLayout" "de"<br />
Option "XkbVariant" "nodeadkeys"<br />
<br />
The solutions above don't work on an Italian keyboard. To activate the AltGr key on an Italian keyboard make sure you have the following lines set up properly:<br />
Driver "kbd"<br />
Option "XkbRules" "xorg"<br />
Option "XkbVariant" ""<br />
<br />
This might still not be enough for a swedish keyboard. Try the above, but with lv3 instead of compose. (Thank you wyvern!)<br />
That is:<br />
Option "XkbLayout" "se"<br />
Option "XkbVariant" "nodeadkeys"<br />
Option "XkbOptions" "lv3:ralt_switch"<br />
<br />
==== Can't set qwerty layouts using the setxkbmap command ====<br />
<br />
After the update, there aren't qwerty layouts as for example sk_qwerty. If you want to switch your present keyboard layout to any qwerty keyboard layout use this command:<br />
$ setxkbmap NAME_OF_THE_LAYOUT qwerty<br />
e.g.: for sk_qwerty use:<br />
$ setxkbmap sk qwerty<br />
<br />
After the update, trying the above command I had this message "Error loading new keyboard description".<br />
I find out that the xserver doesn't have the rights to write, execute, read in the directory /var/tmp<br />
So give the permissions to that directory. Restart the xserver and you will have your deadkeys back!<br />
Don't believe? Try out the code e.g.: it layout<br />
$ setxkbmap -layout it<br />
<br />
==== Setup French Canadian (old ca_enhanced) layout ====<br />
<br />
With Xorg7, "ca_enhanced" is no more. You have to do a little trick to get the same layout that you are used to:<br />
Switch the old:<br />
Option "XkbLayout" "ca_enhanced"<br />
To:<br />
Option "XkbLayout" "ca"<br />
Option "XkbVariant" "fr"<br />
<br />
It will be similar with other layout, I presume. You can refer to Gentoo HowTo there: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml<br />
<br />
<br />
<br />
=== Missing libraries ===<br />
* '''Help! I get an error message running my favourite app saying "libXsomething" doesn't exist!'''<br><br />
In most cases, all you need to do is take the name of the library (eg libXau.so.1), convert it all to lowercase, remove the extension, and pacman for it:<br />
# pacman -S libxau<br />
<br />
This will install the library you're missing, and all will be well again!<br />
<br />
=== Some packages fail to build and complain about missing X11 includes ===<br />
<br />
Just reinstall the packages xproto and libx11, even if they are already installed.<br />
<br />
=== Unable to load font '(null)' ===<br />
* '''Some programs don't work and say unable to load font `(null)'.'''<br><br />
These packages would like some extra fonts. Some programs only work with bitmap fonts.<br />
Two major packages with bitmap fonts are available, xorg-fonts-75dpi and xorg-fonts-100dpi. You don't need both; one should be enough. To find out which one would be better in your case, try this:<br />
<br />
$ xdpyinfo | grep resolution<br />
<br />
and grab what is closer to you (75 or 100 instead of XX)<br />
<br />
# pacman -S xorg-fonts-XXdpi<br />
<br />
=== KDE Taskbar/Desktop Icons Broken ===<br />
* '''KDE taskbar doesn't work and the desktop icons disappear'''<br><br />
Install the packages libxcomposite and libxss. It will be fine.<br />
<br />
# pacman -S libxcomposite libxss<br />
<br />
=== Updating from testing version to extra (missing files) ===<br />
<br />
If you've updated from Xorg 7 in testing to Xorg 7 in extra and are finding that many files seem to be missing (including startx, /usr/share/X11/rgb.txt, and others), you may have lost many files due to the xorg-clients package splitting from a single package into many smaller sub packages. <br><br />
<br />
You need to reinstall all the packages that are dependencies of xorg-clients:<br />
# pacman -S xorg-apps xorg-font-utils xorg-res-utils xorg-server-utils \<br />
xorg-twm xorg-utils xorg-xauth xorg-xdm xorg-xfs xorg-xfwp \<br />
xorg-xinit xorg-xkb-utils xorg-xsm<br />
<br />
This should fix the problem.<br />
<br />
=== Problem with MIME types in various desktop environments ===<br />
<br />
If you noticed icons missing and can't click-open files in desktop environments, add the following lines to /etc/profile or your preferred init script and reboot.<br />
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share<br />
export XDG_DATA_DIRS<br />
<br />
=== DRI stops working with Matrox cards ===<br />
<br />
If you use a Matrox card and DRI stops working after upgrading to xorg7, try adding the line<br />
Option "OldDmaInit" "On"<br />
to the Device section that references the video card in xorg.conf.<br />
<br />
=== Cannot start any clients under Xephyr ===<br />
<br />
The client connections are rejected by the X server's security mechanism, you can find a complete explanation and solution in [http://wiki.debian.org/XStrikeForce/FAQ#howtoxnest].<br />
<br />
=== Cannot start X clients as root using "su" ===<br />
<br />
If you're getting "Client is not authorized to connect to server", try adding the line <br />
<br />
session optional pam_xauth.so<br />
<br />
to the file /etc/pam.d/su. <br />
pam_xauth will properly set environment variables and handle xauth keys.<br />
<br />
== Links ==<br />
See also:<br />
<br />
* [[Enabling a DM]]<br />
* [[Start X at boot]]<br />
* [[Xorg Font Configuration]]<br />
* Proprietary Video Drivers<br />
** [[ATI]]<br />
** [[NVIDIA]]<br />
* [[Desktop Environment]]<br />
** [[KDE]]<br />
** [[GNOME]]<br />
** [[Xfce]]<br />
** [[Enlightenment]]<br />
** [[Fluxbox]]<br />
** [[Openbox]]<br />
** [[LXDE]]<br />
== External Links ==<br />
<br />
* [http://en.wikipedia.org/wiki/X.Org_Server X.org Wikipedia Article]<br />
* [http://wiki.x.org/wiki/ X.org]<br />
* [http://archux.com/page/installing-and-setting-xorg Installing and setting up Xorg]</div>Rquesadahttps://wiki.archlinux.org/index.php?title=Xorg_Input_Hotplugging&diff=54414Xorg Input Hotplugging2008-12-01T03:50:41Z<p>Rquesada: /* FAQ/Troubleshooting */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Xorg_input_hotplugging}}<br />
{{i18n_links_end}}<br />
<br />
<br />
== Rationale ==<br />
Historically, the X server would be used on terminals, and later on, on desktop computers. On those machines the X server would start once, upon when it would configure itself with regards to its rarely changing input and output peripherals: monitors, video cards, keyboards, mice, tablets, touchscreens...<br />
<br />
Following the advent of mobile computing, a given computer often see its peripherals changing, while it is running. Obviously, restarting the whole OS is not an option, so the kernel guys accomodated for this in implementing device hotplugging. Since devices are exposed to userspace as device nodes in /dev, the highly configurable udev was born in lieu of devfs (or manually maintained /dev).<br />
<br />
Still, the X server is having issues with this, as it probes devices and opens device files on startup. If the device was absent on X startup, it will remain unknown to X. If the device file was present at X startup, and the file disappears (e.g the device is disconnected), the file handle is lost, thus the device will remain unknown, even if replugged and the same device node is recreated (which is easy to do with udev). This is also true for gpm, a mouse daemon for VTs.<br />
<br />
To overcome this issue, notably with the most widely encountered case that is a laptop user with a touchpad and an external mouse, the kernel emulates a PS/2 mouse with all events coming from any mouse connected to the system. The device file is always present, and resides at /dev/input/mice (or /dev/psaux). This has a number of issues. First, being an emulated PS/2 mouse, the protocol is predefined, and has inherent limitations, overcome by various proprietary extensions, like ImPS/2 and ExplorerPS/2. What's more, events coming from all the mice have to be translated to this protocol, and thus non-understood or translatable events are lost or misunderstood. What's more, it is impossible to have such an emulated device work in absolute coordinates since it would make no sense (as events can come from many devices). Also, relative button events (like for a wheel, where there's no press/release events) have to be a wheel axis in the PS/2 protocol, and you can't have much of them. Furthermore, all mice will have the same settings with regards to speed or button orders as set via e.g xset of xmodmap. This is an issue when you have a laser mouse which just flies across the screen when another one moves like a turtle.<br />
<br />
In the end, it doesn't matter for many users out there who just want a mouse with a wheel and three buttons. Yet there is an increasing market of keyboards, mice and other special input devices with various extra buttons. While hardcore users will argue that this is useless and that everybody should use tiling WMs and screw the mouse, it is increasingly useful to perform many common tasks with '''either''' the keyboard '''or''' the mouse, depending on what you're '''currently''' doing.<br />
<br />
The solution to enable all those extra buttons is to use the X input event driver (or evdev). Trouble is, this driver must have access to the exact event node matching your device, which resides in /dev/input/event*, and not some funky workaround device emulator sink. So evdev will work, but only if the device is plugged in at X startup, and never unplugged afterwards. <br />
<br />
Instead of writing a routine monitoring /dev or listening to kernel events, which would have the additional nasty effect of tying X hotplugging to linux, the X devs decided to leverage the power of the HAL daemon. hald essentially builds a uniform database of the current hardware available on the system (together with any information it can deduce like device type and so on), and updates it live according to kernel events, while recensing device files. Now, thanks to the hard work of hald and dbus devs, all that X has to do is connect to hald (this is done via dbus), monitor device (dis)appearance, and take action if the device is relevant to X.<br />
<br />
== Current XInput status upstream ==<br />
There's no other way to have '''real''' hotplugging. This is indeed what one might relate to XRandR for its display hotplugging ability, and it's called XInput. It is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.<br />
It is posing a number of problems, because many pieces of software (xmodmap, GTK...) are unaware of how to handle multiple devices, and them disappearing or reappearing.<br />
<br />
== Current status in Arch ==<br />
Input hotplugging is enabled in the 1.5.x series of the xorg-server package. The old 1.4.x versions don't have it enabled, which is not going to change.<br />
<br />
== Requirements ==<br />
To use input hotplugging, the "xf86-input-evdev" package is required. This module handles both keyboard and mouse configuration by default. Other drivers, like "xf86-input-vmmouse" and "xf86-input-synaptics", also contain hotplugging configuration files, which will cause these drivers to be used instead of evdev when your hardware supports them.<br />
Besides installing a supported driver, both dbus and hal have to be running. Add the hal daemon to the DAEMONS array in /etc/rc.conf before anything related to X.Org is started. The hal daemon will load the dbus daemon automatically.<br />
<br />
== Configuration ==<br />
Though input devices are hotplugged, especially keyboards need configuration. Currently there is no way to autoconfigure keymaps for hotplugged keyboards. The default keyboard layout has to be configured in a hal .fdi file. The keymap defaults to a standard US keyboard and is configured in "/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi", a configuration file included in the hal package.<br />
As this file is overwritten on every hal upgrade, this file should be copied to /etc/hal/fdi/policy/. Files placed inside this directory will override the files in /usr/share. The things you want to change are "input.xkb.layout" and "input.xkb.variant". Other options, which are not listed in this file, are "input.xkb.rules", "input.xkb.model" and "input.xkb.options". These options resemble the options you used to put in xorg.conf.<br />
<br />
Other files worth looking at are "10-x11-input.fdi", which configures the default keyboard and mouse driver and "11-x11-synaptics.fdi", which configures your synaptics touchpad in case you have xf86-input-synaptics installed.<br />
<br />
Note that hal needs a restart after changing .fdi files, it will not autodetect any changes. X does not require any restart for this, it will keep listening for signals from hal. Reconfiguring devices that were already added before hal was reconfigured will keep running with the old configuration. To reconfigure these devices, X needs a restart afterall, but removing and adding the devices to the system will also reconfigure them. This is not very useful for laptops with an integrated keyboard or devices that don't support hotplugging (PS/2 mice and keyboards) though.<br />
<br />
== FAQ/Troubleshooting ==<br />
<br />
===I configured my mouse and/or keyboard in xorg.conf, but X will not use it===<br />
When input hotplugging is enabled, X will purge any devices setup in xorg.conf that are using the kbd and mouse driver.<br />
<br />
===After upgrading to xorg-server 1.5.3, X appears to freeze, I can no longer press keys or move my mouse===<br />
This is related to the problem above. Install the xf86-input-evdev driver, configure hal to use the kbd/mouse drivers anyways or disable input hotplugging.<br />
<br />
===I don't want this crap, how do I turn it off?===<br />
To disable input hotplugging, add Option "AutoAddDevices" "False" to ServerFlags in /etc/X11/xorg.conf:<br />
<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
<br />
This will skip devices detected by hal and will use your keyboard/mouse configuration from xorg.conf<br />
<br />
===My mouse is jerky/uncontrollable in SDL apps/games! WTF?===<br />
This was a long time since I started a game. It seems that with evdev, DGA gets broken in SDL: mouse jumps and moves down-right all the time.<br />
<br />
To fix this you have to either set a var:<br />
<br />
export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
which is sufficient for Neverball, or add this to your xorg.conf:<br />
<br />
Section "Module"<br />
...<br />
SubSection "extmod"<br />
Option "omit xfree86-dga" # don't initialise the DGA extension<br />
EndSubSection<br />
...<br />
EndSection<br />
<br />
which is mandatory for e.g Doom III<br />
<br />
===How can I make mouse button XYZ do FOO?===<br />
Well, currently it has to be implemented in the application (like e.g firefox next/previous) or in the WM. Configurable WM like compiz can do something with mouse buttons too. The sad thing is that this is per-button number and not per-device. <br />
There are also some interesting apps like [http://www.bedroomlan.org/~alexios/coding_evrouter.html EvRouter] but the kernel event design makes it so that events are not 'consumed' by applications reading /dev/input/event0, thus catching an event won't prevent the event to be passed to X (which will produce a ButtonXYZ event, which results in a LeftClick if not handled specially by the application). Or I missed something somewhere.<br />
<br />
===Arrow / special keys don't work===<br />
If you use Gnome, and you've followed the instructions in this page (ie. you're using the evdev driver for your keyboard), you may experience problems with the special keys on your keyboard. In the Gnome system/preferences/keyboard dialog, set your "keyboard model" to Generic/Evdev-managed keyboard. This should fix most of your problems. At least it fixed mine!<br />
<br />
===Tapping and sliding doesn't work anymore with my touchpad!===<br />
Assuming you have configured X to use the synaptics driver, you have to manually tell it to enable the tapping functions (it wasn't necessary before). See http://bbs.archlinux.org/viewtopic.php?pid=456689#p456689 for a sample configuration file that works.<br />
<br />
===How cat I get the correct keyboard layout?===<br />
<br />
If previously something like the following snippet of the xorg.conf would deliver your keyboard layout (Option "XkbLayout" "<xkb_layout>"):<br />
<br />
Section "InputDevice"<br />
Identifier "keyboard"<br />
Driver "kbd"<br />
...<br />
Option "XkbLayout" "<xkb_layout>"<br />
EndSection<br />
<br />
Then in a terminal test the following command:<br />
<br />
setxkbmap <xkb_layout><br />
<br />
With the same layout as previously configured in the xorg.conf, and type some letters to see if it works correctly. A simple trick is to add a line to your $HOME/.xinitrc like this:<br />
<br />
exec setxkbmap <xkb_layout> &<br />
<br />
That is, assuming that xinit is being used to start X, it will work nice.</div>Rquesadahttps://wiki.archlinux.org/index.php?title=Acer_Aspire_3624_WXMi&diff=37831Acer Aspire 3624 WXMi2008-02-29T14:24:19Z<p>Rquesada: </p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{stub}}<br />
<br />
Article based on [[Acer Aspire 1652 ZWLMi]], which in turn was based on [[Acer Aspire 1691 WLMi]]. <br />
<br />
This notebook was a very economic solution, at about $500 two years ago that still works like a charm. The combination of a economic processor such as the Celeron M 380 and a lightweight Linux distribution such as Arch Linux with a minimalist usability focus like using the fluxbox window manager, all of that makes a great deal of this laptop, currently used for programming in many environments and paradigms, music listening, video watching and the all-time classic web surfing and mail checking. <br />
<br />
Currently using a custom mainline kernel with no modules other than the additional madwifi Atheros drivers, expecting to use the ath5k drivers in the 2.6.25 kernel. Also, the hard disk uses three partitions, a root partition, an encrypted home partition and the swap. <br />
<br />
Battery life currently tops 2 hours when just coding or writing with WiFi enabled and about 1:20 while watching h.264 video files. <br />
<br />
The modem and PCMCIA slot have never been used. <br />
<br />
=Specifications=<br />
<br />
==Components==<br />
* '''Processor:''' Intel Celeron M 380 1.6Ghz, 1MB L2 Cache (Differences with a Pentium M: No SpeedStep frequency scaling and half the L2 cache).<br />
* '''Memory:''' Hynix 2x256MB 400Mhz DDR2 SO-DIMM in Dual Data Rate configuration<br />
** Upgraded to 2x1GB Corsair Value Select 1GB 533Mhz DDR2 SO-DIMM (VS1GSDS533D2).<br />
* '''Hard Disk Drive:''' Hitachi 80GB (HTS421280H9AT00) UDMA/100, PATA<br />
** It seems that the biggest PATA 2.5" hard disk drive widely available is the 250GB Western Digital WD2500BEVE.<br />
* '''Optical Drive:''' Pioneer DVD-RW (DVR-K16RA) UDMA/33, PATA<br />
* '''Wireless NIC:''' Atheros AR2413 (It is installed as a Mini PCI card, supposedly can be upgraded to 802.11n in the future).<br />
* '''Ethernet NIC:''' Realtek 8139<br />
* '''Screen:''' 14.1" glossy surface 1280x800 native resolution. <br />
* '''Touchpad:''' Synaptics<br />
* '''Bluetooth:''' No. But it has a nice front unused button for it. <br />
<br />
==lspci==<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)<br />
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)<br />
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)<br />
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)<br />
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)<br />
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03)<br />
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)<br />
06:05.0 Ethernet controller: Atheros Communications, Inc. AR2413 802.11bg NIC (rev 01)<br />
06:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)<br />
06:09.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01)<br />
</pre><br />
<br />
=Installing Arch Linux=<br />
<br />
Installed two times with the standard CD, about two years ago (2006) and a fresh reinstall in November 2007, the upgraded the system with pacman -Syu and added all my favorite packages. <br />
<br />
=Kernel=<br />
Currently using a customized configuration 2.6.23.1 kernel with support only for the included hardware and some extra USB stuff. <br />
<br />
=Power Management=<br />
<br />
Turning it off when not used and DPMS screen shutdown in the xorg.conf file. Have not used suspend to disk, boot time is very fast, about 20 seconds from button press to login. <br />
<br />
=Xorg=<br />
<br />
The intel driver doesn't like to set the DPI according to forced physical dimensions, so there is a trick to get the desired DPI (81x81). In the user's ~/.bashrc the following line was added:<br />
<br />
<pre><br />
alias xinit='xinit -- -dpi 81'<br />
</pre><br />
<br />
So that when issuing the xinit command, it will always use that DPI resolution.<br />
<br />
==DPMS screen shutdown==<br />
<br />
The following /etc/X11/xorg.conf snippet adds a DPMS screen shutdown after 5 minutes of no activity. <br />
<br />
<pre><br />
Section "Monitor"<br />
...<br />
Option "DPMS" "true"<br />
...<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
...<br />
Option "OffTime" "5" <br />
...<br />
EndSection<br />
</pre></div>Rquesadahttps://wiki.archlinux.org/index.php?title=Acer_Aspire_3624_WXMi&diff=37830Acer Aspire 3624 WXMi2008-02-29T14:19:52Z<p>Rquesada: New page: Category:Laptops (English) Category:HOWTOs (English) {{stub}} Article based on Acer Aspire 1652 ZWLMi, which in turn was based on Acer Aspire 1691 WLMi. This notebook wa...</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{stub}}<br />
<br />
Article based on [[Acer Aspire 1652 ZWLMi]], which in turn was based on [[Acer Aspire 1691 WLMi]]. <br />
<br />
This notebook was a very economic solution, at about $500 two years ago that still works like a charm. The combination of a economic processor such as the Celeron M 380 and a lightweight Linux distribution such as Arch Linux makes a great deal, currently used for programming in many environments and paradigms, video watching and the all-time classic web surfing. <br />
<br />
Currently using a custom mainline kernel with no modules other than the additional madwifi Atheros drivers, expecting to use the ath5k drivers in the 2.6.25 kernel. Also, the hard disk uses three partitions, a root partition, an encrypted home partition and the swap. <br />
<br />
Battery life currently tops 2 hours when just coding or writing with WiFi enabled and about 1:20 while watching h.264 video files. <br />
<br />
The modem and PCMCIA slot have never been used. <br />
<br />
=Specifications=<br />
<br />
==Components==<br />
* '''Processor:''' Intel Celeron M 380 1.6Ghz, 1MB L2 Cache (Differences with a Pentium M: No SpeedStep frequency scaling and half the L2 cache).<br />
* '''Memory:''' Hynix 2x256MB 400Mhz DDR2 SO-DIMM in Dual Data Rate configuration<br />
** Upgraded to 2x1GB Corsair Value Select 1GB 533Mhz DDR2 SO-DIMM (VS1GSDS533D2).<br />
* '''Hard Disk Drive:''' Hitachi 80GB (HTS421280H9AT00) UDMA/100, PATA<br />
** It seems that the biggest PATA 2.5" hard disk drive widely available is the 250GB Western Digital WD2500BEVE.<br />
* '''Optical Drive:''' Pioneer DVD-RW (DVR-K16RA) UDMA/33, PATA<br />
* '''Wireless NIC:''' Atheros AR2413 (It is installed as a Mini PCI card, supposedly can be upgraded to 802.11n in the future).<br />
* '''Ethernet NIC:''' Realtek 8139<br />
* '''Screen:''' 14.1" glossy surface 1280x800 native resolution. <br />
* '''Touchpad:''' Synaptics<br />
* '''Bluetooth:''' No. But it has a nice front unused button for it. <br />
<br />
==lspci==<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)<br />
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)<br />
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)<br />
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)<br />
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)<br />
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)<br />
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)<br />
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)<br />
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)<br />
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)<br />
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03)<br />
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)<br />
06:05.0 Ethernet controller: Atheros Communications, Inc. AR2413 802.11bg NIC (rev 01)<br />
06:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)<br />
06:09.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01)<br />
</pre><br />
<br />
=Installing Arch Linux=<br />
<br />
Installed two times with the standard CD, about two years ago (2006) and a fresh reinstall in November 2007, the upgraded the system with pacman -Syu and added all my favorite packages. <br />
<br />
=Kernel=<br />
Currently using a customized configuration 2.6.23.1 kernel with support only for the included hardware and some extra USB stuff. <br />
<br />
=Power Management=<br />
<br />
Turning it off when not used and DPMS screen shutdown in the xorg.conf file. Have not used suspend to disk, boot time is very fast, about 20 seconds from button press to login. <br />
<br />
=Xorg=<br />
<br />
The intel driver doesn't like to set the DPI according to forced physical dimensions, so there is a trick to get the desired DPI (81x81). In the user's ~/.bashrc the following line was added:<br />
<br />
<pre><br />
alias xinit='xinit -- -dpi 81'<br />
</pre><br />
<br />
So that when issuing the xinit command, it will always use that DPI resolution.<br />
<br />
==DPMS screen shutdown==<br />
<br />
The following /etc/X11/xorg.conf snippet adds a DPMS screen shutdown after 5 minutes of no activity. <br />
<br />
<pre><br />
Section "Monitor"<br />
...<br />
Option "DPMS" "true"<br />
...<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
...<br />
Option "OffTime" "5" <br />
...<br />
EndSection<br />
</pre></div>Rquesada