Updating Intel CPU microcode from Gentoo Linux

Updates to CPU microcode have to be re-applied each time the computer is booted, because the memory updated is volatile (despite the term ‘firmware’ also being used for microcode). Below I describe two methods (there are others) of applying CPU microcode updates in Gentoo Linux. My main laptop has an Intel CPU so I focus here on Intel microcode updates. The procedure is almost the same for AMD CPUs, but the AMD CPU binary update file (‘binary blob’) is installed by the sys-kernel/linux-firmware package.

METHOD 1: Use an initscript in the boot runlevel with a kernel module

Until recently I was using an initscript named microcode_ctl, which uses a program (also named microcode_ctl) and a kernel module (microcode.ko) to update the Intel CPU microcode during boot. This was straightforward to set up in Gentoo Linux:

1. Build the kernel with CONFIG_MICROCODE=m and CONFIG_MICROCODE_INTEL=y.

This is what I configured in the kernel:

# grep -i microcode /usr/src/linux/.config
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set

2. Install two packages and add an OpenRC initscript to the boot runlevel:

# emerge microcode-data microcode-ctl
# rc-update add microcode_ctl boot

The initscript will re-update the CPU microcode every time the computer is rebooted.

Installing the package microcode-data downloads a compressed file (microcode-yyyymmdd.tgz) from the Intel Download Centre, extracts a text file named microcode.dat and parses the text in it to create a set of binary ‘blobs’ in the directory /lib/firmware/intel-ucode/ (one blob for each model of Intel CPU).

Before rebooting, check the revision of microcode in the CPU (the microcode revision is shown for each logical core):

# This is for the Core i7-720QM CPU in my Compal NBLB2 laptop.
# grep microcode /proc/cpuinfo
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3

If I use this method of updating the microcode, the initscript runs after the message ‘Waiting for uevents to be processed ...‘ is displayed on VT1 while booting. After the module has performed the update, the microcode revision in the CPU’s logical cores has changed:

# grep microcode /proc/cpuinfo
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
# dmesg | grep microcode
[ 15.749533] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[ 15.834790] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[ 15.835530] microcode: CPU0 updated to revision 0x7, date = 2013-08-20
[ 15.835544] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[ 15.835587] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[ 15.836241] microcode: CPU1 updated to revision 0x7, date = 2013-08-20
[ 15.836257] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[ 15.836299] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[ 15.836953] microcode: CPU2 updated to revision 0x7, date = 2013-08-20
[ 15.837063] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[ 15.837128] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[ 15.837767] microcode: CPU3 updated to revision 0x7, date = 2013-08-20
[ 15.837857] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[ 15.837968] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[ 15.838605] microcode: CPU4 updated to revision 0x7, date = 2013-08-20
[ 15.838634] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[ 15.838681] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[ 15.839357] microcode: CPU5 updated to revision 0x7, date = 2013-08-20
[ 15.839390] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[ 15.839453] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[ 15.840121] microcode: CPU6 updated to revision 0x7, date = 2013-08-20
[ 15.840180] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[ 15.840274] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[ 15.840911] microcode: CPU7 updated to revision 0x7, date = 2013-08-20
[ 15.840997] microcode: Microcode Update Driver: v2.00 , Peter Oruba
[ 26.940662] microcode: Microcode Update Driver: v2.00 removed.

Notice that the microcode update occurred in the period from 15.749533 to 15.840997 seconds after the kernel started running, and the microcode was updated from revision 0×3 to 0×7.

METHOD 2: Use the kernel’s built-in Early Update driver

Although the initscript method works perfectly in my case and the update is complete by the time the laptop has finished booting, I wanted to update the CPU microcode earlier. Updating microcode early can fix CPU issues before they occur during kernel boot time. It is possible to configure the kernel to update microcode early by setting CONFIG_MICROCODE_EARLY and CONFIG_MICROCODE_INTEL_EARLY in the kernel. See /usr/src/linux/Documentation/x86/early-microcode.txt for details. That document only refers to initrd files, but, in fact, it also applies to initramfs files.

The Early Update kernel driver will align misaligned microcode data (see Notes on Intel Microcode Updates and [PATCH 7/8] x86, microcode, intel: guard against misaligned microcode data), but you can pre-align the data yourself if you wish by using a .padding file as explained on the latter page. However I did not bother doing that; I leave the Early Update kernel driver to take care of aligning the microcode, as the time penalty to align it is small compared to the overall update time.

It is possible to download the latest compressed Intel microcode data file yourself from the Intel Download Centre. The latest file released is microcode-20140913.tgz at the time of writing. It contains only a text file named microcode.dat, not the required binary blob. Actually, microcode.dat contains data in text format for several Intel CPU models. The microcode.dat file should reside in the directory /lib/firmware/. In the case of Gentoo it is a waste of time manually obtaining the microcode.dat file this way, as there is no tool in Gentoo specifically for creating a binary blob from the microcode.dat file. Therefore just install the Gentoo package sys-apps/microcode-data (which you would have done in any case if you were using the microcode_ctl initscript to load the microcode update to the CPU) and it will automatically download the compressed file from the Intel Web site, unpack it, copy the file microcode.dat to /lib/firmware/ and create the binary blobs in the directory /lib/firmware/intel-ucode/.

You may have read of a tool named intel-microcode2ucode used in other Linux distributions. Gentoo does not build intel-microcode2ucode (the source code of which is included in the Gentoo package sys-apps/microcode-data) as a stand-alone tool, but the act of installing microcode-data creates the required binary files in /lib/firmware/intel-ucode/. i.e. the following command does the complete job:

# emerge microcode-data

Check that the microcode files for the various CPU models were created when microcode-data was installed:

# ls /lib/firmware/intel-ucode/
06-03-02 06-05-03 06-06-0d 06-08-01 06-09-05 06-0b-04 06-0f-02 06-0f-0b 06-17-07 06-1c-02 06-1e-05 06-2a-07 06-3a-09 06-3e-07 0f-00-07 0f-02-05 0f-03-02 0f-04-03 0f-04-09 0f-06-05
06-05-00 06-06-00 06-07-01 06-08-03 06-0a-00 06-0d-06 06-0f-06 06-0f-0d 06-17-0a 06-1c-0a 06-25-02 06-2d-06 06-3c-03 06-3f-02 0f-00-0a 0f-02-06 0f-03-03 0f-04-04 0f-04-0a 0f-06-08
06-05-01 06-06-05 06-07-02 06-08-06 06-0a-01 06-0e-08 06-0f-07 06-16-01 06-1a-04 06-1d-01 06-25-05 06-2d-07 06-3e-04 06-45-01 0f-01-02 0f-02-07 0f-03-04 0f-04-07 0f-06-02
06-05-02 06-06-0a 06-07-03 06-08-0a 06-0b-01 06-0e-0c 06-0f-0a 06-17-06 06-1a-05 06-1e-04 06-26-01 06-2f-02 06-3e-06 06-46-01 0f-02-04 0f-02-09 0f-04-01 0f-04-08 0f-06-04

I looked in /proc/cpuinfo to confirm the model of CPU in my laptop:

$ grep model /proc/cpuinfo
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz

I was able to find the CPUID and other data for that model from the Web site CPU World:

CPUID 106E5
Family 6 (06 hex)
Model 30 (1E hex)
Stepping 5 (05 hex)

Therefore the file /lib/firmware/intel-ucode/06-1e-05 (Family-Model-Stepping in hexadecimal) is the binary blob for my specific CPU model.

First I used genkernel to rebuild the current kernel with CONFIG_MICROCODE_EARLY=y and CONFIG_MICROCODE_INTEL_EARLY=y.

# mount /dev/sda3 /boot # /boot is on a separate partition in my installation.

# Backup the files of the existing kernel image and initramfs:
# cp /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak
# cp /boot/kernel-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/kernel-genkernel-x86_64-3.17.1-gentoo-r1.bak
# cp /boot/System.map-genkernel-x86_64-3.17.1-gentoo-r1 /boot/fitzcarraldo/System.map-genkernel-x86_64-3.17.1-gentoo-r1.bak

# Now rebuild the kernel:
# zcat /proc/config.gz > /usr/src/config
# genkernel --kernel-config=/usr/src/config --menuconfig --splash=Emergance --disklabel all # Set CONFIG_MICROCODE_EARLY and CONFIG_MICROCODE_INTEL_EARLY.
# emerge @module-rebuild
# grub2-mkconfig -o /boot/grub/grub.cfg

This is what I have after rebuilding the kernel:

# grep -i microcode /usr/src/linux/.config
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
# CONFIG_MICROCODE_AMD_EARLY is not set
CONFIG_MICROCODE_EARLY=y

Then I prepended the cpio file containing the binary blob to the initramfs file (see the instructions in /usr/src/linux/Documentation/x86/early-microcode.txt):

# mkdir -p /boot/initrd/kernel/x86/microcode
# cd /boot/initrd
# cp /lib/firmware/intel-ucode/06-1e-05 kernel/x86/microcode/GenuineIntel.bin
# find . | cpio -o -H newc >../ucode.cpio
# cd ..
# cp /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak.early # Backup the recently-built initramfs first.
# cat ucode.cpio /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1 >/boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.ucode
# cp /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.ucode /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1
# rm /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.ucode
# umount /boot
# rc-update del microcode_ctl boot # Disable the initscript so that microcode.ko will no longer be used when I reboot.

Reboot.

Use the following commands to check if the CPU microcode has been updated:

# grep microcode /proc/cpuinfo
# dmesg | grep microcode

There is no point looking in /var/log/messages, because syslog-ng has not started running when the early microcode update occurs.

# grep microcode /proc/cpuinfo
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
# dmesg | grep microcode
[ 0.252234] CPU1 microcode updated early to revision 0x7, date = 2013-08-20
[ 0.265389] CPU2 microcode updated early to revision 0x7, date = 2013-08-20
[ 0.278696] CPU3 microcode updated early to revision 0x7, date = 2013-08-20
[ 1.888471] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888481] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888491] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888498] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888506] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888515] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888523] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888534] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888597] microcode: Microcode Update Driver: v2.00 , Peter Oruba

Compare the update time in the dmesg output above with the update time in the dmesg output for an update done using the initscript (Method 1, further up). With the Early Update driver, the update was complete in 0.278696 seconds. With the initscript and kernel module, the update was complete in 15.840911 seconds. Quite a difference.

I do not know why the dmesg output does not have a message for Core 0 in the group of messages before 1.000000 second elapsed. The message at 1.888471 shows it was updated, so I assume the kernel ring buffer was not large enough and the message was overwritten. Cores 1, 2 and 3 were updated in the period between 0.252234 and 0.278696 seconds, and then all eight logical cores are listed in the period between 1.888471 and 1.888597 seconds. I’m not sure of the precise messages expected, but they look similar to the results obtained by users in other distributions, such as the following CrunchBang Linux output:

$ uname -a
Linux crunchbang 3.10-12.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Sun Sep 15 17:29:51 UTC 2013 x86_64 GNU/Linux
$ dmesg | grep microcode
CPU0 microcode updated early to revision 0x19, date = 2013-06-13
CPU1 microcode updated early to revision 0x19, date = 2013-06-13
CPU2 microcode updated early to revision 0x19, date = 2013-06-13
CPU3 microcode updated early to revision 0x19, date = 2013-06-13
microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x19
microcode: Microcode Update Driver: v2.00 , Peter Oruba
$ cat /proc/cpuinfo | grep microcode | uniq
microcode : 0x19

Finally, I deleted the temporary work directory and files:

# mount /dev/sda3 /boot
# rm -rf /boot/initrd/
# rm /boot/ucode.cpio
# rm /home/fitzcarraldo/kernel-genkernel-x86_64-3.17.1-gentoo-r1.bak
# rm /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak
# rm /home/fitzcarraldo/System.map-genkernel-x86_64-3.17.1-gentoo-r1.bak

# Optional. Could keep the following file in case Intel issues a new microcode.dat file and I want to create a new concatenated initramfs file:
# rm /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak.early

Of course, you will need to repeat the whole process and create a new concatenated initramfs file in any of the following cases:

a) you build a new version of the kernel;

b) you rebuild the current version of the kernel with different configuration settings;

c) Intel releases a new version of the microcode (which does not happen often).

It seems the Early Update driver still has some bugs, so I expect the message output to change in future kernel releases. See e.g. [PATCH 0/8] x86, microcode, intel: fixes and enhancements, [PATCH 3/8] x86, microcode, intel: clarify log messages, Re: [PATCH 3/8] x86, microcode, intel: clarify log messages and a bunch of other very recent posts in the kernel mailing list regarding the Early Update driver and CPU microcode updates.

Installing and using the Pipelight browser plug-in with Firefox 30 for Linux

pipelight-logoI use Gentoo Linux (~amd64) on my main laptop. Although I do not use Netflix or any of the other streaming video services that require the Microsoft Silverlight browser plug-in, I do need to use a browser with the Silverlight plug-in to access an office Intranet site. So I was interested in installing the Pipelight plug-in.

Although Pipelight works with most of the Silverlight test sites I have found on the Web, I cannot get it to work with the above-mentioned office Intranet site, which is why I ended up installing Firefox for Windows and Silverlight in WINE (see my previous post). Anyway, below I explain how I installed and configured Pipelight 0.2.7.1 and Firefox 30.0 for Linux. Even if you use a different Linux distribution to me, almost all of this post will still be relevant; only the package installation commands will differ.

Google Chrome 34 and onwards does not support NPAPI, so Pipelight does not work any more with Chrome. Actually, Mozilla has disabled some NPAPI support by default in Firefox 30: with the exception of the Flash plug-in you have to explicitly give permission for plug-ins to be activated via Click-to-Activate (also known as Click-to-Play). You can configure how Firefox Click-to-Activate behaves via Open menu > Add-ons > Plugins (choose either ‘Ask to Activate’, ‘Always Activate’ or ‘Never Activate’). See ‘Issues related to plugins – 4.1 Click to Play in Mozilla browser versions 23 and above‘ on the mozillaZine Website and ‘How to always activate a plugin for a trusted website‘ on the Mozilla Support Website.

I updated an existing Pipelight ebuild so that it will install the latest version of Pipelight (0.2.7.1) via a Portage local overlay. You can download the new ebuild from Gentoo Bugzilla Bug Report No. 481596 (see Comment 40). I can only get it to merge by using the -binary-pluginloader USE flag. [Update August 18, 2014: The package is now in the main Portage tree, at least for ~amd64]

Installation

Install Firefox if it has not already been installed:

root # emerge firefox

Install Pipelight (installation fails unless I disable binary-pluginloader):

root # USE="-binary-pluginloader" emerge pipelight

Install WINE with the Compholio patches:

root # USE="pipelight" emerge wine

As you can see below, I have wine-1.7.21 and pipelight-0.7.2.1 installed.

user $ eix -I wine
[I] app-emulation/wine
Available versions: 1.2.3^t (~)1.3.28^t 1.4.1^t 1.6.1^t 1.6.2^t (~)1.7.0^t (~)1.7.3^t (~)1.7.4^t (~)1.7.8^t (~)1.7.9^t (~)1.7.10^t (~)1.7.11^t (~)1.7.12^t (~)1.7.13^t (~)1.7.14^t (~)1.7.15^t (~)1.7.16^t (~)1.7.17^t (~)1.7.18^t (~)1.7.19-r1^t (~)1.7.20^t (~)1.7.21^t **9999^t {+X (+)alsa capi cups custom-cflags dbus dos (+)fontconfig +gecko gnutls gphoto2 gsm gstreamer jack (+)jpeg lcms ldap +mono mp3 nas ncurses netapi nls odbc openal opencl +opengl osmesa (+)oss +perl pipelight (+)png +prelink pulseaudio +realtime +run-exes samba scanner selinux (+)ssl test +threads +truetype (+)udisks v4l +win32 +win64 xcomposite xinerama (+)xml ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_X86="(+)32 (+)64 x32" ELIBC="glibc" LINGUAS="ar bg ca cs da de el en en_US eo es fa fi fr he hi hr hu it ja ko lt ml nb_NO nl or pa pl pt_BR pt_PT rm ro ru sk sl sr_RS@cyrillic sr_RS@latin sv te th tr uk wa zh_CN zh_TW"}
Installed versions: 1.7.21^t(13:39:36 06/07/14)(X alsa cups fontconfig gecko gphoto2 gsm jpeg lcms mp3 ncurses nls openal opengl perl pipelight png prelink pulseaudio realtime run-exes scanner ssl threads truetype udisks v4l xinerama xml -capi -custom-cflags -dos -gstreamer -ldap -mono -netapi -odbc -opencl -osmesa -oss -samba -selinux -test -xcomposite ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_X86="32 64 -x32" ELIBC="glibc" LINGUAS="en pt_BR -ar -bg -ca -cs -da -de -el -en_US -eo -es -fa -fi -fr -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -nl -or -pa -pl -pt_PT -rm -ro -ru -sk -sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th -tr -uk -wa -zh_CN -zh_TW")
Homepage: http://www.winehq.org/
Description: Free implementation of Windows(tm) on Unix

user $ eix -I pipelight
[I] www-plugins/pipelight
Available versions: (~)0.2.3[1] (~)0.2.6[2] (~)0.2.7.1[2] {adobereader +binary-pluginloader flash foxitpdf grandstream installation-dialogs npactivex roblox shockwave +silverlight static unity3d}
Installed versions: 0.2.7.1[2](21:57:35 10/07/14)(silverlight -adobereader -binary-pluginloader -flash -foxitpdf -grandstream -installation-dialogs -npactivex -roblox -shockwave -static -unity3d)
Homepage: http://fds-team.de/cms/index.html https://launchpad.net/pipelight
Description: A browser plugin which allows one to use windows-only plugins inside Linux browsers.

[1] "sabayon" /var/lib/layman/sabayon
[2] "local_overlay" /usr/local/portage

Now update the dependency-installer script and enable the plug-in:

user $ sudo pipelight-plugin --update # sudo has to be used for this command only.
user $ pipelight-plugin --enable silverlight

Applies to AMD ATI GPUs only: My main laptop has an AMD ATI HD 5850 GPU, and hardware acceleration causes Firefox to hang when the Pipelight plug-in is enabled, so I have to disable hardware acceleration:

user $ cp /usr/share/pipelight/configs/pipelight-silverlight5.1 ~/.config/

Edit the Pipelight configuration file:

user $ nano ~/.config/pipelight-silverlight5.1

In order to force GPU acceleration uncomment the line:
overwriteArg = enableGPUAcceleration=true

In order to disable GPU acceleration (even if your graphic driver is probably supported) uncomment the line:
overwriteArg = enableGPUAcceleration=false

Instead of disabling GPU hardware acceleration in the Pipelight configuration file (pipelight-silverlight5.1), I could have instead done it each time I launch Firefox by entering the following command:

user $ PIPELIGHT_GPUACCELERATION=0 firefox

But I prefer to be able to enter just the following command:

user $ firefox

or to launch Firefox from the as-installed entry for Firefox in the Desktop Environment’s launcher menu.

After launching Firefox for the first time, a series of pop-up windows will show that the Silverlight plug-in is being installed. Once the final pop-up window has closed, install the Firefox extension User Agent Overrider (do not install User Agent Switcher or any other user agent selection extension for Firefox), click on the down-arrow of the User Agent Overrider icon in Firefox and select ‘Windows / Firefox 29′ from the pull-down menu. I also selected ‘Preferences…’ and added another user agent string to the end of the list:

# Custom
Windows / Firefox 15: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120427 Firefox/15.0a1

Check that the plug-in is installed correctly

Enter about:plugins in the Firefox Address bar to check which plug-ins are installed, their version and current state.

Use the Pipelight diagnostic page to check the plug-in is working.

Pipelight options

To see what commands the Pipelight plug-in supports, enter the following command in a Konsole/Terminal window:

user $ pipelight-plugin --help

Further information

Below are some links to Silverlight tests and other information regarding Pipelight and Silverlight.

Silverlight test pages

Silverlight Version Test

Bubblemark animation test

Silverlight Project Test Page | Deep Zoom

Silverlight DRM Test (Select ‘No DRM’ because the following bug report says that the Silverlight DRM test at the aforementioned Web page is broken and Microsoft will not fix it: Bug 762056.)

Becky’s Silverlight Test Site

Microsoft Silverlight – IIS Smooth Streaming Demo

Experience IIS Smooth Streaming

Silverlight Project Test Page | Deep Zoom Tag Browser

Microsoft Case Studies

Silverlight Demos

Here is an article on Netflix’s intention to dump the awful Silverlight plug-in:
Netflix to dump Silverlight, Microsoft’s stalled technology

Background information on the Pipelight project

This presentation was made by the Pipelight developers:
Pipelight – Windows browser plugins on Linux

Useful pages on the Pipelight Web site

Pipelight | News

This page, about selecting a User Agent String that will work, is important to read if you’re having problems:
Pipelight | Installation – User Agent

Background reading on User Agent Strings

How to Change Your Browser’s User Agent Without Installing Any Extensions

The IE10 User-Agent String

You can find out your current user agent string by using the following link:
What’s My User Agent?

Alternative to using Pipelight

If you still have trouble viewing Web pages that use Silverlight, you might like to try an alternative approach: use Firefox for Windows and the Silverlight plug-in in WINE. See my previous blog post Installing Firefox for Windows and the Silverlight plug-in in WINE.

Work-around if 64-bit Google Earth crashes in Gentoo Linux

Google Earth 5.2.1.1588 was the last version of Google Earth for Linux that worked on my main laptop running 64-bit Gentoo Linux. Even the Panoramio photos were displayed (a common complaint amongst users of Google Earth for Linux). But every subsequent version crashed when I launched it. The latest version, 7.1.2.2041, is no exception:

$ googleearth
[0403/012031:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses()
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:WARNING:backend_impl.cc(1875)] Destroying invalid entry.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0403/012033:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
Google Earth has caught signal 11.



We apologize for the inconvenience, but Google Earth has crashed.
This is a bug in the program, and should never happen under normal
circumstances. A bug report and debugging data have been written
to this text file:

/home/fitzcarraldo/.googleearth/crashlogs/crashlog-533ca953.txt

Please include this file if you submit a bug report to Google.

Now, the Google Earth installation package bundles the libraries it needs, so they are used instead of the ‘native’ libraries installed on your machine. A Linux user going by the moniker amirpli worked out how to enable Google Earth for Linux to use the native Qt libraries rather than the Qt libraries bundled with Google Earth, and posted instructions for a number of distributions (see, for example, Comment 9 in Gentoo Bugzilla Bug Report No. 490066). However, even if I apply amirpli‘s fix, Google Earth on my main laptop crashed with almost the same error message as above. Looking through the crash log file that Google Earth generates, I see the following line, which makes me suspect that Google Earth cannot work with the closed-source AMD ATI Catalyst driver (a.k.a. FGLRX):

./libbase.so(_ZN5earth15GfxCardInfoUnix25GetGraphicsCardMemoryInMBERi+0xe)[0x7f011b3e654e]

I noticed a few posts by users of other distributions in various forums saying that they had installed the 32-bit version of Google Earth in their 64-bit (multilib) installations, so I decided to try that in Gentoo. I hacked the ebuild of version 7.1.2.2041 to force it to install the 32-bit version of Google Earth on my 64-bit multilib installation, and installed it via a local overlay.

The hacked ebuild has the following changes from the stock 7.1.2.2041 ebuild:

a) Replace:

SRC_URI="x86? ( http://dl.google.com/dl/earth/client/current/google-earth-stable_current_i386.deb
                       -> GoogleEarthLinux-${PV}_i386.deb )
       amd64? ( http://dl.google.com/dl/earth/client/current/google-earth-stable_current_amd64.deb
                       -> GoogleEarthLinux-${PV}_amd64.deb )"

with:

SRC_URI="http://dl.google.com/dl/earth/client/current/google-earth-stable_current_i386.deb
                       -> GoogleEarthLinux-${PV}_i386.deb"


b) Replace:

unpack_deb GoogleEarthLinux-${PV}_$(usex amd64 "amd64" "i386").deb

with:

unpack_deb GoogleEarthLinux-${PV}_i386.deb


c) Replace:

patchelf --set-interpreter /lib/ld-linux$(usex amd64 "-x86-64" "").so.2 ${PN}-bin || die "patchelf failed"

with:

patchelf --set-interpreter /lib/ld-linux.so.2 ${PN}-bin || die "patchelf failed"


If you have not used a local overlay before, it is not difficult — just follow the steps given below.

1. If you have not done it before, tell Portage the location of the local overlay:

# echo 'PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/"' >> /etc/make.conf

2. If you have not done it before, give your local overlay a name:

# mkdir /usr/local/portage/profiles
# echo "local_overlay" > /usr/local/portage/profiles/repo_name

3. Create the directories for the local overlay’s Google Earth ebuild and its associated files:

# mkdir -p /usr/local/portage/sci-geosciences/googleearth/files

4. Uninstall the non-functioning 64-bit version of Google Earth that you installed from the Portage main tree:

# emerge -C googleearth

5. Copy the main tree’s ebuild and associated files to the local overlay and edit the ebuild as per the changes I listed above:

# cp /usr/portage/sci-geosciences/googleearth/googleearth-7.1.2.2041.ebuild /usr/local/portage/sci-geosciences/googleearth/
# cp /usr/portage/sci-geosciences/googleearth/files/* /usr/local/portage/sci-geosciences/googleearth/files/
# cd /usr/local/portage/sci-geosciences/googleearth/
# nano googleearth-7.1.2.2041.ebuild

6. Create the manifest for the ebuild and associated files:

# ebuild googleearth-7.1.2.2041.ebuild manifest

7. Finally, install the package:

# emerge googleearth::local_overlay

The 32-bit version of Google Earth works fine in my 64-bit multilib installation, although the Panoramio photos are not displayed, but then Linux users are used to that :-/. Come on Google, you can do better than this!

Fixing a problem with received video in Skype when using the AMD Catalyst (FGLRX) driver in Linux

Some users of Skype for Linux have reported that the bottom half of the received video image is corrupted in installations that use the closed-source video driver for ATI GPUs (the AMD Catalyst proprietary Linux driver, also known as the ‘FGLRX’ driver). One user described the lower half of the video image as “covered in small coloured squares like a chequer board”.

From what I have read in a few forums, it seems the problem does not occur when the open-source Radeon driver is used. My own experience corroborates that: I use the Radeon driver on one of my laptops, and received video in Skype is fine.

My main laptop has an AMD ATI Mobility Radeon HD 5650 GPU and I am using the Catalyst driver under Gentoo Linux. In this case there was a problem with received video in most Skype sessions. Either of the following effects usually occurred:

Snapshot 1 - Extract of received video image in Skype, showing an example of the corrupted image

Snapshot 1 - Extract of received video image in Skype, showing an example of the corrupted image

Snapshot 2 - Extract of received video image in Skype, showing another example of the corrupted image

Snapshot 2 - Extract of received video image in Skype, showing another example of the corrupted image

As shown in Snapshot 1, the lower half of the received video image was covered in a grid of thin green lines with areas tinged with purple, blue or green, whereas there was no grid of lines in the upper half of the image but some areas were tinged with red or blue.

As shown in Snapshot 2, the lower half of the received video image was covered in a grid of thin red lines, with a purple tinge in some areas, whereas there was no grid of lines in the upper half of the image, which looked reasonable but had some red-, green- or blue-tinged areas.

In all cases Skype’s thumbnail of my Webcam’s video image looked fine, and the person on the other end of the call said the video image received from me looked fine too.

Because of a bug in a previous version of the Catalyst driver a few years ago — see my blog posts Playing QuickTime videos in Firefox and Chromium + XVideo bug in AMD Catalyst 11.11 and 11.12 driver and AMD Catalyst for Linux driver 12.2 fixes the XVideo bug that crashed X.Org Server 1.11.x — I happen to know that Sykpe uses X11 overlays with the XVideo extension (xv), rather than using the OpenGL renderer (gl) or X11 with the SHM extension (x11). This made me wonder whether the use of XVideo with the Catalyst driver was causing the current problem. Unlike media players such as MPlayer and VLC, it is not possible to configure Skype to use gl or x11 instead of xv, so I thought it would not be possible to test whether the use of gl or x11 instead of xv would make a difference. Until, that is, I came upon a ‘trick’ posted by openSUSE user queequeg in 2009 during the period when an earlier version of the Catalyst driver had the aforementioned bug:

Skype Video Workaround for ATI

Anybody trying to make a video call with Skype and ATI fglrx drivers has had problems due to Skype using the “xv” video mode with the driver can’t handle. For anyone interested that is affected by this, there is a workaround:

1. Run the xvinfo command and look at the number of xv sessions available. Some cards have only 1, some have as many as 4. This is the number of xv occurances that the card can do at one time.
2. “Use up” all these xv sessions by opening videos in your favorite video player making sure to use xv for the video output. The videos can then be paused.
3. Once this (or they) are open, skype can be started and will default to X11 video and work properly with video calls.

I know this is a goofy way to get around this issue, but until fglrx can handle xv or skype allows an option to choose X11 for video render, I don’t know of any other way to do it.

(From what I hear, the 11.1 fglrx drivers can handle xv, but I haven’t confirmed this.)

So I tried his work-around. I had to launch four media players in order to use all available XVideo sessions. Lo and behold, when I launched Skype and made a video call the received video image was perfect. So it appeared that the Catalyst driver is not able to handle well the XVideo output from Skype. However, playing and pausing four videos every time I want to make a video call in Skype would hardly be practical, would it? And that is not the only downside: when I maximised a Firefox window during the Skype video call, my laptop spontaneously rebooted (I assume the X.Org server crashed).

I did also wonder whether just disabling compositing would solve the problem, so I disabled KWin Desktop Effects, but that didn’t make any difference.

I had also read in several forums that enabling or disabling the TexturedVideo and/or VideoOverlay options in the xorg.conf file have an effect on the video image produced by the Catalyst driver, but I could not find a post mentioning the use of either of those options to fix the specific problem I was seeing. So I decided not to pursue the xorg.conf route.

In my searches of the Web I came across a post somewhere that mentioned using GTK+ UVC Viewer (guvcview) to adjust video properties and improve video in Skype. I thought guvcview was only for adjusting the video image from a Webcam connected to my machine, i.e. adjusting the outgoing video image, and would not have any effect on received video. Nevertheless, I decided to install and launch guvcview to see if I could adjust both incoming and outgoing video properties. To my surprise, guvcview appeared to have fixed the problem with the received video. These are the steps I followed:

  1. I launched Skype and started a video call. The received video image had a grid of thin red lines and purple/green/blue tinting (similar to Snapshot 2).
  2. I Installed guvcview using the package manager.
  3. I launched guvcview in a Konsole (terminal) window. After guvcview created the file /home/fitzcarraldo/.config/guvcview/video0 and checked various video and audio settings it exited because my Webcam was being used by Skype (‘libv4l2: error setting pixformat: Device or resource busy‘).
  4. I clicked on the Webcam icon in the Skype call window, to turn my Webcam off.
  5. I launched guvcview again. The lower half of the received video image in Skype changed from a grid of thin red lines to a continuous green-coloured band, and the upper half of the image now looked reasonable but still had some red- or blue-tinged areas (see Snapshot 3 below).
  6. Snapshot 3 - Extract of received video image in Skype after I launched guvcview again

    Snapshot 3 - Extract of received video image in Skype after I launched guvcview again

  7. On the ‘Image Controls’ tab in the ‘GUVCViewer Controls’ window I changed the video frequency from 60 Hz to 50 Hz then back to 60 Hz again. I was just tinkering, and I believe this had no bearing on the outcome.
  8. I clicked on the ‘Quit’ button in the guvcview window to terminate the application.
  9. I clicked on the Webcam icon in the Skype call window to turn on again the Webcam, and the received Skype video image changed to a perfect image (see Snapshot 4 below).
  10. Snapshot 4 - Extract of received video image in Skype after I turned on again my Webcam in Skype

    Snapshot 4 - Extract of received video image in Skype after I turned on again my Webcam in Skype

It appears that guvcview had an effect on the received video image in Skype, although, if it did, I do not understand how. To check if the fix was permanent I ended the Skype video call, signed out of Skype and quit the application, rebooted and made a new Skype video call. The received video image in Skype was again perfect. I even deleted the guvcview configuration file and repeated this check, just in case the configuration file was somehow being used even though I had not launched guvcview, but the received video in yet another Skype video call was still perfect. I also clicked on the Webcam icon in the Skype call window several times during each call in order to turn my Webcam off and on several times; the received video image of the other person remained perfect.

So there you have it: when using an AMD ATI GPU and the Catalyst driver, it seems that guvcview can be used — at least in my case — to eliminate the type of image corruption in received Skype video shown in Snapshots 1 and 2. So, if you are also using the AMD Catalyst for Linux driver and are experiencing a similar problem, try guvcview. It might just do the trick.

Switching the display quickly between a laptop monitor and an external monitor or projector in Linux

laptop_with_external_monitor_and_keyboardI connect my laptop to an external keyboard and an external monitor or projector in various offices and at home, and each of the monitors has a different resolution. Fn-F3 on my laptop keyboard allows me to toggle between monitors, but I want more control (including the ability to specify the resolution of the external display). Now, I find the GPU manufacturer’s application and the Desktop Environment’s GUI for switching monitors and changing screen resolution rather cumbersome, so I wanted an icon on the Desktop that I could double-click to switch monitors without having to enter the root user’s password and fiddle around too much. So I decided to create some simple Bash scripts and associated Desktop Config files with nice-looking icons on the desktop, which I can launch easily and quickly by double-clicking. Obviously the resolutions are limited to the range of resolutions supported by the GPU and external monitor.

The suite of Desktop Config files I created have self-explanatory names:

$ cd ~/Desktop
$ ls -1 Switch*
Switch_OFF_laptop_monitor_if_external_monitor_is_connected
Switch_OFF_laptop_monitor_if_external_monitor_is_connected_auto
Switch_ON_laptop_monitor_and_external_monitor
Switch_ON_laptop_monitor_and_switch_off_external_monitor
$ ls -1 Toggle*
Toggle_display

The difference between Switch_OFF_laptop_monitor_if_external_monitor_is_connected and Switch_OFF_laptop_monitor_if_external_monitor_is_connected_auto is that the former prompts for the resolution of the external monitor whereas the latter tries to find the resolution automatically. I have both because I have found that, for some external display devices (e.g. projectors), it is handy to have the ability to specify the resolution manually.

Switch off the laptop monitor if an external monitor is connected (find resolution automatically)

The Desktop Config file I double-click the most is ~/Desktop/Switch_OFF_laptop_monitor_if_external_monitor_is_connected_auto, and it contains the following text:

[Desktop Entry]
Comment[en_GB]=switch off laptop monitor if external monitor is connected auto
Comment=switch off laptop monitor if external monitor is connected auto
Exec=sh /home/fitzcarraldo/switch_off_laptop_monitor_if_external_monitor_is_connected_auto.sh
GenericName[en_GB]=Switch off laptop monitor if external monitor is connected auto
GenericName=Switch off laptop monitor if external monitor is connected auto
Icon=/home/fitzcarraldo/Pictures/Icons/display.png
MimeType=
Name[en_GB]=Switch_OFF_laptop_monitor_if_external_monitor_is_connected_auto
Name=Switch_OFF_laptop_monitor_if_external_monitor_is_connected_auto
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=

The Bash script it launches, ~/switch_off_laptop_monitor_if_external_monitor_is_connected_auto.sh, contains the following code:

#!/bin/bash
if xrandr -q | grep "CRT1 connected"; then
  xrandr --output LVDS --off
  xrandr --output CRT1 --off
  xrandr --output CRT1 --auto
else
  xrandr --output CRT1 --off
  xrandr --output LVDS --off
  xrandr --output LVDS --mode 1920x1080
# 1920x1080 is the native resolution of my laptop monitor
fi

Don’t forget to make them executable:

$ chmod +x /home/fitzcarraldo/Desktop/Switch_OFF_laptop_monitor_if_external_monitor_is_connected_auto
$ chmod +x /home/fitzcarraldo/switch_off_laptop_monitor_if_external_monitor_is_connected_auto.sh

If you’re wondering how I knew I had to specify ‘CRT1′ and ‘LVDS’ in the Bash script, I used the xrandr command to find out what names the GPU gives the monitors:

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920
LVDS connected (normal left inverted right x axis y axis)
1920x1080 60.0 +
1680x1050 60.0
1400x1050 60.0
1600x900 60.0
1280x1024 60.0
1440x900 60.0
1280x960 60.0
1280x768 60.0
1280x720 60.0
1024x768 60.0
1024x600 60.0
800x600 60.0
800x480 60.0
640x480 60.0
DFP1 disconnected (normal left inverted right x axis y axis)
CRT1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
1920x1080 60.0*+
1280x1024 75.0 60.0
1280x960 60.0
1280x800 59.8
1152x864 75.0
1280x720 60.0
1024x768 75.0 70.1 60.0
800x600 72.2 75.0 60.3 56.2
640x480 75.0 72.8 67.0 59.9

Switch off the laptop monitor if an external monitor is connected (enter resolution)

The Desktop Config file I double-click is ~/Desktop/Switch_OFF_laptop_monitor_if_external_monitor_is_connected, and it contains the following text:

[Desktop Entry]
Comment[en_GB]=switch off laptop monitor if external monitor is connected
Comment=switch off laptop monitor if external monitor is connected
Exec=sh /home/fitzcarraldo/System_Administration/switch_off_laptop_monitor_if_external_monitor_is_connected.sh
GenericName[en_GB]=Switch off laptop monitor if external monitor is connected
GenericName=Switch off laptop monitor if external monitor is connected
Icon=/home/fitzcarraldo/Pictures/Icons/display.png
MimeType=
Name[en_GB]=Switch_OFF_laptop_monitor_if_external_monitor_is_connected
Name=Switch_OFF_laptop_monitor_if_external_monitor_is_connected
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=

The Bash script it launches, ~/switch_off_laptop_monitor_if_external_monitor_is_connected.sh, contains the following code:

#!/bin/bash
if xrandr -q | grep "CRT1 connected"; then
echo -n "Enter resolution width of external monitor (hint 1920 Doha, 1440 home): "
read EXTERNAL_WIDTH
echo -n "Enter resoluton height of external monitor (hint 1080 Doha, 900 home): "
read EXTERNAL_HEIGHT
  xrandr --output LVDS --off
  xrandr --output CRT1 --off
  xrandr --output CRT1 --mode $EXTERNAL_WIDTH"x"$EXTERNAL_HEIGHT
else
  xrandr --output CRT1 --off
  xrandr --output LVDS --off
  xrandr --output LVDS --mode 1920x1080
# 1920x1080 is the native resolution of my laptop monitor
fi

Don’t forget to make them executable:

$ chmod +x /home/fitzcarraldo/Desktop/Switch_OFF_laptop_monitor_if_external_monitor_is_connected
$ chmod +x /home/fitzcarraldo/switch_off_laptop_monitor_if_external_monitor_is_connected.sh

Switch on the laptop monitor and external monitor simultaneously

I don’t need to use this one much, only when I am using an external monitor but suddenly want to use the laptop’s built-in Webcam and so have to open fully the laptop’s lid. The file ~/Desktop/Switch_ON_laptop_monitor_and_external_monitor contains the following text:

[Desktop Entry]
Comment[en_GB]=switch_ON_laptop_monitor_and_external_monitor
Comment=switch_ON_laptop_monitor_and_external_monitor
Exec=sh /home/fitzcarraldo/switch_on_laptop_monitor_and_external_monitor.sh
GenericName[en_GB]=Switch_ON_laptop_monitor_and_external_monitor
GenericName=Switch_ON_laptop_monitor_and_external_monitor
Icon=/home/fitzcarraldo/Pictures/Icons/display.png
MimeType=
Name[en_GB]=Switch_ON_laptop_monitor_and_external_monitor
Name=Switch_ON_laptop_monitor_and_external_monitor
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=

and the Bash script it calls, ~/switch_on_laptop_monitor_and_external_monitor.sh, contains the following code:

#!/bin/bash
if xrandr -q | grep "CRT1 connected"; then
  echo "Note that the resolution specified must be the same for both monitors, and must be achievable on both monitors."
  echo -n "Enter resolution width of external monitor (hint 1920 office, 1440 home): "
  read EXTERNAL_WIDTH
  echo -n "Enter resoluton height of external monitor (hint 1080 office, 900 home): "
  read EXTERNAL_HEIGHT
  #xrandr --output LVDS --off
  xrandr --output LVDS --mode $EXTERNAL_WIDTH"x"$EXTERNAL_HEIGHT
  xrandr --output CRT1 --off
  xrandr --output CRT1 --mode $EXTERNAL_WIDTH"x"$EXTERNAL_HEIGHT
else
  xrandr --output CRT1 --off
  xrandr --output LVDS --off
  xrandr --output LVDS --mode 1920x1080
# 1920x1080 is the native resolution of my laptop monitor
fi

Don’t forget to make them executable:

$ chmod +x /home/fitzcarraldo/Desktop/Switch_ON_laptop_monitor_and_external_monitor
$ chmod +x /home/fitzcarraldo/switch_on_laptop_monitor_and_external_monitor.sh

Switch on the laptop monitor and switch off an external monitor

I don’t need to use this one much either, given that the display mode reverts to the laptop monitor after I reboot or shutdown/power-up the laptop. The file ~/Desktop/Switch_ON_laptop_monitor_and_external_monitor contains the following text:

[Desktop Entry]
Comment[en_GB]=switch on laptop monitor and switch off external monitor
Comment=switch on laptop monitor and switch off external monitor
Exec=sh /home/fitzcarraldo/switch_on_laptop_monitor_and_switch_off_external_monitor.sh
GenericName[en_GB]=Switch on laptop monitor and switch off external monitor
GenericName=Switch on laptop monitor and switch off external monitor
Icon=computer-laptop
MimeType=
Name[en_GB]=Switch_ON_laptop_monitor_and_switch_off_external_monitor
Name=Switch_ON_laptop_monitor_and_switch_off_external_monitor
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

The Bash script it launches, ~/switch_on_laptop_monitor_and_switch_off_external_monitor.sh, contains the following code:

#!/bin/bash
xrandr --output CRT1 --off
xrandr --output LVDS --auto
xrandr --output LVDS --mode 1920x1080
# 1920x1080 is the native resolution of my laptop monitor

I did also create a fifth Desktop Config file and associated Bash script, to toggle between the three modes (laptop monitor only > both monitors > external monitor only) rather than having to double-click three different icons. But, to be honest, it’s quicker and easier to have the three icons and double-click on the one I want rather than toggling through three display modes. Anyway, in case you are interested, the Desktop Config file ~/Desktop/Toggle_Display contains the follow text:

[Desktop Entry]
Comment[en_GB]=Toggle between laptop monitor, external monitor and both
Comment=Toggle between laptop monitor, external monitor and both
Exec=sh /home/fitzcarraldo/toggle_display.sh
GenericName[en_GB]=Toggle between laptop monitor, external monitor and both
GenericName=Toggle between laptop monitor, external monitor and both
Icon=video-display
MimeType=
Name[en_GB]=Toggle_display
Name=Toggle_display
Path=
StartupNotify=false
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=

and the Bash script it launches, ~/switch_on_laptop_monitor_and_external_monitor.sh, contains the following code:

#!/bin/sh

# Using the xrandr command I found that the two video outputs from my laptop are named LVDS
# (the internal display) and CRT1 (the external display driven by the laptop's VGA socket).
# My external monitor at home has a resolution of 1440x900.

CONNECTED=`xrandr | grep -i ' connected' | grep LVDS | awk '{print $1}'`
CONNECTED="${CONNECTED} `xrandr | grep -i ' connected' | grep CRT | awk '{print $1}'`"

ENABLED=`awk '{print;exit}' ~/displays_enabled 2>/dev/null`

if [ "$CONNECTED" = "LVDS" -o "$CONNECTED" = "LVDS " -o "$CONNECTED" = " LVDS" ]; then
        # Only the internal display is connected, so don't do anything.
        echo "LVDS" > ~/displays_enabled
        ENABLED="LVDS"
        xrandr --output CRT1 --off
        xrandr --output LVDS --off
        xrandr --output LVDS --auto
        exit 0
elif [ "$CONNECTED" = "LVDS CRT1" ]; then
        # Both the internal and external displays are connected, so let's toggle
        # LVDS > LVDS,CRT1 > CRT1

        EXTERNALRES=`xrandr | awk 'c&&c--;/ connected/{c=1}' | awk '{print $1}' | grep 1440x900`
        if [ "$ENABLED" = "LVDS" ]; then
        # Switching on both displays.
                xrandr --output LVDS --off
                if [ "$EXTERNALRES" = "1440x900" ]; then
                         xrandr --output LVDS --mode 1440x900
                         xrandr --output CRT1 --off
                         xrandr --output CRT1 --auto
                else
                         xrandr --output LVDS --auto
                         xrandr --output CRT1 --off
                         xrandr --output CRT1 --auto
                fi
                ENABLED="LVDS CRT1"
                echo "LVDS CRT1" > ~/displays_enabled
        elif [ "$ENABLED" = "LVDS CRT1" ]; then
        # Switching on only external display.
                xrandr --output LVDS --off
                xrandr --output CRT1 --off
                xrandr --output CRT1 --auto
                ENABLED="CRT1"
                echo "CRT1" > ~/displays_enabled
        else
        # Switching on only internal display.
                xrandr --output CRT1 --off
                xrandr --output LVDS --off
                xrandr --output LVDS --auto
                ENABLED="LVDS"
                echo "LVDS" > ~/displays_enabled
        fi
fi

As I use KDE, I also used System Settings > Shortcuts and Gestures | Custom Shortcuts to create a keyboard shortcut which I named ‘Toggle display’, with Meta+P as Trigger and sh ~/toggle_display.sh as Action, but I tend to use the mouse rather than the keyboard in any case.

By the way, you might think some of the xrandr commands in the above Bash scripts are redundant. You would be correct in thinking that, but in practice I found that the displays did not switch if I didn’t include the additional commands shown (due to a bug in xrandr, perhaps?). Even then, when I switch to an external monitor, occasionally the screen resolution is slightly too big or too small, so I placed the icons at the top left of the desktop so that they are always accessible and I can just double-click on the same icon again if necessary. As I’m using KDE, I placed a Folder View Plasmoid for ~/Desktop/ at the top left of the desktop, as you can see in the screenshot.

Desktop showing icons for switching between monitors

Footnote

I’ve been using the above method of switching between displays for a couple of years now with an AMD ATI GPU. It works nicely and suits my needs perfectly. AMD has supported xrandr since 2008 (see Ref. 1), whereas NVIDIA only began to support xrandr last year (see Ref. 2) so I’m not sure how well these scripts would work with NVIDIA GPUs.

Ref. 1: AMD Catalyst 8.9 Gets WINE Fix, RandR 1.2 Support, September 18, 2008
Ref. 2: NVIDIA’s 302 Linux Driver Finally Has RandR 1.2/1.3, May 2, 2012

AMD Catalyst for Linux driver 12.2 fixes the XVideo bug that crashed X.Org Server 1.11.x

Just a brief ‘heads up’ for users of the closed-source FGLRX driver in Linux: In a previous blog post I mentioned a bug in the AMD Catalyst driver for Linux that caused X.Org Server 1.11.x to crash if you tried to play a video and your media player was configured to use XVideo (Xv) output. The bug also meant that people talking to you via Skype could not enable their Web cams or X.Org Server 1.11.x would crash on your machine, as Skype uses XVideo.

The problem occurred with versions 11.11, 11.12 and 12.1 of the FGLRX driver (the package x11-drivers/ati-drivers). Well, today I installed version 12.2 of the driver and am pleased to report that I can again set media players to use Xv output without causing the X.Org Server to crash (I’m currently using xorg-server-1.11.4). Likewise, other people who I am talking to via Skype can again enable their Web cams without causing the X.Org Server on my machine to crash.

Playing QuickTime videos in Firefox and Chromium + XVideo bug in AMD Catalyst 11.11 and 11.12 driver

Video problems seem to be perennial in Linux. The latest two to affect me were:

1) Firefox and Chromium could no longer play QuickTime videos on the Apple iTunes Movie Trailers Web site;

2) a bug in the latest two releases of the closed-source ATI FGLRX driver (AMD Catalyst 11.11 and 11.12 for Linux) that causes the X.Org Server to crash when I try to play .mov files using XVideo (Xv) output in media players such as SMPlayer, VLC, GNOME-MPlayer etc. (see e.g. Gentoo Bug Report No. 391193).

The reason I mention these two problems in the same breath is because I encountered the second whilst trying to fix the first. Anyway, below I explain what I did to resolve the two problems.

I first had a problem displaying QuickTime movie trailers in Firefox a couple of years ago. The solution then was to install the User Agent Switcher add-on for Firefox and create a user agent to fool the Apple Web site into thinking Firefox was using Apple’s QuickTime browser plugin instead of mplayerplug-in for Linux. But within a few days Firefox again could not play movie trailers on the Apple Web site. I had to uninstall mplayerplug-in and install the then latest version of its successor, gecko-mediaplayer (which uses gnome-mplayer). All was good again until…

Several months ago I found that, yet again, Firefox could not play movie trailers on the Apple Web site. I tried to view the trailers in Chromium instead but had the same problem. Both browsers just displayed a black box where the video should be playing. A little searching on the Web led me to the conclusion that the problem lay with the latest version of gecko-mediaplayer and gnome-mplayer that I was using at the time, so I gave up and decided to wait for new versions of gecko-mediaplayer and gnome-mplayer to be released.

Now, yesterday I wanted to watch a particular trailer on the Apple Web site, but, despite having installed the latest version of gecko-mediaplayer and gnome-mplayer anyway a few days ago, neither Firefox nor Chromium would display the trailer. A little searching on the Web suggested that I should try mozplugger instead of gecko-mediaplayer, so I uninstalled the latter, installed mozplugger and… the black box in the browser was replaced by a white box displaying the QuickTime ‘Q’ logo and a message that I needed to install QuickTime. Argghh!

So I uninstalled mozplugger and reinstalled gecko-mediaplayer and gnome-mplayer (the same versions that I installed recently, you inderstand). This time my attempts to watch trailers on the Apple Web site resulted in Firefox and Chromium displaying grey boxes and appearing to download the QuickTime videos, but then the X.Org Server crashed, restarted and the Desktop Environment’s login screen appeared. Furthermore, when I tried playing .mov videos in VLC, the same thing happened. Perhaps now you may understand why I mentioned above the bug with the FGLRX driver? It took me a few hours to realise there were two separate problems here.

The work-around to the second problem was to configure media players to use a different output driver rather than the XVideo (Xv) output driver. For example, in VLC this is done via Tools > Preferences > Video and selecting ‘GLX video output (XCB)’ as the Output under Video Settings. For SMPlayer this is done via Options > Preferences > General and selecting ‘gl (fast – ATI cards)’ as the Output driver under the Video tab.

And, most importantly, in order to enable gecko-mediaplayer to display those Apple QuickTime trailers in Firefox and Chromium I had to launch gnome-mplayer, select Edit > Preferences, click on the Player tab and select ‘gl’ as the Video Output under Adjust Output Settings. Actually, clicking on the MPlayer tab and entering “-vo gl” (without the quotes) in the ‘Extra Options to MPlayer:’ box achieves the same result. By the way, the tickboxes QuickTime Emulation, RealPlayer Emulation, Windows Media Player Emulation and DIVX Player Emulation were already ticked on the Plug-in tab.

So, there you have it. After several hours of searching and tinkering I can again watch movie trailers on the Apple Web site. Don’t you just love Linux?

For the sake of completeness, below I list the versions of the applicable packages currently installed on my main laptop:

firefox-9.0
chromium-16.0.912.63
gecko-mediaplayer-1.0.5_beta1_p20111207
gnome-mplayer-1.0.5_beta1
mplayer-1.0_rc4_p20111215
ffmpeg-0.9
libquicktime-1.2.3-r1
xorg-server-1.11.2-r2
ati-drivers-11.12

EDIT (January 2, 2012): I’ve just had a thought: When I used Skype for Linux a few days ago, my laptop rebooted spontaneously as soon as the person at the other end enabled her Webcam in Skype for Windows. This was reproducible consistently. However, I could enable my Webcam, she could see me in Skype on her PC, and I could also see video of me in Skype’s ‘myself preview’ on my laptop. Now, it could be a coincidence but I wonder if the reboot occurred because Skype for Linux uses XVideo? Skype’s Web page for Skype for Linux lists “Video card driver with Xv support” as one of the hardware requirements, which looks pretty conclusive to me. However, this leaves a couple of niggling questions: a) If Skype does indeed use XVideo, why didn’t the ‘myself preview’ video in the Skype for Linux window crash the X.Org Server?. b) If the FGLRX driver bug is the cause, why did my laptop reboot instead of just the X.Org Server crashing, restarting and displaying the Desktop Environment login screen? Furthermore, Skype’s Options > Video Devices > Test does work correctly on my laptop. So perhaps the rebooting problem is caused by a different bug. Suspicious, though. Unfortunately, as far as I know there is no way of switching Skype to use OpenGL instead of XVideo, so I cannot prove that XVideo is the cause of this particular problem I’m experiencing with Skype.

Follow

Get every new post delivered to your Inbox.

Join 52 other followers