Random Wisdom

On a default Fedora installation, Gnome will automatically mount (with some default options) any recognized volumes as soon as an external storage device is plugged in. While the defaults might be fine in general, sometimes it is necessary to supply some more options.

The tool responsible for automating the mount (gnome-volume-manager) gets additional options from the /system/storage/default_options/$fstype$/mount_options key of gconf — the Gnome “system registry”. One can check/modify existing entries (one a per user basis) by running:

$ gconf-editor /system/storage/default_options &

This should launch the graphical configuration editor with the default_options key selected. Under this key are the entries for different filesystems. Default mount options can then be changed by selecting the desired filesystem and editing the mount_options key.

If a required filesystem type is not listed, then it can be added by using the gconftool-2 utility. E.g. if we wanted to add the ext3 filesystem to the configuration database with the options “sync” and “uid=“, we would run the command:

$ gconftool-2 -t list –list-type string \

                  -s /system/storage/default_options/ext3/mount_options “[sync,uid=]”

Next time an external volume is plugged in, it will be mounted with the additional options specified! It should be noted that regardless of the options supplied via gconf, some mount options are always present: r(o|w),noexec,nosuid,nodev. At the moment I do not know how to change them.

The main motivation for finding out about the defaults is that I wanted to add “sync” as a default option. This causes data to be written immediately to the device, instead of being buffered first — a useful option to have for external devices. It should minimized data loss in case of an accidental removal (without running umount first). However, it should also be noted that for solid state drives (e.g. flash), this may result in a shortening of service life and poorer performance.

Update [Sun Mar 18, 2007]:
I’ve done some rudimentary throughput performance testing with both the sync and async modes and the performance hit with sync appears to be quite severe (at least 20 times slower than async) — even with a high performance HDD as the target. In light of this, I am removing sync from the list of default options. Given the type of data I’m likely to store on the device, speed is certainly more valuable than data integrity.

Test results:
Testing was carried out on a FAT32 volume. For each mode, both the transfer time and the subsequent un-mount time (indicating the time needed to flush the buffer) are shown.

async:

$ time dd if=/dev/zero of=/tmp/usb/dummy bs=8k count=130000 && time sudo umount /tmp/usb/
130000+0 records in
130000+0 records out
1064960000 bytes (1.1 GB) copied, 45.9035 seconds, 23.2 MB/s

real    0m46.026s
user    0m0.035s
sys     0m2.915s

real    0m11.680s
user    0m0.003s
sys     0m0.263s

sync:

$ time dd if=/dev/zero of=/tmp/usb/dummy bs=8k count=130000 && time sudo umount /tmp/usb/
130000+0 records in
130000+0 records out
1064960000 bytes (1.1 GB) copied, 969.384 seconds, 1.1 MB/s

real    16m13.525s
user    0m0.048s
sys     0m12.156s

real    0m0.842s
user    0m0.004s
sys     0m0.199s

There’s lot that can be learned from the conversations on the fedora-list. Today I learnt of a nifty little tool called gnome-open. Basically you just type something like:

[darkknight@darkworld ~]$ gnome-open file.cpp

and voila! It figures out the default application (under GNOME) for the files of type *.cpp and opens the file using that default editor. I haven’t verified, but it seems that instead of a file an URL can also be specified. Mmm .. it definitely creates the possibility of writing portable scripts; at least on GNOME systems anyway 🙂

This is useful for multimedia keyboards that aren’t automatically recognized. Also useful when you want actions other that those offered in “gnome-keybinding-properties“. The first step is to check if the buttons are recognized at all. This can be accomplised by running “xev”

$ xev

Once the little window pops up, press any of the buttons and see if you get an output like the following:

KeyPress event, serial 29, synthetic NO, window 0x3c00001,
root 0xd6, subw 0x0, time 2073408, (1033,644), root:(1051,745),
state 0x0, keycode 231 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3c00001,
root 0xd6, subw 0x0, time 2073529, (1033,644), root:(1051,745),
state 0x0, keycode 231 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:

If you do get the output, the important thing to note is the keycode (keycode 231 here). Once you have the keycode for a key, you need to define a Key Symbol for it. To do this, you need a xmodmap file. You can get a copy of it using:

$ xmodmap -pke > ~/.xmodmaprc

Once the current map is dumped, open the file for editing and locate the required keycode:

$ vi ~/.xmodmaprc
[snip]
keycode 231 =
[snip]

As we can see there is no symbol associated with the keycode 231 yet. To get a list of available symbols, look at /usr/X11R6/lib/X11/XKeysymDB. Since the button is marked as Refresh, we can use XF86Refresh as a suitable symbol:

[snip]
keycode 231 = XF86Refresh
[snip]

Once all the required keys have been set, save the file.

To make the new map take effect (in GNOME):

$ gconftool-2 --set "/desktop/gnome/peripherals/keyboard/general/known_file_list" 
  --type list --list-type string "[.xmodmaprc]"

$ gconftool-2 --set "/desktop/gnome/peripherals/keyboard/general/update_handlers"
  --type list --list-type string "[.xmodmaprc]"

At this point you probably need to logout and log back in.

Now, for the case where xev doesn’t already detect the key. Start by tailing the /var/log/messeges file:

$ sudo tail -f /var/log/messages

The last lines of the file will be displayed. Now, press the desired key. Now, you should see something like

Aug 27 13:55:58 darkworld kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x96 on isa0060/serio0).
Aug 27 13:55:58 darkworld kernel: atkbd.c: Use 'setkeycodes e016 <keycode>' to make it known.
Aug 27 13:55:58 darkworld kernel: atkbd.c: Unknown key released (translated set 2, code 0x96 on isa0060/serio0).
Aug 27 13:55:58 darkworld kernel: atkbd.c: Use 'setkeycodes e016 <keycode>' to make it known.

So, as suggested, we make it known by:

$ setkeycodes e016 187

I chose 187 since it doesn’t appear to be used by any key yet. Once all the keycodes have been set, repeat as before to assign the key symbols.

[Edit (Sept. 8, 2005)]
It seems that there is a better way to choose the kernel keycode. We can run getkeycodes to see which keycodes are currently in use. We can use any keycode between 84 and 255 that is not already used.

$ getkeycodes
Plain scancodes xx (hex) versus keycodes (dec)
for 1-83 (0x01-0x53) scancode equals keycode

0x50:   80  81  82  83  99   0  86  87
0x58:   88 117   0   0  95 183 184 185
0x60:    0   0   0   0   0   0   0   0
0x68:    0   0   0   0   0   0   0   0
0x70:   93   0   0  89   0   0  85  91
0x78:   90  92   0  94   0 124 121   0

Escaped scancodes e0 xx (hex)

e0 00:    0 195 196 197 198   0   0   0
e0 08:    0   0   0   0   0   0   0   0
e0 10:  165   0   0   0   0   0   0   0
e0 18:    0 163   0   0  96  97   0   0
e0 20:  113 140 164   0 166   0   0   0
e0 28:    0   0 255   0   0   0 114   0
e0 30:  115   0 150   0   0  98 255  99
e0 38:  100   0   0   0   0   0   0   0
e0 40:    0   0   0   0   0 119 119 102
e0 48:  103 104   0 105 112 106 118 107
e0 50:  108 109 110 111   0   0   0   0
e0 58:    0   0   0 125 126 127 116 142
e0 60:    0   0   0 143   0 217 156 173
e0 68:  128 159 158 157 155 226   0 112
e0 70:    0   0   0   0   0   0   0   0
e0 78:    0   0   0   0   0   0   0   0

It also seems we need to restore the kernel keycode mapping after every reboot. This is easily accomplished by having the required commands in /etc/rc.local:

[darkknight@darkworld ~]$ cat /etc/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

setkeycodes e016 187 e015 188 e014 189 e013 190 e005 191
            e01e 192 e009 193 e00b 202 e008 194 e018 199
            e00a 200 e017 201 e03b 203 e03c 204 e03d 205
            e03e 206 e03f 207 e040 208 e041 211 e042 210
            e043 212 e023 213 e057 214 e058 215 e064 216

The kernel keycodes are different from the keycodes used by X. So, we need to run xev again to get the keycodes (as seen by X) of the newly found keys.

Got the hints from here.
[End Edit]

Now that we have KeySymbols, what do we do with them? Open up gconf-editor and browse to the key /apps/metacity/global_keybindings. There, choose any of the run_command_* keys marked as disabled and change the value to the desired KeySymbol (e.g. XF86AudioPrev). Then navigate to the key /apps/metacity/keybinding_commands and find the command_* key with the same number as the run_command_*. Change the value of the key to whatever command you wish to be performed when the Previous key is pressed. If you happen to run out of run_command_* and command_* key pairs, simply create new pairs from the right click menu.