3
Long time no speak... Glad to be back : )
Unfortunately, it's to share some of my findings with configuring Ubuntu on a Thinkpad X300, which means I had to spend some time figuring out the correct settings... But let's cut down to the chase: configuring the X300 internal mic to work with your favorite "sound capturing" program, in our case, let's say skype.
First, you'd need to have the "backports-alsa-karmic" for your version of Ubuntu, whichever it is: linux-backports-alsa-karmic-generic or linux-backports-alsa-karmic-generic-pae
Also make sure you have the package "gnome-alsamixer" installed, as this will play a crucial part in the config...
Then, it's a 2-part operation:
1. Manually loading ALSA
This means editing the /etc/pulse/default.pa to add a line similar to:
load-module module-alsa-source device=hw:0,0
Upon restart, you will see notice a new entry in the "Input" tab of the "Sound preferences", named "Internal Audio", as opposed to the "Internal Audio Analog Stereo" that existed before. See the screenshot below, where you'll notice that the input level gauge recognizes I'm currently speaking to my laptop)))
2. Configure ALSA
This is done via the GUI you start with Applications > Sound & Video > GNOME ALSA Mixer. The important part is to have the Rec checkbox ticked under "Capture". Once again, screenshot below...
After that, your application should be able to capture sound from the internal mic...
Unfortunately, it's to share some of my findings with configuring Ubuntu on a Thinkpad X300, which means I had to spend some time figuring out the correct settings... But let's cut down to the chase: configuring the X300 internal mic to work with your favorite "sound capturing" program, in our case, let's say skype.
First, you'd need to have the "backports-alsa-karmic" for your version of Ubuntu, whichever it is: linux-backports-alsa-karmic-generic or linux-backports-alsa-karmic-generic-pae
Also make sure you have the package "gnome-alsamixer" installed, as this will play a crucial part in the config...
Then, it's a 2-part operation:
1. Manually loading ALSA
This means editing the /etc/pulse/default.pa to add a line similar to:
load-module module-alsa-source device=hw:0,0
Upon restart, you will see notice a new entry in the "Input" tab of the "Sound preferences", named "Internal Audio", as opposed to the "Internal Audio Analog Stereo" that existed before. See the screenshot below, where you'll notice that the input level gauge recognizes I'm currently speaking to my laptop)))
2. Configure ALSA
This is done via the GUI you start with Applications > Sound & Video > GNOME ALSA Mixer. The important part is to have the Rec checkbox ticked under "Capture". Once again, screenshot below...
After that, your application should be able to capture sound from the internal mic...
0
Fedora 11 has been released for a while now. The upgrade from my Fedora 10 installation was relatively pain-free and Fedora 11 runs happily on my system. Upgrading did not bring any stunning revolutions and, as I'm not using ext4 yet, the most noticeable change from my point of view is certainly the 20 seconds start-up.
Now, some forewords of wisdom...
WARNING1: It is not possible to upgrade directly from Fedora 9 to Fedora 11. You must upgrade to Fedora 10 first. Do not attempt an upgrade from Fedora 9 to Fedora 11!
WARNING2: Make sure you backup important data before you upgrade. It does have to be complicated: use rsync or tar to do this.
WARNING3: The yum update step should NOT run inside a graphical session (Gnome or KDE or whatever you favorite GDM is). This could result in a unusable install. Updates should be run in a vty, runlevel 3, or a screen session.
That being said, let's get into the details!
1. Prepare for the upgrade
First we need to upgrade the RPM package via yum update rpm. During this step, I encountered the error:
The solution was to clean up the install *manually* prior to updating RPM:
If you notice that a new kernel got installed during yum -y update, you have to reboot the system. After the reboot, log in as root again either directly or via sudo.
Finally, we need to clean the yum cache:
2. Upgrade
Here is the upgrade process itself. We can do this with preupgrade, which will also take care of your RPMFusion packages and start a nice handy GUI. Install preupgrade, then start the utility:
The preupgrade wizard will then start... Just follow the indications of the screen and you'll be off with a flashy new Fedora 11 installation!
Fedora 11 has been released for a while now. The upgrade from my Fedora 10 installation was relatively pain-free and Fedora 11 runs happily on my system. Upgrading did not bring any stunning revolutions and, as I'm not using ext4 yet, the most noticeable change from my point of view is certainly the 20 seconds start-up.
Now, some forewords of wisdom...
WARNING1: It is not possible to upgrade directly from Fedora 9 to Fedora 11. You must upgrade to Fedora 10 first. Do not attempt an upgrade from Fedora 9 to Fedora 11!
WARNING2: Make sure you backup important data before you upgrade. It does have to be complicated: use rsync or tar to do this.
WARNING3: The yum update step should NOT run inside a graphical session (Gnome or KDE or whatever you favorite GDM is). This could result in a unusable install. Updates should be run in a vty, runlevel 3, or a screen session.
That being said, let's get into the details!
1. Prepare for the upgrade
First we need to upgrade the RPM package via yum update rpm. During this step, I encountered the error:
[nicolas@munin /TEMP]# yum update rpm
(...)
rpmdb: Program version 4.7 doesn't match environment version 4.5
error: db4 error(-30971) from dbenv->open: DB_VERSION_MISMATCH:
Database environment version mismatch
(...)
(...)
rpmdb: Program version 4.7 doesn't match environment version 4.5
error: db4 error(-30971) from dbenv->open: DB_VERSION_MISMATCH:
Database environment version mismatch
(...)
The solution was to clean up the install *manually* prior to updating RPM:
yum clean all
rm -f /var/lib/rpm/__db*
rpm --rebuilddb
yum -y update
yum update rpm
rm -f /var/lib/rpm/__db*
rpm --rebuilddb
yum -y update
yum update rpm
If you notice that a new kernel got installed during yum -y update, you have to reboot the system. After the reboot, log in as root again either directly or via sudo.
Finally, we need to clean the yum cache:
yum clean all
2. Upgrade
Here is the upgrade process itself. We can do this with preupgrade, which will also take care of your RPMFusion packages and start a nice handy GUI. Install preupgrade, then start the utility:
yum install preupgrade
preupgrade
preupgrade
The preupgrade wizard will then start... Just follow the indications of the screen and you'll be off with a flashy new Fedora 11 installation!
1
For a while now, I've been searching documentation about Solid State Drives (SSD). They are still quite expensive when compared to traditional SATA drives - 40 times more expensive in fact :), but they offer good performances and as their prices will keep falling down, they will make a better alternative. Among other advantages, they are shock-resistant, consume less resources than traditional HD and have very fast access times.
My X300 is currently fitted with a 64GB Samsung SSD that works fine with either Fedora or Ubuntu. That said, the performance and life expectency of an SSD drive can be significantly improved by a few tweaks.
1. Mount volumes using the noatime option
By default on Linux, the last accessed time of files will be logged. All these additional write operations can reduce the life of the disk. The noatime mount option will turn this off. Most Linux distros use the relatime option by default. For your SSD partitions (presumably formatted as ext3), replace relatime with noatime in /etc/fstab.
PS: you need a reboot for these changes to take effect.
2. Change the I/O scheduler
The default I/O scheduler in Linux is cfq, which stands for "completely fair queuing". It works quite well with standard HD but since SSDs are a different sort of beast, noop or deadline are probably more suited to them.
Personally, I've opted for noop. Simply added “elevator=noop” to the kernel parameters in my boot loader’s config file - typically /boot/grub/menu.lst. Here is the Fedora section on my laptop:
Once again, this type of change need a restart to be fully effective.
3. Prefer ramdisk for temporary filesystems
This is something I've been using for a while, even with standard HD, for machines where the amount of available RAM is important. For standard HD, the reasoning was that reading the RAM was faster than reading the disk. With SSD, this performance argument can be discussed, but still, you will increase your disk's life expectancy by moving temporary filesystems that are frequently read to the RAM. Another advantage is that these filesystems are removed then re-mounted at every reboot, meaning that you are less likely to have to clean them up manually.
Again, the changes are to be made in /etc/fstab. Here is a sample from my Ubuntu fstab:
Limiting the size of these tmpfs directly in /etc/fstab is likely a bit of an overkill, but these temporary filesystems (especially /tmp) can be filled up pretty quickly (by an application core dump for instance) and you surely don't want to see all your RAM eaten up in such case...
For a while now, I've been searching documentation about Solid State Drives (SSD). They are still quite expensive when compared to traditional SATA drives - 40 times more expensive in fact :), but they offer good performances and as their prices will keep falling down, they will make a better alternative. Among other advantages, they are shock-resistant, consume less resources than traditional HD and have very fast access times.
My X300 is currently fitted with a 64GB Samsung SSD that works fine with either Fedora or Ubuntu. That said, the performance and life expectency of an SSD drive can be significantly improved by a few tweaks.
1. Mount volumes using the noatime option
By default on Linux, the last accessed time of files will be logged. All these additional write operations can reduce the life of the disk. The noatime mount option will turn this off. Most Linux distros use the relatime option by default. For your SSD partitions (presumably formatted as ext3), replace relatime with noatime in /etc/fstab.
PS: you need a reboot for these changes to take effect.
2. Change the I/O scheduler
The default I/O scheduler in Linux is cfq, which stands for "completely fair queuing". It works quite well with standard HD but since SSDs are a different sort of beast, noop or deadline are probably more suited to them.
Personally, I've opted for noop. Simply added “elevator=noop” to the kernel parameters in my boot loader’s config file - typically /boot/grub/menu.lst. Here is the Fedora section on my laptop:
title Fedora Core 10
root (hd0,0)
kernel /vmlinuz-2.6.27.21-170.2.56.fc10.x86_64 ro rhgb quiet elevator=noop
initrd /initrd-2.6.27.21-170.2.56.fc10.x86_64.img
quiet
root (hd0,0)
kernel /vmlinuz-2.6.27.21-170.2.56.fc10.x86_64 ro rhgb quiet elevator=noop
initrd /initrd-2.6.27.21-170.2.56.fc10.x86_64.img
quiet
Once again, this type of change need a restart to be fully effective.
3. Prefer ramdisk for temporary filesystems
This is something I've been using for a while, even with standard HD, for machines where the amount of available RAM is important. For standard HD, the reasoning was that reading the RAM was faster than reading the disk. With SSD, this performance argument can be discussed, but still, you will increase your disk's life expectancy by moving temporary filesystems that are frequently read to the RAM. Another advantage is that these filesystems are removed then re-mounted at every reboot, meaning that you are less likely to have to clean them up manually.
Again, the changes are to be made in /etc/fstab. Here is a sample from my Ubuntu fstab:
$ grep tmpfs /etc/fstab
tmpfs /tmp tmpfs defaults,noatime,mode=1777,size=1024M 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777,size=512M 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777,size=1024M 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777,size=512M 0 0
Limiting the size of these tmpfs directly in /etc/fstab is likely a bit of an overkill, but these temporary filesystems (especially /tmp) can be filled up pretty quickly (by an application core dump for instance) and you surely don't want to see all your RAM eaten up in such case...
2
I have to admit it took me several tries to have the internal microphone working on my Thinkpad X300. In case you're looking for some working settings gnome-volume-control, here are the one that work on my Jaunty config:
NB: the Skype options that do work with the above settings are:
NB: the Skype options that do work with the above settings are:
0
Coming from a sysadmin background, I appreciate having a constant view on the OS metrics like CPU and memory usage, disk space left, etc... There are plenty of tools available out there to do that, but none as simple and as flexible as conky. I like it so much that it actually runs in the background of all my Linuxes (desktops as well as servers). My main usage is sysadmin-oriented, but there are plenty of other functionalities available, like displaying the weather forecasts, or interfacing with Amarok or Rhythmbox to show the details of the song currently playing, etc... the possibilities are infinite.
All you have have to do is create a ~/.conkry file in the user's home directory and have your your session manager start the conky deamon automatically. Below is a an exemple how of to do that for the Ubuntu Gnome desktop, with the resulting little panel on the bottom left of the destop:
Posted on 5/03/2009 07:51:00 pm by Nicolas and filed under
conky,
how-to,
linux,
monitoring,
open source,
tool
To keep on with the applications/tools I could not live without (see below for bootchart), here comes a quick post on conky.Coming from a sysadmin background, I appreciate having a constant view on the OS metrics like CPU and memory usage, disk space left, etc... There are plenty of tools available out there to do that, but none as simple and as flexible as conky. I like it so much that it actually runs in the background of all my Linuxes (desktops as well as servers). My main usage is sysadmin-oriented, but there are plenty of other functionalities available, like displaying the weather forecasts, or interfacing with Amarok or Rhythmbox to show the details of the song currently playing, etc... the possibilities are infinite.
All you have have to do is create a ~/.conkry file in the user's home directory and have your your session manager start the conky deamon automatically. Below is a an exemple how of to do that for the Ubuntu Gnome desktop, with the resulting little panel on the bottom left of the destop:
1
The easiest tool to profile and analyse a machine's boot sequence is probably bootchart. It will run on all Unix distros and will generate easy-to-read graphs.
Basics on using bootchart on Ubuntu
The bootchart package is available in the Ubuntu repositories, so it can be installed either through apt-get or Synaptic. After you install it, all you have to do to generate your first bootchart is restart (dead easy, eh?!). The graph is stored in /var/log/bootchart as a PNG file. Each bootchart is listed with the hostname, date and a number sorting charts generated on the same day. An example bootchart will look like this:
This graphically shows you what your computer is doing in terms of CPU, IO, and processes during the boot procedure. The chart itself contains 4 sections:
-description of the system
-CPU graph
-I/O graph
-a Gantt-like chart showing the details and sequence of the running processes
By default, bootchart stops recording when it has detected gdm has started, so be aware that the resulting charts are unlikely to include the extra time gdm takes to start up and show you a usable desktop. But usually by that point the init is done and the remaining optimizations need to be done in the window manager (Gnome, KDE, XFCE, etc...) rather than in the system init scripts. The most immediately useful purpose of bootchart is to objectively discover the boot time, and where the bottlenecks are. For example, the boot chart below, captured on the same machine with the same OS and parameters shows a total boot time of 14 seconds, which isn't bad, but still almost double than above!!
Ideally, you'd want your init to max out the CPU at 100% as much as possible. If the CPU is not pegged at 100% and there is a high I/O wait, that usually means your CPU is idling while it is waiting for the disk to return data. But if your CPU is idle and the I/O are limited, you'd want to investigate... Basically, in the case above, you'll quickly notice a 5 seconds "dead zone", with 2 suspicious processes named "resume" and "sleep". In fact, this 5 seconds delay makes up for most of the difference between the two boot sequences.
So where can they come from and what should be done to optimize the boot time? Well, first you'll notice the 5 seconds sleep occurs before the rc scripts, so no need to fiddle with your startup scripts. Then you'll notice they come in sequence after the console_setup, which points you to the initramfs scripts. Once that is said, the solution is obvious: the "sleep 5" comes from the initramfs script trying to mount the RAM. Having a look at the logs will confirm this and give some indications as to what is failing. This behavior could typically be caused by the fact that you have somehow modified your swap partition (new kernel setup? swap partition resize?) and thus initramfs-tools cannot find the partition through the old UUID...
PS: Once you are done playing with bootchart and with your optimizations, you'll probably want to un-install the package so you don't keep writing PNG files on every boot...
Posted on 5/03/2009 04:51:00 pm by Nicolas and filed under
bootchart,
how-to,
linux,
open source,
tool,
ubuntu
Boot times have become quite a hot topic, especially since the release of Ubuntu 9.04, which emphasised on shorter boot times - "some as short as 25 seconds" as per the official announcement.The easiest tool to profile and analyse a machine's boot sequence is probably bootchart. It will run on all Unix distros and will generate easy-to-read graphs.
Basics on using bootchart on Ubuntu
The bootchart package is available in the Ubuntu repositories, so it can be installed either through apt-get or Synaptic. After you install it, all you have to do to generate your first bootchart is restart (dead easy, eh?!). The graph is stored in /var/log/bootchart as a PNG file. Each bootchart is listed with the hostname, date and a number sorting charts generated on the same day. An example bootchart will look like this:
This graphically shows you what your computer is doing in terms of CPU, IO, and processes during the boot procedure. The chart itself contains 4 sections:
-description of the system
-CPU graph
-I/O graph
-a Gantt-like chart showing the details and sequence of the running processes
By default, bootchart stops recording when it has detected gdm has started, so be aware that the resulting charts are unlikely to include the extra time gdm takes to start up and show you a usable desktop. But usually by that point the init is done and the remaining optimizations need to be done in the window manager (Gnome, KDE, XFCE, etc...) rather than in the system init scripts. The most immediately useful purpose of bootchart is to objectively discover the boot time, and where the bottlenecks are. For example, the boot chart below, captured on the same machine with the same OS and parameters shows a total boot time of 14 seconds, which isn't bad, but still almost double than above!!
Ideally, you'd want your init to max out the CPU at 100% as much as possible. If the CPU is not pegged at 100% and there is a high I/O wait, that usually means your CPU is idling while it is waiting for the disk to return data. But if your CPU is idle and the I/O are limited, you'd want to investigate... Basically, in the case above, you'll quickly notice a 5 seconds "dead zone", with 2 suspicious processes named "resume" and "sleep". In fact, this 5 seconds delay makes up for most of the difference between the two boot sequences.
So where can they come from and what should be done to optimize the boot time? Well, first you'll notice the 5 seconds sleep occurs before the rc scripts, so no need to fiddle with your startup scripts. Then you'll notice they come in sequence after the console_setup, which points you to the initramfs scripts. Once that is said, the solution is obvious: the "sleep 5" comes from the initramfs script trying to mount the RAM. Having a look at the logs will confirm this and give some indications as to what is failing. This behavior could typically be caused by the fact that you have somehow modified your swap partition (new kernel setup? swap partition resize?) and thus initramfs-tools cannot find the partition through the old UUID...
PS: Once you are done playing with bootchart and with your optimizations, you'll probably want to un-install the package so you don't keep writing PNG files on every boot...
0
So here is an example of how this can be done:
1. create a file /etc/hal/fdi/policy/mouse-wheel.fdi with a content like:
2. restart HAL, check the config is taken into account then restart your X server
Posted on 4/27/2009 07:14:00 pm by Nicolas and filed under
how-to,
linux,
open source,
trackpoint,
ubuntu,
X300
After yesterday's update on evdev on Fedora 10, I starting wondering if this could be portable on Ubuntu to configure the old EmulateWheel functionalities. evdev was indeed ported to Ubuntu, so, provided the version was compatible (>2.1) then there was no reason why this would not be valid... And indeed it is! It also offers the huge advantage ofnot having to play with the xorg.conf file, which is always a risk given it impacts the behaviour of the whole X server.So here is an example of how this can be done:
1. create a file /etc/hal/fdi/policy/mouse-wheel.fdi with a content like:
2. restart HAL, check the config is taken into account then restart your X server
0
But it's probably worth another separate post...
It still evolves around the topic of configuring the "how wonderful!" middle button horizontal scrolling. I was not so sure how I had worked it out on Fedora 10, so I just rebooted to this OS and confirmed that the tweak with the "mouse" driver does not work on this distro. As said below, it *does* work with Fedora 9 though. What happens is that this button is "emulated" via HAL. No point looking for the xorg.conf file as there should not be any such file...
To configure the TrackPoint scroll, you have to:
1. Edit the config file /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi
Basically, just add lines similar to the following in the relevant part of the file:
... by relevant, I mean you'll have to make sure you're in the correct section of the file as markup languages are sensitive to that... If you don't see what this means, have a look at the markup language article on Wikipedia.
2. Then restart HAL and check the modifications appear among the
device options that you can check via the output of lshal. Typically:
[nicolas@munin ~]$ lshal | grep TrackPoint
info.product = 'TPPS/2 IBM TrackPoint' (string)
input.product = 'TPPS/2 IBM TrackPoint' (string)
3. Finally restart the X server and enjoy some nice and smooth vertical scrolling!
NDLR: once again, from the above extract you'll notice the FDI file does not enable horizontal scrolling... same reason as below: Firefox would understand it has a backward/forward instruction...
For reference, here is the original article on Thinkwiki.
I am also aware that it used to *not* work on earlier versions of evdev, so you'll have to make you run at least version 2.1.
Posted on 4/26/2009 05:34:00 pm by Nicolas and filed under
fedora,
how-to,
linux,
open source,
trackpoint,
X300
It's a sort of edit to my previous post - see just below for the original story ;)But it's probably worth another separate post...
It still evolves around the topic of configuring the "how wonderful!" middle button horizontal scrolling. I was not so sure how I had worked it out on Fedora 10, so I just rebooted to this OS and confirmed that the tweak with the "mouse" driver does not work on this distro. As said below, it *does* work with Fedora 9 though. What happens is that this button is "emulated" via HAL. No point looking for the xorg.conf file as there should not be any such file...
To configure the TrackPoint scroll, you have to:
1. Edit the config file /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi
Basically, just add lines similar to the following in the relevant part of the file:
... by relevant, I mean you'll have to make sure you're in the correct section of the file as markup languages are sensitive to that... If you don't see what this means, have a look at the markup language article on Wikipedia.2. Then restart HAL and check the modifications appear among the
device options that you can check via the output of lshal. Typically:
[nicolas@munin ~]$ lshal | grep TrackPoint
info.product = 'TPPS/2 IBM TrackPoint' (string)
input.product = 'TPPS/2 IBM TrackPoint' (string)
3. Finally restart the X server and enjoy some nice and smooth vertical scrolling!
NDLR: once again, from the above extract you'll notice the FDI file does not enable horizontal scrolling... same reason as below: Firefox would understand it has a backward/forward instruction...
For reference, here is the original article on Thinkwiki.
I am also aware that it used to *not* work on earlier versions of evdev, so you'll have to make you run at least version 2.1.
0
Also, I find the middle button quite practical for scrolling. This can be configured via the xorg mouse input driver. Unfortunately, this is no longer possible with recent Linux distros (typically Fedora starting from version 9 or also Ubuntu from 8.10), the evdev driver is taking precedence, even though another driver is explicitly configured in xorg.conf (explanations from Red Hat developers can be found in this bug opened against Fedora 9). The correct solution is to disable this auto-detection by turning the "AutoAddDevices" server flag to "false".
Here are the relevant sections in my /etc/X11/xorg.conf:
Section "ServerFlags"
Option "AutoAddDevices" "false"
EndSection
Section "InputDevice"
Identifier "Trackpoint"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ExplorerPS/2"
Option "Emulate3Buttons" "off"
Option "EmulateWheel" "on"
Option "EmulateWheelTimeOut" "200"
Option "EmulateWheelButton" "2"
Option "YAxisMapping" "4 5"
# Option "XAxisMapping" "6 7"
Option "ZAxisMapping" "4 5"
EndSection
Please note from the above that the middle button is only enabled for vertical scrolling. I'm barely using horizontal scrolling and it gets interpreted in Firefox as backwards/forwards which can get quickly annoying : ) Hence its being commented.
Posted on 4/26/2009 03:22:00 pm by Nicolas and filed under
fedora,
how-to,
linux,
open source,
trackpoint,
ubuntu,
X300
I've been asked recently my prefered settings for the pointing devices on Thinkpads... I'm addicted to the Trackpoint (the little red strawberry encrusted between the G, H and B keys) and the Trackpad (the flat sensitive surface also referred to as touchpad) generally disrupts me as I tend to accidentally touch it with the palm of my hand, so I generally disable it from the BIOS.Also, I find the middle button quite practical for scrolling. This can be configured via the xorg mouse input driver. Unfortunately, this is no longer possible with recent Linux distros (typically Fedora starting from version 9 or also Ubuntu from 8.10), the evdev driver is taking precedence, even though another driver is explicitly configured in xorg.conf (explanations from Red Hat developers can be found in this bug opened against Fedora 9). The correct solution is to disable this auto-detection by turning the "AutoAddDevices" server flag to "false".
Here are the relevant sections in my /etc/X11/xorg.conf:
Section "ServerFlags"
Option "AutoAddDevices" "false"
EndSection
Section "InputDevice"
Identifier "Trackpoint"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ExplorerPS/2"
Option "Emulate3Buttons" "off"
Option "EmulateWheel" "on"
Option "EmulateWheelTimeOut" "200"
Option "EmulateWheelButton" "2"
Option "YAxisMapping" "4 5"
# Option "XAxisMapping" "6 7"
Option "ZAxisMapping" "4 5"
EndSection
Please note from the above that the middle button is only enabled for vertical scrolling. I'm barely using horizontal scrolling and it gets interpreted in Firefox as backwards/forwards which can get quickly annoying : ) Hence its being commented.
0
The relevant extract from the Release Notes reads:
Just to make it completely clear: the dontzap package is NOT installed by default, which means you will have to install it from the depots before enabling it!
Posted on 4/26/2009 09:13:00 am by Nicolas and filed under
gnome,
how-to,
linux,
open source,
ubuntu
Yes, apparently, they have done it, despite all the Linux fanatics shouting this would be a regression just to please newbies that are not familiar with it...The relevant extract from the Release Notes reads:
Ctrl-Alt-Backspace is now disabled, to reduce issues experienced by users who accidentally trigger the key combo. Users who do want this function can enable it in their xorg.conf, or via the command dontzap –disable.Well, at least there's a positive since you can install an additional package that will re-enable this powerful key combination to restart the X server when needed.
Just to make it completely clear: the dontzap package is NOT installed by default, which means you will have to install it from the depots before enabling it!
