Getting Google Earth in Gentoo Linux to display Panoramio photos

Well, I decided to get Panoramio photos working in Google Earth installed using the hacked ebuild I posted in April 2014 (see my post Work-around if 64-bit Google Earth crashes in Gentoo Linux).

The modification devised by user amirpli (see Comment #9 in Gentoo Bugzilla Bug Report No. 490066) does not work in my case, as explained in detail in the above-mentioned April 2014 post. I believe this is because I am using the FGLRX video driver, as I have successfully applied amirpli‘s modification in an installation on a PC that has an Intel GPU.

Here is how I got Panoramio photos to display on my main laptop running the FGLRX driver, although my fix is yet another hack: I use 32-bit libraries downloaded from the Web. It works for me, though!

Background

I am running Google Earth 7.1.2.2041 installed from a local overlay (see my above-mentioned April 2014 post) in KDE 4.14.3 under Gentoo Linux ~amd64 with the 3.17.1-gentoo-r1 kernel and FGLRX driver:

# eix ati-drivers
[I] x11-drivers/ati-drivers
     Available versions:
     (legacy) 13.1_pre897^td
     (1)    13.4^td 13.9^td 13.12^td 14.4_p1^td (~)14.6_beta2^td (~)14.9-r2^ftd (~)14.12-r2^td 14.12-r3^td
       {debug disable-watermark +modules multilib pax_kernel qt4 static-libs ABI_X86="32 64" KERNEL="linux"}
     Installed versions:  14.12-r3(1)^td(20:22:04 13/02/15)(modules qt4 -debug -pax_kernel -static-libs ABI_X86="32 64" KERNEL="linux")
     Homepage:            http://www.amd.com
     Description:         Ati precompiled drivers for Radeon Evergreen (HD5000 Series) and newer chipsets

Procedure

1. Download into ~/Downloads/ the following Ubuntu 32-bit packages from http://packages.ubuntu.com/utopic/i386/libs/

$ ls -la *.deb
-rw-r--r-- 1 fitzcarraldo users  24060 Mar  1 23:59 libecore-imf1_1.8.6-2ubuntu1_i386.deb
-rw-r--r-- 1 fitzcarraldo users 274206 Mar  1 22:59 libfreeimage3_3.15.4-3build1_i386.deb
-rw-r--r-- 1 fitzcarraldo users  52154 Mar  1 23:45 libilmbase6_1.0.1-6.1_i386.deb
-rw-r--r-- 1 fitzcarraldo users 135300 Mar  2 00:28 libjasper1_1.900.1-debian1-2ubuntu0.2_i386.deb
-rw-r--r-- 1 fitzcarraldo users 106868 Mar  1 23:00 libjpeg-turbo8_1.3.0-0ubuntu2_i386.deb
-rw-r--r-- 1 fitzcarraldo users  98500 Mar  1 23:39 libopenjpeg5_1.5.2-2_i386.deb
-rw-r--r-- 1 fitzcarraldo users 189420 Mar  2 00:21 libraw10_0.16.0-6_i386.deb

2. Download into ~/Downloads/ the following 32-bit packages from http://rpmfind.net/linux/rpm2html/search.php and http://pkgs.org/

$ ls -la *.rpm
-rw-r--r-- 1 fitzcarraldo users  57976 Mar  2 00:13 libilmbase6-1.0.2-11.1.2.i586.rpm
-rw-r--r-- 1 fitzcarraldo users 148379 Mar  2 00:03 libilmimf6-1.6.1-alt9.i586.rpm

3. Extract into ~/Downloads/ the following 32-bit libraries from the above-mentioned .deb and .rpm packages:

$ ls -la lib*.so*
-rw-r--r-- 1 fitzcarraldo users 644568 Apr 27  2014 libfreeimage-3.15.4.so
-rw-r--r-- 1 fitzcarraldo users 677340 Apr 27  2014 libfreeimageplus-3.15.4.so
-rwxr-xr-x 1 fitzcarraldo users 271780 Jul 15  2012 libHalf.so.6.0.0
-rwxr-xr-x 1 fitzcarraldo users 104044 Jul 15  2012 libIex.so.6.0.0
-rw-r--r-- 1 fitzcarraldo users 671896 Dec  3 15:06 libIlmImf.so.6.0.0
-rwxr-xr-x 1 fitzcarraldo users  22260 Jul 15  2012 libIlmThread.so.6.0.0
-rw-r--r-- 1 fitzcarraldo users 342116 Jan 22 18:46 libjasper.so.1.0.0
-rw-r--r-- 1 fitzcarraldo users 300776 Dec 19  2013 libjpeg.so.8.0.2
-rw-r--r-- 1 fitzcarraldo users 142604 Apr 26  2014 libopenjpeg.so.1.5.2
-rw-r--r-- 1 fitzcarraldo users 657336 Jul 22  2014 libraw.so.10.0.0

4. Merge the 32-bit Google Earth package from a local overlay, using the ebuild listed in my above-mentioned April 2014 post:

# emerge -C googleearth
# rm -rf /opt/googleearth/
# emerge googleearth::local_overlay

5. Delete the four bundled Qt libs, compile the shim devised by user amirpli (see Comment #9 in Gentoo Bugzilla Bug Report No. 490066) but compile it for 32 bits (‘-m32‘), and edit the googleearth script to use the 32-bit libfreeimage.so.3 that you will copy into /opt/googleearth/ later:

# cd /opt/googleearth
# rm libQt*
# touch baifaao.cpp
# nano baifaao.cpp
# cat baifaao.cpp
/* amirpli 2013/11/28 */
#include <QtCore/QAtomicInt>
extern "C" {
        int _Z34QBasicAtomicInt_fetchAndAddOrderedPVii(QAtomicInt* a, int b) {
                return a->fetchAndAddOrdered(b);
        }
}
# gcc -I/usr/include/qt4 -O3 -m32 -fPIC --shared baifaao.cpp -o baifaao.so
# nano googleearth
# tail googleearth
}

script_path=$(FindPath $0);

cd $script_path;

export LD_PRELOAD=/opt/googleearth/libfreeimage.so.3:/opt/googleearth/baifaao.so
export LC_NUMERIC=en_US.UTF-8 # Must do this if you are using non-US locale.

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./googleearth-bin "$@"

6. Copy into the Google Earth directory all the libraries downloaded and extracted in Steps 1 to 3 above, and create the necessary symlinks and permissions:

# cd /opt/googleearth
# cp /home/fitzcarraldo/Downloads/libfreeimage-3.15.4.so .
# cp /home/fitzcarraldo/Downloads/libfreeimageplus-3.15.4.so .
# ln -s libfreeimage-3.15.4.so libfreeimage.so.3
# ln -s libfreeimage.so.3 libfreeimage.so
# ln -s libfreeimageplus-3.15.4.so libfreeimageplus.so.3
# ln -s libfreeimageplus.so.3 libfreeimageplus.so
# chmod +x libfreeimage-3.15.4.so
# chmod +x libfreeimageplus-3.15.4.so
# cp /home/fitzcarraldo/Downloads/libjpeg.so.8.0.2 .
# ln -s libjpeg.so.8.0.2 libjpeg.so
# ln -s libjpeg.so libjpeg.so.8
# chmod +x libjpeg.so.8.0.2
# cp /home/fitzcarraldo/Downloads/libopenjpeg.so.1.5.2 .
# ln -s libopenjpeg.so.1.5.2 libopenjpeg.so
# ln -s libopenjpeg.so libopenjpeg.so.5
# chmod +x libopenjpeg.so.1.5.2
# cp /home/fitzcarraldo/Downloads/libIlmImf.so.6.0.0 .
# ln -s libIlmImf.so.6.0.0 libIlmImf.so
# ln -s libIlmImf.so libIlmImf.so.6
# chmod +x libIlmImf.so.6.0.0
# cp /home/fitzcarraldo/Downloads/libHalf.so.6.0.0 .
# ln -s libHalf.so.6.0.0 libHalf.so
# ln -s libHalf.so libHalf.so.6
# chmod +x libHalf.so.6.0.0
# cp /home/fitzcarraldo/Downloads/libIex.so.6.0.0 .
# ln -s libIex.so.6.0.0 libIex.so
# ln -s libIex.so libIex.so.6
# chmod +x libIex.so.6.0.0
# cp /home/fitzcarraldo/Downloads/libraw.so.10.0.0 .
# ln -s libraw.so.10.0.0 libraw.so
# ln -s libraw.so libraw.so.10
# chmod +x libraw.so.10.0.0
# cp /home/fitzcarraldo/Downloads/libIlmThread.so.6.0.0 .
# ln -s libIlmThread.so.6.0.0 libIlmThread.so
# ln -s libIlmThread.so libIlmThread.so.6
# chmod +x libIlmThread.so.6.0.0
# cp /home/fitzcarraldo/Downloads/libjasper.so.1.0.0 .
# ln -s libjasper.so.1.0.0 libjasper.so
# ln -s libjasper.so libjasper.so.1
# chmod +x libjasper.so.1.0.0

Finally, launch Google Earth from your user account, not the root user’s account:

$ googleearth

Clicking on any photo icon in Google Earth should now display Panoramio photos.

If you click on a photo icon and the frame that opens displays several thumbnails, clicking on a thumbnail may result in a white Panoramio frame without any photo and thumbnails displayed. According to user amirpli this problem occurs in KDE but not GNOME. If it does happen in your case, to view the other photos right-click on a thumbnail and select ‘Open in New Window’. This way you will be able to view any of the photos.

It’s nice to be able to see the Panoramio photos again in Linux with the FGLRX driver.

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!

Update (March 2, 2015): See my post Getting Google Earth in Gentoo Linux to display Panoramio photos for a way to get Google Earth in Gentoo Linux to display the Panoramio photos.

Installing the Windows version of Google Earth in WINE

Some Gentoo Linux users have reported that, although the native Linux release of Google Earth crashes, they can run the Windows version successfully under WINE. However, those users have also reported that the Windows installer for Google Earth did not work under WINE and so they copied the C:\Program Files\Google\Google Earth\ directory from a Windows PC to the virtual C:\ drive in their .wine directory (it would be ‘Program Files (x86)‘ in a 64-bit Windows installation, as Google Earth is a 32-bit application).

Now, if you download the Windows Google Earth installer from the Google Web site, what you get is a file GoogleEarthWin.exe that is 534.6 KiB in size (the size may vary depending on the release). However, you can instead download the Offline Installer using the following URL:

http://dl.google.com/earth/client/advanced/current/GoogleEarthWin.exe

and then you get a file GoogleEarthWin.exe that is 24.3 MiB in size (the size will vary depending on the release), which does run in WINE and does install the Windows version of Google Earth in WINE.

So, you might like to try that if you cannot run Google Earth in Linux but you have WINE installed. However, note that you will be wasting your time if the native Linux version of Google Earth crashes because of its incompatibility with the closed-source ATI or NVIDIA video driver. For example, Google Earth 7.1.2.2041 for Linux crashes on my main laptop using the 14.3_beta version of ati-drivers (AMD ATI Catalyst driver, a.k.a. FGLRX).

Anyway, if you want to install the Windows release of Google Earth under WINE here’s how to do it in a Konsole/Terminal window:

$ cd
$ export WINEPREFIX=$HOME/.wine-googleearth
$ export WINEARCH="win32"
$ winecfg
$ cd ./.wine-googleearth/drive_c/
$ wget http://dl.google.com/earth/client/advanced/current/GoogleEarthWin.exe
$ wine GoogleEarthWin.exe

And, to run it later:

$ env WINEPREFIX="/home/fitzcarraldo/.wine-googleearth" WINEARCH="win32" wine C:\\windows\\command\\start.exe /Unix /home/fitzcarraldo/.wine-googleearth/dosdevices/c:/users/fitzcarraldo/Start\ Menu/Programs/Google\ Earth/Google\ Earth.lnk

(Of course replace “fitzcarraldo” with your user name.)

But, as I wrote above, if the native Linux version of Google Earth crashes due to its incompatibility with the closed-source video driver (ATI or NVIDIA), it is highly unlikely the native Windows version will work under WINE.

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.

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 60 other followers