Xorg: Using the US International (altgr-intl variant) Keyboard Layout

TL;DR: If you want to sanely type French, German, Spanish, or other European languages on a standard US keyboard (101 or 104 keys), your only real option is the us layout with the (relatively new) altgr-intl variant.

I like to type in French and German sometimes because I study these languages for fun. For some time, I had used the fr and de X keyboard layouts to input special characters from these languages. However, it wasn’t until recently that I realized how most European layouts, such as fr and de, require that you have a 105-key keyboard. A 105-key keyboard looks exactly like the standard, full-sized IBM-style 104-key keyboard (i.e., IBM Model “M” 101-key keyboard plus 2 Windows keys and 1 “Menu entry” key on the bottom row), except that it has 1 more extra key on the row where the Shift keys are (and also has a “tall” Enter key with some of the existing keys on the right side rearranged a bit).

I personally use a 104-key keyboard (a Unicomp Space Saver 104, because that’s how I roll). Now, when I switched to the fr layout the other day, I wanted to type the word âme. Unfortunately, the circumflex dead key was not where it was supposed to be. This was because I only had 104 keys instead of 105, and during the process of switching forcibly to the fr layout, there was a malfunction in the conversion (rightfully so).

Now, the choice was to either buy a 105-key keyboard or just find an alternative 104-key layout that had dead keys. I didn’t want to buy a new 105-key keyboard because (1) the extra 1 key results in a squished, “square” looking left-Shift key and (2) the tall Enter key would make it more difficult for me to keep my fingers happy on the home row, since I’d have to stretch my pinky quite a bit to reach it, and (3) I just didn’t feel like spending another ~$100 for a keyboard (my Unicomp is still in excellent condition!).

So, I had to find a new keyboard layout that could process accented/non-English Latin characters better. The Canadian Multilingual Standard keyboard layout (http://en.wikipedia.org/wiki/Keyboard_layout#Canadian_Multilingual_Standard) looked very, very cool, but it was only for a 105-key keyboard. I then discovered a layout called the US International Standard keyboard layout, which enables you to type all the cool accented letters from French or German (and other European languages) while still retaining a QWERTY, 101/104 key design. This sounded great, until I realized that the tilde (~), backtick (`), single quote (‘) and other keys were dead keys. I.e., to type ‘~’ in this layout, you have to type ‘~’ followed by a space. This is horrible for programmers in Linux because the ~ key comes up everywhere (it’s a shell shortcut for the $HOME directory). To type a single quote character, you have to type (‘) followed by a space! Ugh. I’m sorry, but whoever designed this layout was obviously a European non-programmer who wanted to type English easier.

But then, all hope was not lost. When browsing all of the choices for the us keyboard layout variant under X (/usr/share/X11/xkb/rules/base.lst), I found a curious variant called altgr-intl. A quick google search turned up this page, an email from the creator of this layout to the X developers: http://lists.x.org/archives/xorg/2007-July/026534.html. Here was a person whose desired usage fit perfectly with my own needs! Here’s a quote:

I regularly write four languages (Dutch, English, French and German)
on a US keyboard (Model M – © IBM 1984).

I dislike the International keyboard layout. Why do I have to press
two keys for a single quote (‘ followed the spacebar) just because the
‘ key is a dead-key that enables me to type an eacute (é)?

I decided to ‘hide’ the dead-keys behind AltGr (the right Alt key).
AltGr+’ followed by e gives me eacute (é). It also gives me
m² (AltGr+2).

Excellent! Apparently, this layout was so useful that it became included eventually into the upstream X codebase, as the altgr-intl variant for the standard us (QWERTY) keyboard layout. The most compelling feature of this layout is that all of the non-US keys are all hidden behind a single key: the right Alt key. If you don’t use the right Alt key, this layout behaves exactly the same as the regular plain us layout. How cool is that?! And what’s more, this layout makes it compatible with the standard 101-key or 104-key IBM-styled keyboards!

This variant deserves much more attention. Unfortunately, there seems to be little or no information about it other than the above-quoted email message. Also, I’ve noticed that it is capable of generating Norse characters as well, like þ and ø. There does not seem to be a simple keyboard layout picture on the internet to show all the keys. Anyway, I’ve been using it recently and it really does work great. There is no need for me to switch between the us, fr, and de layouts to get what I want. I just use this layout and that’s it. Take that, Canadian Multilingual Standard!

Here’s how to set it up: use either the setxkbmap program like this:

setxkbmap -rules evdev -model evdev -layout us -variant altgr-intl

in a script called by ~/.xinitrc, or use it directly in your keyboard xorg settings:

Section "InputClass"
    Identifier "Keyboard Defaults"
    MatchIsKeyboard "yes"
    Option  "XkbLayout" "us"
    Option  "XkbVariant" "altgr-intl"
EndSection

I personally prefer the script method because you can tweak it easily and reload it without restarting X. For me, I had to use the -rules evdev -model evdev options because -model pc104 would mess things up (probably due to an interaction with xmodmap and such in my ~/.xinitrc). Whatever you do, make sure everything works by testing out the AltGr (right Alt) key. For example, AltGr+a should result in ‘á’.

A couple caveats: Some keys like â and è (which are AltGr+6+a and AltGr+`+e (i.e., uses dead keys)) do not show up at all on urxvt. I’m guessing that the dead keys are broken for urxvt (or maybe it’s a bug with this layout; who knows). Luckily, I can just use a non-console app (like GVIM) to do my Euro-language typing, so it’s OK (although, eventually, I’ll run into this bug again when I start typing French emails from within mutt inside urxvt 20 years later… but by then it will be fixed, I’m sure.) Also, the nifty xkbprint utility can generate nice pictures of keyboard layouts (just do a google image search on it), but it’s currently missing (https://bugs.archlinux.org/task/17541) from Arch Linux’s xorg-xkb-utils package. So, if you’re on Arch, you’ll have to experiment a bit to figure out the various AltGr+, and AltGr+Shift+ key combinations.

See also: Xorg: Switching Keyboard Layouts Consistenly and Reliably from Userspace

UPDATES:

  • October 30, 2011: I just found out that the dead keys bug in urxvt is actually a bug in ibus/SCIM (I use ibus, which relies on SCIM, to enter Japanese/Korean characters when I need to). I tried out uim, which is a bit more complicated (much less user friendly, although there are no technical defects, from what I can tell), and with uim, the dead keys work properly in urxvt. The actual bug report for ibus is here.
    So, use uim if you want to use the altgr-intl layout flawlessly, while still retaining CJK input functionality. Of course, if you never needed CJK input methods in the first place, this paragraph shouldn’t concern you at all.
  • December 7, 2011: Fix typo.
  • January 24, 2012: Fix grammar.

Xorg: Switching Keyboard Layouts Consistenly and Reliably from Userspace

For some time now, the XkbLayout option (set to “us, fr, de”) in my /etc/X11/xorg.conf.d/10-keyboard.conf has been broken for me. This probably has something to do with my recent xmodmap hacks in ~/.xinitrc, and possibly the interaction with the /etc/X11/xorg.conf.d/10-evdev.conf, which includes an entry to catch all keyboards. I decided to fix this problem today, and with a healthy dose of serendipity, got everything working smoothly again. Sources for my custom scripts are included, as usual.

By accident, I discovered the setxkbmap userland program. It does everything you could possibly do with keyboard layouts. It is maintained by the Xorg project, so it’s pretty much guaranteed to work. Here’s a sample run (using Arch’s xorg-setxkbmap 1.2.0-2 and xorg-server 1.10.1-1):

$ setxkbmap -help
Usage: setxkbmap [args] [<layout> [<variant> [<option> ... ]]]
Where legal args are:
-?,-help            Print this message
-compat <name>      Specifies compatibility map component name
-config <file>      Specifies configuration file to use
-device <deviceid>  Specifies the device ID to use
-display <dpy>      Specifies display to use
-geometry <name>    Specifies geometry component name
-I[<dir>]           Add <dir> to list of directories to be used
-keycodes <name>    Specifies keycodes component name
-keymap <name>      Specifies name of keymap to load
-layout <name>      Specifies layout used to choose component names
-model <name>       Specifies model used to choose component names
-option <name>      Adds an option used to choose component names
-print              Print a complete xkb_keymap description and exit
-query              Print the current layout settings and exit
-rules <name>       Name of rules file to use
-symbols <name>     Specifies symbols component name
-synch              Synchronize request w/X server
-types <name>       Specifies types component name
-v[erbose] [<lvl>]  Sets verbosity (1..10).  Higher values yield
                    more messages
-variant <name>     Specifies layout variant used to choose component names

And here’s a sample query on my machine:

$ setxkbmap -query
rules:      base
model:      pc105
layout:     us

And here’s how to change layouts.

To switch to the “us” keyboard layout:

$ setxkbmap us

To switch to the “fr” layout:

$ setxkbmap fr

To switch to the “de” layout:

$ setxkbmap de

And so on. Very useful, indeed. Here are some things to keep in mind:

  1. The layout change is X server-wide. This means that your layout change will take effect on all windows. Of course, you can limit your layout change with the various options like -display or -geometry, but to me that’s impractical.
  2. You can run this command from within a script, in a sub-shell (backgrounded), and it will still work! This is a nice feature which allows one to script/automate the whole thing (which is what I did).
  3. Unfortunately, running this command clears any xmodmap settings that were present before. For Xmonad/vim/etc. users who like to change up their Caps Lock key, for example, you need to re-run the xmodmap commands to get them back. I’m in this boat.

So, here’s my new setup, taking into account the xmodmap issue noted above:

  • layout_switch.sh: This script simply changes up the layout. It’s a dead-simple zsh script that you can easily port to Bash.
  • xmodmap.sh: This script simply does all the xmodmap-editing business that I need to do to get my Xmonad setup to work.
  • ~/.xmonad/xmonad.hs: Here, I have set up a hotkey sequence to call the layout_switch.sh script. I have to be careful to choose a hotkey that will remain consistent even in different layouts (e.g., I first tried the “\” backslash key, but this key’s location is different in the French layout). This means that I have to depend on keys like Escape, or the F1-F12 function keys. Since I already have F1-F12 mapped to additional workspaces, I chose the Escape key.
  • ~/.xinitrc: Here, I call the layout_switch.sh script to set my keyboard layout explicitly on startup. You could do fancy things, for example, of selecting a different layout on a different day (maybe on Sundays you want to start typing in French only, so you could just script that in here).

And here are the relevant source files for these scripts:

layout_switch.sh:

#!/bin/zsh
# LICENSE: PUBLIC DOMAIN
# switch between us, fr, and de layouts

# If an explicit layout is provided as an argument, use it. Otherwise, select the next layout from
# the set [us, fr, de].
if [[ -n "$1" ]]; then
    setxkbmap $1
else
    layout=$(setxkbmap -query | awk 'END{print $2}')
    case $layout in
        us)
            setxkbmap fr
            ;;
        fr)
            setxkbmap de
            ;;
        *)
            setxkbmap us
            ;;
    esac
fi

# remap Caps_Lock key to Xmonad's exclusive 'mod' key
~/syscfg/script/sys/xmodmap.sh

xmodmap.sh:

#!/bin/zsh
# LICENSE: PUBLIC DOMAIN
# remap Caps_Lock key to Xmonad's exclusive 'mod' key

xmodmap -e "remove Lock = Caps_Lock"
xmodmap -e "add mod3 = Caps_Lock"
xmodmap ~/.xmodmap

~/.xmodmap:

remove Lock = Caps_Lock
remove mod3 = Super_L
keysym Caps_Lock = Super_L
add mod3 = Super_L

~/.xmonad/xmonad.hs:

myKeys :: String -> XConfig Layout -> M.Map (KeyMask, KeySym) (X ())
myKeys hostname conf@(XConfig {XMonad.modMask = modm}) = M.fromList $
...
    -- change keyboard layouts
    , ((modm              , xK_Escape), spawn "/home/shinobu/syscfg/script/sys/layout_switch.sh")
...

~/.xinitrc:

...
# explicitly choose "us" (English) keyboard layout (and set Caps Lock key to
# xmonad's modmap key)
/home/shinobu/syscfg/script/sys/layout_switch.sh us &
...

There are a couple big advantages to this setup:

  • Because everything is handled in userspace (we didn’t touch any Xorg file!), we no longer have to restart the X server to diagnose any problem we encounter with changing the keyboard layout. Gone are the days of fiddling with a “XkbLayout” option (or any other Xorg option) and restarting X just to see if the changes worked.
  • Because everything is handled in userspace, we can use any number of custom shell scripts, programs, etc. to customize how the layout switch is made. For me, since I use Xmonad, I can use Xmonad’s extensive, consistent hotkey definitions to choose which hotkeys to do the layout switch. To be honest, I disliked the options available in the base file (/usr/share/X11/xkb/rules/base) when choosing which hotkeys to do my keyboard layout switching. And, my choice of modm + Escape (i.e., (dead) Caps Lock key + Escape) was impossible to realize with the base file.

Finally, a caveat: the only flaw with the setup above is that if I execute the xmonad.hs layout-switching hotkey too quickly too many times, there’s a chance of two independent processes of layout_switch.sh being spawned at nearly the same time. This means that the call to xmodmap.sh within each of those processes might get interleaved! For me, this has resulted in my Caps lock key becoming permanently turned on, for instance. However, you can always execute the xmodmap.sh script a second or two afterwards to clear this up.

I strongly recommend everyone to do their keyboard switching this way — not only is everything made explicit, but everything is transparent, too: keyboard layout switching isn’t a mysterious process anymore.

UPDATE August 18, 2011: Cleaned up some typos.

UPDATE August 24, 2011: See this post — I no longer use the fr and de layouts, but rather, just the us layout with variant altgr-intl. It’s much, much simpler this way.

Linux Dual Monitor Setup: Nvidia & Xinerama Guide: Rotating just one monitor

I have 2 LCD monitors (both are widescreen) hooked up to an Nvidia card in Linux. For a while, I rotated both of them into a “portrait” view, because, aside from the other benefits a portrait view can give (to webpages and documents), putting two widescreens on a landscape configuration takes up too much horizontal space.

But yesterday, I decided to take a hybrid approach and put my left monitor in landscape view, but my right one into portrait view — i.e., I only wanted one monitor rotated 90 degrees. Of course, this is fairly straightforward in Windows with the proprietary Nvidia utility, but it takes a little bit of work with Linux. I googled around a bit, and found this page. I couldn’t really understand what was going on by just looking at the sample xorg.conf file on that page, so I decided to write out my usual in-depth explanation on the matter.

First, to get this hybrid approach, you have to use Xinerama, and NOT Nvidia’s popular TwinView utility/configuration. This is because TwinView (in Linux) only allows you to rotate BOTH monitors together in the same direction.

The only thing you have to do is edit your /etc/X11/xorg.conf file. First, if you already have TwinView set up to work in a dual monitor configuration, you have to run sudo nvidia-settings, and then change from “TwinView” to “Separate X screen” under the “X Server Display Configuration” settings, like so:

2009-10-04-133053_914x657_scrot

The reason we do this (if you already have nvidia-settings installed) is because it auto-generates a working xorg.conf for us. The thing is, under TwinView, you just have 1 option for everything in Xorg — i.e., you just have Device0, Screen0, Monitor0, but now with the “Separate X screen”, you have Device1, Screen1, etc. Not only that, but your old, irrelevant TwinView settings will be automatically deleted or commented out, so it will save you a couple minutes of work (and any typos as well — typos will prevent X from booting!). After that, it’s just a matter of tweaking the xorg.conf file to suit your needs. (BTW, the reason why the right monitor looks like it’s not aligned vertically correctly with the one on the left is because of a manual adjustment — it’s the 333 pixel shift adjustment I made; read on below for more on that).

Here is my current, working xorg.conf with just 1 monitor rotated:

Section "ServerLayout"
Identifier     "Layout0"
#Screen      0  "Screen0" RightOf "Screen1" # put it on the RIGHT (other options are Below, Above, LeftOf, RightOf;
# alternatively, you can put an absolute, pixel X and Y offset (so RightOf
# would be 1680 0
Screen      0  "Screen0" 1680 0 # NOTE: Screen 0 MUST be defined BEFORE Screen 1!!!
Screen      1  "Screen1" 0 333 # put this screen on the top left, but adjust it down a little bit to match the portrait screen on the right
InputDevice    "Keyboard0" "CoreKeyboard"
InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "Module"
Load           "dbe"
Load           "extmod"
Load           "type1"
Load           "freetype"
Load           "glx"
EndSection

Section "ServerFlags"
Option         "AutoAddDevices" "False"
Option         "Xinerama" "1"
EndSection

Section "InputDevice"

# generated from default
Identifier     "Mouse0"
Driver         "mouse"
Option         "Protocol" "auto"
Option         "Device" "/dev/psaux"
Option         "Emulate3Buttons" "no"
#Option         "ZAxisMapping" "4 5" # for the Logitech MX 400
EndSection

Section "InputDevice"
Identifier     "Keyboard0"
Driver         "kbd"
Option         "XkbModel" "pc105"
Option         "XkbLayout" "us,fr,de"
Option         "XkbOptions" "grp:shifts_toggle"
EndSection

Section "Monitor"
Identifier     "Monitor0"
VendorName     "Unknown"
ModelName      "Acer X222W"
HorizSync       31.0 - 81.0
VertRefresh     56.0 - 75.0
Option         "DPMS"
Option         "Rotate" "Right" # for portrait mode
EndSection

Section "Monitor"
Identifier     "Monitor1"
VendorName     "Unknown"
ModelName      "Acer X222W"
HorizSync       31.0 - 81.0
VertRefresh     56.0 - 75.0
Option         "DPMS"
EndSection

Section "Device"
Identifier     "Device0"
Driver         "nvidia"
VendorName     "NVIDIA Corporation"
BoardName      "GeForce 8800 GTS"
Option         "RandRRotation" "on"
BusID          "PCI:1:0:0"
Screen          0 # i.e., the monitor on the RIGHT (physically)
EndSection

Section "Device"
Identifier     "Device1"
Driver         "nvidia"
VendorName     "NVIDIA Corporation"
BoardName      "GeForce 8800 GTS"
BusID          "PCI:1:0:0"
Screen          1 # the monitor on the LEFT (physically)
EndSection

Section "Screen"

Identifier     "Screen0"
Device         "Device0"
Monitor        "Monitor0"
DefaultDepth    24
Option         "metamodes" "DFP-0: 1680x1050 +0+0"
SubSection     "Display"
Depth       24
EndSubSection
EndSection

Section "Screen"
Identifier     "Screen1"
Device         "Device1"
Monitor        "Monitor1"
DefaultDepth    24
Option         "metamodes" "DFP-1: 1680x1050 +0+0"
SubSection     "Display"
Depth       24
EndSubSection
EndSection

Probably the most important options are the “Screen” options under the “ServerLayout” section — these define which monitor starts where, and the relationship between the two monitors. The “Screen” options are defined by a X-axis (horizontal) and Y-axis (vertical) offset — you can only use positive numbers, I think, and so this means that if a screen is defined as “0 0”, it is on the top left corner of the imaginary monitor “plane,” so to speak. I.e., increasing the X-axis offset moves your screen to the right, whereas increasing the Y-axis offset moves your screen down. For me, my left monitor is slightly adjusted down by 333 pixels, so that it matches up smoothly with my rotated monitor on my right (my setup, physically, looks like a sideways “T”). I’m not sure if the “RandRRotation” option is necessary — it probably is not — I’m too lazy to check after fiddling with my xorg.conf all day yesterday. The other options should be self-explanatory, along with the comments.

 

Here are some of the not-so-obvious details: for me, my “DFP-1” is my LEFT monitor and “DFP-0” is my RIGHT monitor. Apparently, the “primary display” is by default DFP-o (e.g., in Windows, the Nvidia utility detects DFP-o (my RIGHT monitor) as screen “1 of 2”, so I have to manually set DFP-1 (2 of 2) as my primary screen) — the only reason why I have it like this is because for some reason, my BIOS stuff shows up on DFP-1, and not the default “primary” DFP-0, and I’ve always liked my BIOS to show up on my LEFT screen by default — hence the reason why DFP-1 is on my left and DFP-0 is on my right. I hope that made sense. It probably didn’t, so here is a screenshot:

Each monitor has a resolution of 1680×1050, but now, my virtual desktop has a 2730×1680 resolution (1680 + 1050 = 2730). DFP-0 is physically rotated so that the bottom side sticks out to the far right — i.e., it’s rotated counter-clockwise 90 degrees — so that the clean, button-less bezel of its top area matches up nicely with the unrotated DFP-1. And so, we rotate “Right” under the “Monitor” section for Screen 0. This is probably the most sensible way for most people, since almost all monitors that do have buttons at all (to make an uneven, fatter bezel where the buttons are) have them at the bottom of the monitor.

Here are the advantages that you get with Xinerama in the above setup:

  • Moving the mouse from the right to the left is always continuous and seamless. This is even true when moving from the far edges of the portrait monitor into the widescreen one (see notes in screenshot). Finally, the virtual screen behaves EXACTLY like how the monitors look in the real world. (This behavior is available in Windows; however, there are two shortcomings that are not found in Xinerama: (1) when the mouse is on the top or bottom edge of the portrait monitor, your mouse becomes “stuck” and does not transition smoothly over to the widescreen monitor on the other side (see screenshot above); (2) even though you can adjust the monitors by simply dragging the icons around (which is very user-friendly, I must say), the adjustments are very course and you cannot adjust things down to the last pixel.)
  • Maximizing a window maximizes to the monitor’s area (i.e., the window maximizes up to either the landscape or portrait view), and not the big, virtual landscape of 2730×1680 pixels; even the applications behave intelligently!

A (temporary) disadvantage:

  • Since I’m using Xmonad as my window manager, popup dialog boxes automatically spawn to to the top-left of the virtual screen — i.e., if they’re small enough, they fit entirely into the unviewable area on the top edge. I have to manually flatten the image into the tiled area to see the contents of it. However, this is Xmonad’s fault, and there is probably a hack out there to fix this sort of thing. Even so, since I don’t really use GUI applications that have a lot of popup dialog boxes in the first place, this is a non-issue.

For a long time I thought that Xinerama was an ATI thing, but apparently, it works for Nvidia as well. The xorg.conf layout looks much nicer, and simpler with Xinerama, and is much more flexible with it (e.g., the 333 pixel shift). If you change the few lines in my xorg.conf above that deal with rotations, you could even do without TwinView as well and just use Xinerama for a basic dual-head setup without any rotated screens.

Minor Update, February 25, 2010: A comment in the screencap was incorrect. Thanks Bela!

(Belated) Update November 4, 2010: Removed obsolete bugs and workarounds (In short, commit 21ed660f30a3f96c787ab00a16499e0fb034b2ad was introduced in into the xserver code in the spring of 2010, and fixed this issue of left vs. right monitors b). Xorg 1.8.1.902 works perfectly fine with either monitor being rotated into portrait mode.

Update June 20, 2012: Nvidia driver version 302.17 has made some changes to how you describe which monitor to rotate. Here is my current Xorg file, called “10-dual-monitor-hybrid.conf” which lives under /etc/X11/xorg.conf.d:

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0 # NOTE: Screen 0 MUST be defined BEFORE Screen 1!!!
    Screen      1  "Screen1" 1050 295 # push this screen down (vertically) 295 pixels from the top to match the portrait monitor on the left
    Option         "Xinerama" "1" # dual-head won't work properly without this!
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Acer X222W"
    HorizSync       31.0 - 81.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "Acer X222W"
    HorizSync       31.0 - 81.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8800 GTS"
    BusID          "PCI:1:0:0"
    Screen          0 # i.e., the monitor on the LEFT (physically)
    Option "NoLogo" "1"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8800 GTS"
    BusID          "PCI:1:0:0"
    Screen          1 # the monitor on the RIGHT (physically)
    Option "NoLogo" "1"
EndSection

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "metamodes" "DFP-0: 1680x1050 +0+0 { Rotation=left }"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "metamodes" "DFP-1: 1680x1050 +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Notice that the screen rotation settings are now taken care of under the “metamodes” option in the “Screen” section of the monitor you want to rotate. The recent Xorg versions do not use the usual /etc/X11/xorg.conf file any more (it has been like that for many months).