Hook’s Humble Homepage

Less is more in modern X Or How I Enabled Hotplugging in X, Survived and Got an Extra Treat

Attention

This article is deprecated. Your X should ideally work out-of-the-box and if you need to tweak anything read the newer instructions on tweaking X11 directly via UDev

In these modern times it is said that in most cases X does not even need xorg.conf to exist in order to work properly. These days due to HAL, Evdev and RandR devices that X needs can be detected and configured automatically. No more resetting X and fiddling about to get the external projector working or cursing why the mouse will not come back when it is un- and re-plugged.

Herein you should find both a HOWTO and short explanations as to why and how some options are to be used and what the caveats are, based on personal experience when migrating.

Software needed

These are the versions that I used and short explanations as to why these are the minimum versions required for this magic to work:

  • xorg-server 1.5.3 (with the AllowEmptyInput by default patch) – needed to solve a problem with the keyboard (included in the X11 Gentoo overlay)
  • xf86-input-evdev 2.1 – needed for some advanced settings like ButtonMapping (I had to manually bump this ebuild)
  • libXrandr 1.2, randrproto 1.2 and xrandr 1.2 – needed for monitor hotplugging (in the official Gentoo tree)

Before the big change

For those faint of heart, without interest or who just plainly do not want to bother, just skip this part.

I used to have a big (yes, handwritten!) xorg.conf settings file that was mostly written using arcane man and HOWTO knowledge – all neatly commented, so I would not get (too) lost in the whole mess:

# **********************************************************************
# DRI Section
# **********************************************************************

Section "dri"
# Access to OpenGL ICD is allowed for all users:
Mode    0666
EndSection

# **********************************************************************
# Module section -- this  section  is used to specify
# which dynamically loadable modules to load.
# **********************************************************************

Section "Module"

    Load    "dbe"                # Double buffer extension
    Load    "vbe"                # za VESA za vsak slučaj
    Load    "extmod"
    Load    "bitmap"
    Load    "ddc"                # da monitor sam pove kakšno resolucijo hoče
    Load    "type1"
    Load    "freetype"

    Load    "glx"                # libglx.a
    Load    "dri"                # libdri.a
    Load    "drm"
    ### Dodano, ker tako hoče Acer Aspire 5024 HOWTO
    Load    "xtrap"
    Load    "record"

EndSection

# **********************************************************************
# Files section.  This allows default font and rgb paths to be set
# **********************************************************************

Section "Files"

       # The module search path.  The default path is shown here.

       FontPath    "/usr/share/fonts/misc:unscaled"
       FontPath    "/usr/share/fonts/Type1"
       FontPath    "/usr/share/fonts/TTF"
       FontPath    "/usr/share/fonts/corefonts"
       FontPath    "/usr/share/fonts/freefonts"
       FontPath    "/usr/share/fonts/terminus"
       FontPath    "/usr/share/fonts/ttf-bitstream-vera"
       FontPath    "/usr/share/fonts/unifont"
       FontPath    "/usr/share/fonts/75dpi:unscaled"
       FontPath    "/usr/share/fonts/100dpi:unscaled"
       FontPath    "/usr/share/fonts/artwiz-aleczapka-en"
       FontPath    "/usr/local/share/fonts"

EndSection


# **********************************************************************
# Server flags section.
# **********************************************************************

Section "ServerFlags"


EndSection

# **********************************************************************
# Input devices
# **********************************************************************

# **********************************************************************
# Core keyboard's InputDevice section
# **********************************************************************

Section "InputDevice"

       Identifier    "Keyboard1"
       Driver        "kbd"

       # For most OSs the protocol can be omitted (it defaults to "Standard").
       # When using XQUEUE (only for SVR3 and SVR4, but not Solaris),
       # uncomment the following line.

       #    Option    "Protocol"    "Xqueue"

       Option    "AutoRepeat"    "500 30"

       # Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
       #    Option    "Xleds"    "1 2 3"

       #    Option    "LeftAlt"    "Meta"
       #    Option    "RightAlt"    "ModeShift"

       #    Option    "XkbDisable"

       Option    "XkbRules"    "xorg"
       Option    "XkbModel"    "pc105"
       Option    "XkbLayout"    "si"

EndSection


# **********************************************************************
# Core Pointer's InputDevice section
# **********************************************************************

Section "InputDevice"

# Identifier and driver

    ### Logitech USB
    Identifier    "Mouse"
       Driver    "evdev"
       Option    "Name"            "Logitech Optical USB Mouse"
       Option    "Emulate3Buttons"
       Option    "Resultion"        "800"

EndSection

Section "InputDevice"
       Identifier    "Synaptics"
       Driver        "synaptics"
       Option    "Device"        "/dev/input/mouse0"
       Option    "Protocol"        "auto-dev"
       Option    "LeftEdge"        "1700"
       Option    "RightEdge"        "5300"
       Option    "TopEdge"        "1700"
       Option    "BottomEdge"        "4200"
       Option    "FingerLow"        "25"
       Option    "FingerHigh"        "30"
       Option    "MaxTapTime"        "180"
       Option    "MaxTapMove"        "220"
       Option    "VertScrollDelta"    "100"
       Option    "MinSpeed"        "0.09"
       Option    "MaxSpeed"        "0.18"
       Option    "AccelFactor"        "0.0015"
       Option    "SHMConfig"        "true"
       Option    "Repeater"        "/dev/ps2mouse"
       ### KSynaptics prav da rab UseShm
       Option    "UseShm"        "true"
EndSection

# **********************************************************************
# Monitor section
# **********************************************************************

# Any number of monitor sections may be present

Section "Monitor"
       Identifier    "InternalLCD"
       Option        "DPMS"    "true"
       DisplaySize    331 207

EndSection


# **********************************************************************
# Graphics device section
# **********************************************************************


Section "Device"
    Identifier    "ATI Radeon X600"
    VendorName    "ATI Technologies Inc"
       BoardName    "unknown"

       Driver        "radeon"

       Option        "MonitorLayout"        "LVDS,CRT"
       Option        "MergedFB"        "true"
       Option        "CRT2HSync"        "30-86"
       Option        "CRT2VRefresh"        "50-120"
       Option        "MetaModes"        "1280x800-1280x1024 1280x800-1024x768 1280x800-800x600"
       Option        "MergedNonRectangular"    "true"

       Option        "FBTexPercent"        "50"         # Nej bi poštelal Gart, da dela, kot je treba
       Option        "AGPMode"        "4"
       Option        "AGPFastWrite"        "true"
       Option        "ColorTiling"        "true"
       Option        "EnablePageFlip"    "false"        ### mogoče pomaga, če izklopim pri stabilnosti – „man radeon“ pravi, da v redkih primerih nagaja
       Option        "RenderAccel"        "false"        ### „man radeon“ pravi, da še ni podprt za novejše čipe od 9200 (moj je novejši)
       Option        "AccelMethod"        "XAA"         # XAA je starejši, bolj stabilen za 3D, EXA pa novejši in boljši za Render ter Composite
    #    Option        "XaaNoOffScreenPixmaps"            ### mogoče to kej pomaga
       Option        "DDCMode"        "true"        ### da naj monitor sam pove resolucijo

    # enable (partial) PowerPlay features
       Option        "DynamicClocks"        "true"        ### mogoče kej pomaga pri 3D, če ga izklopim – „man radeon“ pravi, da bi lahko

EndSection

# **********************************************************************
# Screen sections
# **********************************************************************
Section "Screen"
       Identifier    "Screen0"
       Device        "ATI Radeon X600"
       Monitor        "InternalLCD"
       DefaultDepth    24

       Subsection    "Display"
           Depth        24
              Modes        "1280x800" "1024x768" "800x600"
              Virtual        1280 800
              ViewPort    0 0
           EndSubsection
EndSection

# **********************************************************************
# ServerLayout sections.
# **********************************************************************

Section "ServerLayout"

       Identifier    "Server Layout"

       Screen        "Screen0"

       InputDevice    "Keyboard1"    "CoreKeyboard"
       InputDevice    "Mouse"        "AlwaysCore"
       InputDevice    "Synaptics"    "CorePointer"

EndSection

Section "Extensions"
       Option "Composite" "Enable"
EndSection

The big downsides of this are no real hotplugging of input and output devices and … well … the general mess of it all.

Getting rid of the unneeded

First on there is a bit of cleaning up to do.

As already said X nowadays is able to work without a single line in xorg.conf or it even existing. But there are still occasions where the user would like to have an option differently then the defaults.

In my settings – and this can be probably quite safely applied to most others as well – the following sections were obsolete, as X is able to load automatically what it needs:

  • Section "dri"
  • Section "Module"
  • Section "Files"
  • Section "ServerFlags"
  • Section "Extensions"

All these can be safely removed regardless of whether further down the line you want to enable input device and dualhead hotplugging or keep it all static in your xorg.conf. If you later on happen to find an option that you want to set up differently then the defaults (e.g. turn off Composite), consult the man xorg.conf.

Input devices hotplugging

Input device hotplugging is especially useful for laptop owners or those who use systems where mice, keyboards and/or other input devices (e.g. trackballs, drawing tablets, joysticks, etc.) are often being un- and re-plugged while X is running and you would not want to restart X just to get the new device working.

The old way of how X handles input devices was to have it set up in xorg.conf with a device path (e.g. /dev/input/mouse0). This meant that whenever a new device was introduced X had to be restarted.

Things became a bit better with udev and even more so with HAL. Thanks to those two devices that are plugged in while the system is running will get a device path automatically and HAL will know all sorts of useful info about the device (e.g. the manufacturer, model, number of keys, etc.). This also means that when you change the below explained .fdi file you do not need to restart the whole X, but only the HAL daemon in order for changes to be taken into account – even this can be a big plus, when you need a X session to run for a longer time.

With all this modernisation of how devices are handled, one really asks oneself why still let X handle them like in the 1990's. The people at Xorg have also though about this and made a new, smart driver called Evdev that supports all input devices that the Linux kernel does and can communicate with HAL.

Keyboard

Many will not see the point in having a configuration that enables keyboard hotplugging, as most of us (especially laptop owners) use only one keyboard on the same box. But there is more to it then being able to just plug in e.g. and external USB keyboard and start using it the very same moment. There is also the big plus of not having to bother about counting how many keys are on the keyboard and so on if HAL can detect it.

To do so you only need to remove the whole InputDevice section that handles your keyboard and the keyboard line from the ServerLayout section.

E.g. in my case, from xorg.conf I deleted:

Section "InputDevice"

    Identifier    "Keyboard1"
    Driver        "kbd"

    # For most OSs the protocol can be omitted (it defaults to "Standard").
    # When using XQUEUE (only for SVR3 and SVR4, but not Solaris),
    # uncomment the following line.

    #    Option    "Protocol"    "Xqueue"

    Option    "AutoRepeat"    "500 30"

    # Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
    #    Option    "Xleds"    "1 2 3"

    #    Option    "LeftAlt"    "Meta"
    #    Option    "RightAlt"    "ModeShift"

    #    Option    "XkbDisable"

    Option    "XkbRules"    "xorg"
    Option    "XkbModel"    "pc105"
    Option    "XkbLayout"    "si"

EndSection

and

InputDevice    "Keyboard1"    "CoreKeyboard"

Now that these settings are missing, X will not override what HAL detects. If the defaults work for you, you can safely just leave this as it is.

But if you e.g. use a different keyboard layout that you want to associate with a (in my case a specific) keyboard, then you might want to migrate at least some of the previous settings to a .fdi file for HAL to take into account. This file has to reside in the /etc/hal/fdi/policy/ folder and is a simple XML file that can implement all of the chosen driver's options and HAL's recognision patterns.

For example, this is my /etc/hal/fdi/policy/keyboard.fdi:

<?xml version="1.0" encoding="UTF-8"?>
deviceinfo version="0.2">
    <device>
        <match key="info.capabilities" contains="input.keyboard">
        <match key="info.product" contains="AT Translated Set 2 keyboard">
            <merge key="input.x11_driver" type="string">evdev</merge>
            <merge key="input.x11_options.XkbLayout" type="string">si</merge>
        </match>
        </match>
    </device>
</deviceinfo>

The match tags are there for HAL and Evdev to narrow down the search which device to apply the commands in the merge tags. In my case I wanted to enforce this setting for only my integrated keyboard (hence the product line).

In the example you can also see the input.x11_options.XkbLayout line, which does exactly the same as did the Option "XkbLayout" line in xorg.conf. You can implement any of the Options that the driver you use (e.g. Evdev) or X itself supports, as long as you put it in a line like: MyOptionValue (change the MyOption and MyOptionValue accordingly, of course!). Also worth noting here is that irrelevant of what the driver manual says the type is, for HAL you should always chose type="string" – that means also when the Options are boolean (i.e. only true or false; on or off) or numeric, you should still write it as string in the .fdi file.

The only two lines that are a must is a match line to select the device(s) and the input.x11_driver line to select the driver.

It is possible to associate a device by different means, but I prefer using the product identifier, because a) when hotplugging a device it tends to get associated with a different device path, but its identifier stays the same and b) if I happen to get my hands on e.g. another of the same device, I would like the same rules to apply, but perhaps not when the device is different (e.g. different keyboard).

Information needed to associate an .fdi file contents with a device can be found by running hal-device in a treminal emulator. The above .fdi example bases on the hal-device output below:

35: udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input'
input.keymap.data = { 'e025:help', 'e026:setup', 'e027:battery', 'e029:switchvideomode',
'e033:euro', 'e034:dollar', 'e055:wlan', 'e056:wlan', 'e057:bluetooth', 'e058:bluetooth', '
e071:f22', 'e072:f22', 'e073:prog2', 'e074:prog1' } (string list)
input.xkb.rules = 'base'  (string)
linux.sysfs_path = '/sys/class/input/input3/event3'  (string)
info.category = 'input'  (string)
info.subsystem = 'input'  (string)
input.xkb.model = 'evdev'  (string)
info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port'  (string)
info.capabilities = { 'input', 'input.keyboard', 'input.keypad', 'input.keys', 'input.key
map', 'button' } (string list)
info.product = 'AT Translated Set 2 keyboard'  (string)
input.xkb.layout = 'us'  (string)
info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input'   (string)
input.xkb.variant = ''  (string)
input.device = '/dev/input/event3'  (string)
input.x11_driver = 'evdev'  (string)
input.product = 'AT Translated Set 2 keyboard'  (string)
linux.hotplug_type = 2  (0x2)  (int)
input.x11_options.XkbLayout = 'si'  (string)
linux.subsystem = 'input'  (string)
linux.device_file = '/dev/input/event3'  (string)
info.addons.singleton = { 'hald-addon-input' } (string list)
info.callouts.add = { 'hal-setup-keymap' } (string list)
input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port'  (string)

As you can see I included one of the info.capabilities strings and the info.product string to let HAL and Evdev know which keyboard(s) exactly it should apply the rules in the keyboard.fdi. You can also see the results of the .fdi file, as the output shows input.x11_options.XkbLayout = 'si' (string) – meaning that this setting overrides the input.xkb.layout = 'us' (string) default.

More information on which options are avaliable can be found on the driver's man page (man evdev) and there is an example .fdi file online as well.

The above on writing .fdi files also applies to other input devices below.

Touchpad

When it comes to touchpads the same reasons why to switch to HAL handling the devices apply as for keyboards.

Also the whole logic of writing a .fdi file and removing the static config from xorg.conf applies.

Just remove the whole InputDevice section that has the Synatpics driver and the appropriate line in ServerLayout.

E.g. remove this:

Section "InputDevice"
    Identifier    "Synaptics"
    Driver        "synaptics"
    Option    "Device"        "/dev/input/mouse0"
    Option    "Protocol"        "auto-dev"
    Option    "LeftEdge"        "1700"
    Option    "RightEdge"        "5300"
    Option    "TopEdge"        "1700"
    Option    "BottomEdge"        "4200"
    Option    "FingerLow"        "25"
    Option    "FingerHigh"        "30"
    Option    "MaxTapTime"        "180"
    Option    "MaxTapMove"        "220"
    Option    "VertScrollDelta"    "100"
    Option    "MinSpeed"        "0.09"
    Option    "MaxSpeed"        "0.18"
    Option    "AccelFactor"        "0.0015"
    Option    "SHMConfig"        "true"
    Option    "Repeater"        "/dev/ps2mouse"
    ### KSynaptics prav da rab UseShm
    Option    "UseShm"        "true"
EndSection

and

    InputDevice    "Synaptics"    "CorePointer"

And then write a .fdi file with the appropriate options you find from the hal-device output and the Synaptics manual page (man synaptics). The defaults are quite sane, so try starting with bare minimum (the device and the driver) and then start adding options that you find useful.

For example, here is my /etc/hal/fdi/policy/synaptics.fdi:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
    <device>
    <match key="info.capabilities" contains="input.touchpad">
    <match key="info.product" contains="SynPS/2 Synaptics TouchPad">
        <merge key="input.x11_driver" type="string">synaptics</merge>
        <merge key="input.x11_options.TapButton1" type="string">1</merge>
        <merge key="input.x11_options.TapButton2" type="string">2</merge>
        <merge key="input.x11_options.TapButton3" type="string">3</merge>
        <merge key="input.x11_options.VertTwoFingerScroll" type="string">false</merge>
        <merge key="input.x11_options.HorizTwoFingerScroll" type="string">false</merge>
        <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
    </match>
    </match>
    </device>
</deviceinfo>

As you can see there are a few Options set in the above .fdi example. Notice that the right way to do it is to first test the defaults and then set up individual Options only if you want behaviour other then the default.

External mouse

Again, there is not much new to tell about how to migrate the external mouse. It's pretty much the same as with above, only you should consult the Evdev man page (man evdev) for options.

In my case, this is the relevant hal-device output:

1: udi = '/org/freedesktop/Hal/devices/usb_device_46d_c521_noserial_if1_logicaldev_input'
info.addons.singleton = { 'hald-addon-input' } (string list)
linux.sysfs_path = '/sys/class/input/input10/event6'  (string)
input.originating_device = '/org/freedesktop/Hal/devices/usb_device_46d_c521_noserial_if1
'  (string)
info.subsystem = 'input'  (string)
info.parent = '/org/freedesktop/Hal/devices/usb_device_46d_c521_noserial_if1'  (string)
info.product = 'Logitech USB Receiver'  (string)
info.udi = '/org/freedesktop/Hal/devices/usb_device_46d_c521_noserial_if1_logicaldev_inpu
t'  (string)
input.xkb.rules = 'base'  (string)
input.xkb.model = 'evdev'  (string)
linux.hotplug_type = 2  (0x2)  (int)
input.xkb.layout = 'us'  (string)
linux.subsystem = 'input'  (string)
input.xkb.variant = ''  (string)
info.capabilities = { 'input', 'input.keys', 'button' } (string list)
input.device = '/dev/input/event6'  (string)
linux.device_file = '/dev/input/event6'  (string)
input.x11_driver = 'evdev'  (string)
info.category = 'input'  (string)
input.product = 'Logitech USB Receiver'  (string)

2: udi = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_logicaldev_inp
ut'
linux.sysfs_path = '/sys/class/input/input9/event5'  (string)
input.originating_device = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial'  (string)
info.subsystem = 'input'  (string)
info.parent = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial'  (string)
info.product = 'Logitech USB Receiver'  (string)
info.udi = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_logicaldev_input'  (string)
linux.hotplug_type = 2  (0x2)  (int)
linux.subsystem = 'input'  (string)
info.capabilities = { 'input', 'input.mouse' } (string list)
input.device = '/dev/input/event5'  (string)
linux.device_file = '/dev/input/event5'  (string)
input.x11_driver = 'evdev'  (string)
info.category = 'input'  (string)
input.product = 'Logitech USB Receiver'  (string)
input.x11_options.ButtonMapping = '1 0 3 4 5 6 7 8 2'  (string)

As you can see, with this specific mouse (Logitech NX80 and similar) the same device is associated for both keyboard and mouse movement. I imagine this is because Logitech did not bother to make different receivers for different products. So you have to make sure to associate the .fdi file settings with the input.mouse. Also Logitech did not bother to remove the button 2 (i.e. "middle mouse button") support on its NX80, although this button is physically missing due to the two-speed vertical wheel where you (mechanically) change speeds by pressing the wheel down.

In the example above in the last line you can also see the ButtonMapping option set – this is because on my system I have already written an .fdi file for the mouse and HAL has already taken into account the ButtonMapping options set as you can see below.

Example /etc/hal/fdi/policy/usb-mouse-receiver.fdi:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
    <device>
        <match key="info.capabilities" contains="input.mouse">
        <match key="info.product" contains="Logitech USB Receiver">
            <merge key="input.x11_driver" type="string">evdev</merge>
            <merge key="input.x11_options.ButtonMapping" type="string">1 0 3 4 5 6 7 8 2</merge>
        </match>
        </match>
    </device>
</deviceinfo>

Now you can safely remove the mouse settings from the xorg.conf file:

Section "InputDevice"

# Identifier and driver

### Logitech USB
    Identifier    "Mouse"
    Driver    "evdev"
    Option    "Name"            "Logitech Optical USB Mouse"
    Option    "Resultion"        "1000"
    Option    "ButtonMappint"        "1 0 3 4 5 6 7 8 2"
EndSection

and

    InputDevice    "Mouse"        "AlwaysCore"

As you can see we did not migrate the Resolution option, because HAL guesses it correctly.

Output devices hotplugging

There are other cases where output device hotplugging makes sense, but the most common (and the one that also applies to me) is when the computer or laptop has a dual-head graphics card and the user would like to use more then one display to show his desktop(s).

Here I will walk you through how to enable clone mode – which is the most used by laptop users, who want to reproduce the video output they see on their internal LCD displays also on an external device (e.g. a projector). Other modes take only a quick look at man xorg.conf and in some cases also the man page of the graphics driver you use (a list of those can be found at the very end of man xorg.conf) and writing those settings into xorg.conf.

For our undertaking RandR defaults are pretty much enough and all it takes is to remove the obsolete lines from xorg.conf and let RandR work its magic by itself.

From the Device section:

    Option        "MonitorLayout"        "LVDS,CRT"
    Option        "MergedFB"        "true"
    Option        "CRT2HSync"        "30-86"
    Option        "CRT2VRefresh"        "50-120"
    Option        "MetaModes"        "1280x800-1280x1024 1280x800-1024x768 1280x800-800x600"
    Option        "MergedNonRectangular"    "true"

    Option        "DDCMode"        "true"        ### da naj monitor sam pove resolucijo

the whole ServerLayout section:

Section "ServerLayout"

    Identifier    "Server Layout"

    Screen        "Screen0"

    InputDevice    "Keyboard1"    "CoreKeyboard"
    InputDevice    "Mouse"        "AlwaysCore"
    InputDevice    "Synaptics"    "CorePointer"

EndSection

and from the Display subsection of the Screen section:

        Modes        "1280x800" "1024x768" "800x600"
        Virtual        1280 800
        ViewPort    0 0

When the xorg.conf is finally free of unneeded user settings, just restart X and let RandR handle everything.

Now, let us say, you want to clone the display also to the external monitor or projector. Now plug the external display in and run xrandr --auto. In most cases this is enough, because RandR sees which resolutions are supported for each display and automatically applies the biggest resolution that works for both (or all). When you plug the external monitor/projector out, just run xrandr --auto again and all will be back to the way it was before.

In case you want more control, just run xrandr to see which ports are used and which resolutions those displays support (* marks which resolution is currently in use and + marks the optimal resolution for that display).

You will most likely see something like this:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1200
VGA-0 connected (normal left inverted right x axis y axis)
1280x1024      60.0 +   75.0     60.0     60.0
1280x960       60.0     60.0
1152x864       75.0     75.0
1024x768       75.1     75.0     70.1     60.0
832x624        74.6
800x600        72.2     75.0     60.3     56.2
640x480        75.0     72.8     72.8     75.0     66.7     60.0     59.9
720x400        70.1
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1280x800       60.0*+
1024x768       60.0
800x600        60.3
640x480        59.9
S-video disconnected (normal left inverted right x axis y axis)

Now that you know which output devices are plugged on which ports (LDVS is the internal laptop LCD), you can e.g. disable the internal monitor by hand by running xrandr --output LVDS --off

More info can be found by reading man xrandr – there you can also see how to set up modes other then clone (e.g. if you want the displays to form a grid, or just one left of the other etc.), handle picture rotations and a lot of other settings.

GUI frontends

There are also GUI frontends for xrandr in existance – for example KDE (at least 3.x) users have the Resize and Rotate System Tray Applet.

In case some output devices are always present (e.g. the integrated monitor or if you use certain monitors in a specific layout all the time), you can also put their specific settings into xorg.conf, for which the man pages of xorg.conf and your graphic card driver apply.

General clean-up

By now we succeeded in removing a lot from xorg.conf, but you can also safely strip it of any options that you do either do not need or that the defaults of them suit you just fine.

For example, this is how my xorg.conf looks like after this whole procedure:

Section "Monitor"
    Identifier    "Elberethin LCD"
    DisplaySize    331 207
EndSection

Section "Device"
    Identifier    "ATI Radeon X600"
    VendorName    "ATI Technologies Inc"
    Driver        "radeon"
#     Option        "AGPFastWrite"        "true"
    Option        "RenderAccel"        "true"        ### zgleda, da r300 še nima 3D pospeševanja (glej „man radeon“)
    Option        "AccelMethod"        "EXA"         ### XAA je starejši, bolj stabilen za 3D, EXA pa novejši in boljši za Render ter Composite
    Option        "DynamicClocks"        "true"        ### vklopljen varčuje baterijo; vendar nekateri pravijo, da oslabi 3D
    Option        "Monitor-LVDS"        "Elberethin LCD"    ### da za vgrajeni LCD uporabi posebne nastavitve samo zanj
EndSection

Section "Screen"
    Identifier    "Primarni zaslon"
    Device        "ATI Radeon X600"
    Monitor        "Elberethin LCD"
    DefaultDepth    24

    Subsection    "Display"
        Depth        24
    EndSubsection
EndSection

The difference from the beast at the beginning of this article is stunning, is it not? And not only is it now more legible, but we now have both input and output device hotplugging working properly. Long live Xorg and its evolution!

Related Posts

Published

Last Updated

Category

Tehne

Tags