Skip to content

Video

VideocoreIV Glamor on your Raspberry Pi

RaspberryPi Logo

Running an X (Xorg) server on your Raspberry Pi is frustrating. You can either use the fbdev or fbturbo driver which will give an un-accelerated 2D environment with swrast 3D (OpenGL) all beating your poor RPi's CPU. Overclocking it will only help you so much which is a pity considering that there is another layer on the SoC that would be perfect for that but is now unused.

Enter the VideocoreIV (VC4) and Eric Anholt (formally of Intel, now of Broadcom), who are going to breath new life into the RPi. The idea is to offload the 2D rendering, via Glamor, to the VC4 with OpenGL calls. Since a OpenGL stack needs to exist, that means there will be a Direct Rendering Manager (DRM) Linux kernel module and Gallium/DRI module in Mesa.

This is happening now, here is the current status of support via the Piglit test-suite: skip 19102, fail 3866, pass 3146, crash 153, total 26267

While we skip a great deal of tests, they are because some extensions are not yet implemented. Of those implemented, almost half of the tests are passing! Wrapping up the crashed and failed tests will help add stability to the OpenGL stack that will lead to the eventual use of the VC4 as an everyday use of the RPi.

If you would like to follow along from home, and I suggest you do as there are updates almost every day, then you can see the progress for yourself! The end result, at least for me, is to see OpenMW running on the RPi with full OpenGL acceleration under X. Eric has left some low-hanging fruit for new and would be contributors to help out! I'll provide a check-list of things you'll need, best practices and ways that you can help too.

Phase 1: Setting up your RPi workbench You'll need an RPi, running the latest Raspbian "Jessie" release. Setup a 'dev' directory under your account. Optionally, but highly recommended is to set this dev directory up as an NFS mountpoint so that your compiling/working is not ruining your SD-card with constant writes.

Phase 2: Getting the VC4 kernel driver At this point, you'll need to git clone Eric's fork of the kernel and get familiar with building your own kernel. You'll need do the following:

  • sudo apt-get install git build-essential ncurses-dev
  • git clone -b vc4 --depth=10 https://github.com/anholt/linux.git
  • cd linux; zcat /proc/config.gz > .config; make oldconfig

The basic idea is that you are cloning his specific branch and not the whole tree, otherwise your just wasting time. You'll pull in your running kernel's config and bring it up to date with what is new in Eric's VC4 branch.

You'll also need to modify a few things in the .config file, first: CONFIG_CMA_SIZE_MBYTES=5 --> CONFIG_CMA_SIZE_MBYTES=64 This needs to be set to, at least, 64 since 5 is NOT enough for the VC4 kernel module. The VC4 DRM module on the other hand is best, currently at least, to be built into the kernel. You'll need to turn on DRM and VC4 like below.

Direct Rendering Manager

CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_KMS_FB_HELPER=y

CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

CONFIG_DRM_GEM_CMA_HELPER=y CONFIG_DRM_KMS_CMA_HELPER=y

I2C encoder or helper chips

CONFIG_DRM_I2C_CH7006 is not set

CONFIG_DRM_I2C_SIL164 is not set

CONFIG_DRM_I2C_NXP_TDA998X is not set

CONFIG_DRM_UDL is not set

CONFIG_DRM_ARMADA is not set

CONFIG_DRM_RCAR_DU is not set

CONFIG_DRM_SHMOBILE is not set

CONFIG_DRM_PTN3460 is not set

CONFIG_DRM_VC4=y

If you don't wish to do this by hand, just give the 'make menuconfig' a spin and you'll work through the options available there. A this point, you should be ready to build your kernel. The first time around will take a while.

make; make modules; make modules_install

After it is finished, time to copy your newly baked kernel and copy it to /boot to be usable. If you screw up, and your RPi no longer boots, just insert your SD-card into a FAT readable machine and edit the config.txt file to point to the old kernel since we'll be moving it out-of-the-way first.

sudo mv /boot/kernel.img /boot/kernel.img.orig; sudo cp arch/arm/boot/zImage /boot/kernel.img; sync

At this point, cross your fingers and reboot your RPi. If it comes back online, check your dmesg for the following output:

[ 1.267449] BCM2708FB: allocated DMA memory 58400000 [ 1.272631] BCM2708FB: allocated DMA channel 0 @ f2007000 [ 1.298488] Console: switching to colour frame buffer device 200x75 [ 1.320303] uart-pl011 dev:f1: no DMA platform data [ 1.325906] vc-cma: Videocore CMA driver [ 1.330043] vc-cma: vc_cma_base = 0x00000000 [ 1.334843] vc-cma: vc_cma_size = 0x00000000 (0 MiB) [ 1.340424] vc-cma: vc_cma_initial = 0x00000000 (0 MiB) [ 1.346345] Initialized drm 1.1.0 20060810 [ 1.361836] vc4-drm vc4-drm.0: fb1: frame buffer device [ 1.367283] vc4-drm vc4-drm.0: registered panic notifier [ 1.372819] Initialized vc4 0.0.0 20140616 on minor 0

At this point, you are good to go! The glue between VC4 and userland is ready to be abused! Keep in mind, if there are updates on the linux side, git pull and rebuild your kernel and modules. Don't forget to install both! Thankfully this doesn't happen often as most of the work happens in Mesa.

Phase 3: Getting Mesa and building the VC4 Gallium DRM

This is pretty straight forward, if you know the right magic during configuration. We've (Eric and I) finally nailed with is necessary to build and get working.

  • sudo apt-get install xorg-dev libgl1-mesa-dev libgles1-mesa-dev libgles2-mesa-dev libglu1-mesa-dev xutils-dev xserver-xorg-dev
  • git clone --depth=10 git://anongit.freedesktop.org/mesa/mesa
  • cd mesa; autoreconf -v --install
  • ./autogen.sh \ --prefix=$HOME/prefix \ --with-gallium-drivers=vc4,swrast \ --enable-gles1 \ --enable-gles2 \ --with-egl-platforms=x11,drm \ --enable-glx-tls \ --enable-dri \ --with-dri-drivers=swrast \ --enable-shared-glapi \ --enable-texture-float \ --with-log-dir=/var/log \ --prefix=/usr \ --libdir=/usr/lib/arm-linux-gnueabihf
  • make; sudo make install

What is going on here is that you need to install some development headers so that you can build your Mesa drivers that will be used with Xorg. You might need to install more packages, if so, please notify me but these should work and configuration shouldn't fail. At the end of the configuration, it should give you an output of everything it will do during compilation. Yours should look like mine:

prefix: /usr exec_prefix: ${prefix} libdir: ${exec_prefix}/lib includedir: ${prefix}/include

OpenGL: yes (ES1: yes ES2: yes) OpenVG: no

OSMesa: no

DRI platform: drm DRI drivers: swrast DRI driver dir: ${libdir}/dri GLX: DRI-based

EGL: yes EGL platforms: x11 drm EGL drivers: builtin:egl_dri2

llvm: no

Gallium: yes

Shared libs: yes Static libs: no Shared-glapi: yes

CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp Macros: -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DTEXTURE_FLOAT_ENABLED -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE

PYTHON2: python2

Phase 4: Piglit testing

This is the part that will tell you that everything you've done up to this point hasn't been in vain. Piglit is a OpenGL test-suite that is very thorough. You'll use this when developing, to test against.

  • sudo apt-get install libwaffle-dev python-dev
  • git clone --depth=10 git://anongit.freedesktop.org/git/piglit
  • cd piglit; cmake -DPIGLIT_BUILD_GLES2_TESTS=TRUE .
  • PIGLIT_PLATFORM=gbm ./bin/shader_runner tests/shaders/glsl-algebraic-add-add-1.shader_test -auto -fbo

After running the individual test, you should get something like this:

PIGLIT: {"result": "pass" }

Don't mind the rather noisy MESA-LOADER issues, the RPi doesn't have a PCI bus. Congratulations, you're now utilizing your VC4! Happy hacking!

For additional output, debug information and trace level QIR calls, try running the former command like this:

PIGLIT_PLATFORM=gbm VC4_DEBUG=qir ./bin/shader_runner tests/shaders/glsl-algebraic-add-add-1.shader_test -auto -fbo

MESA-LOADER: malformed or no PCI ID MESA-LOADER: malformed or no PCI ID libEGL debug: Native platform type: drm (environment overwrite) libEGL debug: EGL search path is /usr/lib/arm-linux-gnueabihf/egl libEGL debug: added /usr/lib/arm-linux-gnueabihf/egl/egl_gallium.so to module array libEGL debug: added egl_dri2 to module array libEGL debug: dlopen(/usr/lib/arm-linux-gnueabihf/egl/egl_gallium.so) libEGL info: use DRM for display 0x16a1568 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no usable display)

libEGL debug: the best driver is DRI2 QIR: mov t2, u2 mov t3, u3 mov t4, u4 mov t5, u5 fadd t6, u0, t2 fadd t7, u1, t3 fadd t8, u1, t4 fadd t9, u1, t5 pack_colors t15, t6, t7, t8, t9 tlb_color null, t15 ... PIGLIT: {"result": "pass" }

Now on to the real work, as Eric describes it in his LJ article helping out with VC4:

Now the actual work: I've left some of the TGSI opcodes unfinished (SCS, DST, DPH, and XPD, for example), so the driver just aborts when a shader tries to use them. How they work is described in src/gallium/docs/source/tgsi.rst. The TGSI-to_QIR code is in vc4_program.c (where you'll find all the opcodes that are implemented currently), and vc4_qir.h has all the opcodes that are available to you and helpers for generating them. Once it's in QIR (which I think should have all the opcodes you need for this work), vc4_qpu_emit.c will turn the QIR into actual QPU code like you find described in the chip specs.

Phase 5: Bonus Round -- Modesetting Xorg driver

You're likely thinking, right... all this work and how do I get it into Xorg's driver seat? The answer is the 'modesetting' driver which acts as the glue to getting X talking with Glamor. Be warned though, there isn't anything usable yet. This might change though in a month or two so keep an eye on this. Who knows, glxgears might be just around the corner!

  • git clone git://people.freedesktop.org/~anholt/xf86-video-modesetting
  • ./configure --prefix=/usr
  • make; sudo make install

You'll need to create an xorg.conf file and run startx to see anything. However, be again warned, if you do this, the VC4 will be in an unknown state afterwards and likely need a reboot of your RPi.

sudo vim /etc/X11/xorg.conf

Section "Module" Load "glamoregl" Load "glx" EndSection

Section "Device" Identifier "Default screen" Driver "modesetting" # you can change this back to fbdev Option "ForceGallium" "True" Option "AccelMethod" "glamor" EndSection

Section "dri" Mode 0666 EndSection

As always, you should also keep up to date with what Eric has been up to here: http://anholt.livejournal.com/

This wraps up hacking the VC4 on your Raspberry Pi boot-camp and I hope it was useful enough to get you started in the right direction.

Development on the Raspberry Pi

RaspberryPi Logo

Now that I'm a proud owner of a Raspberry Pi, I've being really stressing the little guy. There is only but so much a ARMv6 processor, on an microSD with only 512MiB of ram can do, which means that compiling on such a machine is going to take a really long time.

Take for example OpenMW, currently it takes about 4 minutes on a quad-core i7 to compile. You're in for a treat on the Pi, it will take you at least a day, two days if you realize that half-way through the OOM Killer came through and killed your cc process. This is about the time you start wondering about various ways to improve the situation, such as a larger swap file or using zram.

At this point, I was wondering about other ways compiling binaries and packages for the Pi. There was cross-compiling, but then I would have to set up a full toolchain and recompile all the packages from scratch. That will have to be for another post though as it is another world. Another option is to try virtualizing the Pi and apparently QEMU gets us pretty darn close.

Let us begin with the preparation of our environment. We'll get the latest Raspbian release and clean up it for use in a QEMU environment.

# get the latest Raspbian: wget http://downloads.raspberrypi.org/raspbian_latest

create new target image of about 20GiB and mount it

dd bs=1 count=0 seek=20G if=/dev/zero of=raspbian.img sudo losetup -f --show raspbian.img

mount downloaded raspbian image and copy over

sudo losetup -f --show 2014-06-20-wheezy-raspbian.img sudo dd if=/dev/loop1 of=/dev/loop0 sudo losetup -d /dev/loop1

resize partition, edit one file, and umount

sudo parted /dev/loop0 resizepart 2 20GB

resize our filesystem

sudo partprobe /dev/loop0 sudo resize2fs /dev/loop0p2

editing out shared lib preloading so that it fully boots

sudo mount /dev/loop0p2 /mnt/image sudo sed -i s/'\/usr'/'#\/usr'/g /mnt/image/etc/ld.so.preload cp /mnt/image/boot/kernel.img ~/kernel.img # used later in the custom built qemu sync sudo losetup -d /dev/loop0

At this point, you have an image for QEMU to use but now you have to choose. There are two routes:

  • The default QEMU with only 256MiB of ram and a slightly different kernel than the Raspbian one because it uses a different CPU. The benefit here is that you don't have to do much, just apt-get install and you're on your way.
  • The modified QEMU, that gives you native RPi support so you can use your Raspbian kernel. It also has 512MiB of ram, like the RPi B+ which helps with compiling. The only drawback currently is the lack of networking.

First choice: # get a kernel: wget http://xecdesign.com/downloads/linux-qemu/kernel-qemu

fire up QEMU:

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda raspbian.img

Second choice: # setup build environment, configure and compile sudo aptitude install libsdl-dev libfdt-dev git build-essential git clone git://github.com/Torlus/qemu.git -b rpi cd qemu ./configure --target-list="arm-softmmu arm-linux-user" --enable-sdl make -j8

remember that kernel.img we copied earlier? We can use it here!

run our newly made system

arm-softmmu/qemu-system-arm -M raspi -m 512 -sd ~/raspbian.img -kernel ~/kernel.img -append "earlyprintk loglevel=8 panic=120 keep_bootcon rootwait dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768 bcm2708.boardrev=0xf bcm2708.serial=0xcad0eedf smsc95xx.macaddr=B8:27:EB:D0:EE:DF sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1c000000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline rootwait root=/dev/mmcblk0p2 panic=1 rootfstype=ext4 rw" -serial stdio -device usb-kbd -device usb-mouse -usbdevice net

At this point, you should have a usable Raspbian environment which should be faster than the real deal. Perfect for compiling and creating packages for your Raspberry Pi.

Happy hacking!

Properly ripping DVDs and adding subtitles in Ubuntu

dvd::rip

There are occasions where you legitimately need tools to help that would otherwise be considered the domain of "pirates" and "ne'er-do-wells". In this particular scenario, my grandparents send a DVD from the United States (Region1) to us in Belgium (Region2). Not only will the DVD not play back on a region locked DVD player, there are also no Dutch subtitles.

There are however technological solutions to this type of problem, including such programs as dvd::rip, vobsub2srt and a few websites dedicted to crowdsourced subtitles.

Our first task is to properly rip a DVD. There are many options here, but I chose dvd::rip because it just works. It creates a small xvid (avi) file that is compatible with a set-top DVD player and it is also allows ripping of any subtitles found on the DVD. If may wish to dig into the documentation to really understand the details of dvd:rip. I'll give you a step-by-step run down on how I did things.

dvd::rip

  1. Install the program and it's libraries.
  2. Following the directions and make sure the directories are set, dvd drive is found and that libraries are installed.
  3. On the left will be tabs, use this as a process. Begin with "Storage" where you set the project name, dvd drive to use and "Copy data from DVD to hard disk before encoding" which will make things faster.

Storage

  1. On "Rip Title" you need to read the data on the DVD and select which files to rip. First "Read DVD table of contents", select the Title or Titles you wish to rip, usually the one with the most Chapters and/or Runtime is your target. Highlight that entry, select on the right your audio track (en for English, other en entries are usually commentary tracks). Set "Specify chapter mode" to None so that it is ripped as one file and not a set of files (per chapter) and set the "Grab subtitle preview images" to All so that you can select what subtitles you wish use, if any. The last step here is to "Rip selected title(s)/chapter(s) which will take a few minutes.

RipTitle

  1. Select next the "Clip & Zoom" which will allow you to set the correct format (size) that is perfect for your TV. You need to be careful here because the source (DVD) can be different such as: letterbox (widescreen) 1.85:1 ratio, anamorphic (widescreen) 16:9 ratio, or pan & scan (fullscreen) 4:3 ratio. Look at the back of your DVD box to verify. To test different settings, do a grab frame and try various "Autoadjust" presets until you find something that looks right. If you are playing back on an older DVD player with USB divx/xvid/avi support, then try to pick Small Frame Size, which is about 480p. This will make playing back smother as your hardware DVD player doesn't have enough CPU power to downscale higher resolutions.

ClipAndZoom

  1. Moving to the Subtitles screen, you can select the DVD title that you ripped and the correct subtitle you wish to rip. You can either "Activate this subtitle" for rendering or "Create now" which will produce separate files which you can use later. I prefer another method of handling subtitles than hard-rendering them to the rip. After "Create Now", you will have extra files that we can convert to SubRip text file format (SRT) later.

Subtitles

  1. After that we go to the "Transcode" tab which is the 'meat' of the program. We select our DVD title, select a container of AVI, make sure the "Video codec" is xvid, "By target size"'s "Target media" to One x 700MB which will create one file at an acceptable bitrate. On the Audio Options side, "Select track" to the one we ripped and select MP3. I set the Samplerate to 192kbit/s to get better audio. the rest I set to defaults. On the bottom left gives you an "Calculated storage". If you are content with your choices, go to "Operate" and select "Transcode" and wait a bit more.

Transcode

  1. Success! Try out your newly made AVI file with VLC or another player to make sure it is to you liking. If you got an error, you can go to the "Logging" tab on the left and see where you went wrong.

At this point, you should have an AVI file that you can play back in your video player or DVD player. However the job is not yet finished as we also need the subtitles for those in their native language. We saw that we could 'Rip' subtitles with dvd::rip but the files we have are in the VOB format idx/ifo/sub format which may or may not be readable by your player. We can convert this format to a SRT text-based file which is widely supported subtitle format using a tool called: VobSub2SRT.

VobSub2SRT

  1. Download and build VobSub2SRT yourself or install the package via PPA.
  2. You will also need to install 'tesseract-ocr' and any of the language files necessary to handle the subtitle language you ripped earlier.
  3. From the command line, go to where your ripped subtitles are and run the command to convert (OCR) them into an SRT file.

vobsub2srt --lang en dolphinetail-001-sid00

This will use english (en) from the idx/sub files to make the srt file. You can find out which languages you can pick from using the --langlist parameter.

bcurtis@Wintermute:~/.dvdrip-data/dolphinetail/avi/001$ vobsub2srt --lang en dolphinetail-001-sid00 Selected VOBSUB language: 0 language: enen Wrote Subtitles to 'dolphinetail-001-sid00.srt'

Success! Just copy the SRT file to where your AVI is and your player should recognize and automatically use the subtitle file.

There are times when you have the film but there is not subtitle for your language of choice. This is where crowd sourcing comes in as there is no shortage of people wanting to either subtitle the film for free as volunteer work or for some other altruistic or non-altruistic reason.

Crowdsourced Subtitles

  • Bierdopje: Dutch subtitles for films and series.
  • OpenSubtitles: Multi-lingual subtitles for films and series
  • Podnapisi: Older Multi-lingual subtitles for films and series

Resizing Video There can be moments where you have a file you want to play back on your DVD player and it complains that the resolution is not supported. This because it doesn't have a CPU powerful enough to downscale your film to your TV's resolution. I found this Video Conversion Guide which helped. You just need to figure out what your TV's native resolution is, and try to match it. For example my TV is an old CRT PAL monster and the source is a 1280x720 video. The DVD player doesn't support that resolution, but it is 16:9 ratio. We then convert the mkv to an avi to stay within the same ratio and play back on an old style PanScan CRT.

mencoder input.avi -ovc xvid -vf scale=648:364 -oac mp3lame -lameopts cbr:br=192 -xvidencopts pass=2:bitrate=-1400000:threads=4 -o output.avi

This converts the film 648:364, however you should keep in mind your TV's resolution. The guide gives a better understanding and there is no need to repeat the information here.

The end result should be a film for your USB in with a subtitle of your choice.

Ubuntu 12.04 (Precise) and AMD Catalyst 12.4

glxgears

Precise Pangola has been released and a day later comes a new fglrx driver. While there isn't a changelog, this build apparently gives us:

early-look support for Ubuntu 12.04, Linux PowerXpress support for the Intel Ivy Bridge platform, packaging script updates, and various bug-fixes.

Among the bug-fixes for Catalyst 12.4 on Linux are: fixing some multi-head issues, a system hang in certain PowerXpress configurations, fixing a system hang when using OpenGL overlays, correcting an OpenGL performance drop, a soft-hang when killing the X Server, and severe corruption for OpenGL games using the AMD "Redwood" graphics processors.

If you want to build these for yourself then you can follow these instructions:

  1. Download 64-bit 12.4 from AMD
  2. Extract the files from the package: sh ./amd-driver-installer-12-4-x86.x86_64.run --extract ati
  3. Build your new ati/fglrx deb packages: ./ati-installer.sh 8.961 --buildpkg Ubuntu/precise
  4. Install our newly created deb packages: sudo dpkg -i ../fglrx*.deb
  5. If your /etc/X11/xorg.conf is missing you will need to run: sudo aticonfig --initial and then reboot.

That newly created package should work for 3.2 kernel series in Precise.

Ubuntu 11.04 Natty with fglrx and 2.6.39

glxgears

Natty (11.04) users can finally get fglrx playing nicely together with X.org 1.10. We can also make the latest driver work well with the 2.6.39 kernel.

Custom build procedure:

  1. Install the latest 2.6.39 kernel revision from Ubuntu Mainline or install the PPA.
  2. Download 64-bit 11.4.
  3. Extract the files from the package: sh ./ati-driver-installer-11-4-x86.x86_64.run --extract ati
  4. For 2.6.39 support, download this extra patch: 2.6.39_bkl.patch
  5. Check for Big Kernel Lock usage: cat /lib/modules/`uname -r`/build/.config | grep -c CONFIG_BKL=y If the result of this command is 0, then download no_bkl.patch as well.
  6. then apply them: cd ati; for i in ../*.patch; do patch -p1 < $i; done
  7. Build your new ati/fglrx deb packages: ./ati-installer.sh 8.841 --buildpkg Ubuntu/natty
  8. Install our newly created deb packages: sudo dpkg -i ../fglrx*.deb
  9. If your /etc/X11/xorg.conf is missing you will need to run: sudo aticonfig --initial and then reboot.

That newly created package should work for the entire 2.6.39 series.

Ubuntu 2.6.39 kernel and fglrx 8.831

glxgears

For those 10.10 Maverick users with 2.6.38 or 2.6.39 (64-bit) kernels, you can get fglrx playing nicely together with X.org 1.9.

Unfortunately this new driver does not support X.org 1.10 and that leaves 11.4 users to use the open-source drivers.

Custom build procedure:

  1. Install the latest 2.6.38 or 2.6.39 kernel revision from Ubuntu Mainline.
  2. Download 64-bit 11.3 from AMD
  3. Extract the files from the package: sh ./ati-driver-installer-11-3-x86.x86_64.run --extract ati
  4. For 2.6.38 and up, download these patches: makefile_compat.patch and 2.6.38_console.patch
  5. For 2.6.39 support, download this additional patch: 2.6.39_bkl.patch
  6. Check for Big Kernel Lock usage: cat /lib/modules/`uname -r`/build/.config | grep -c CONFIG_BKL=y If the result of this command is 0, then download no_bkl.patch as well.
  7. then apply them: cd ati; for i in ../*.patch; do patch -p1 < $i; done
  8. Build your new ati/fglrx deb packages: ./ati-installer.sh 8.831 --buildpkg Ubuntu/maverick
  9. Install our newly created deb packages: sudo dpkg -i ../fglrx*.deb
  10. If your /etc/X11/xorg.conf is missing you will need to run: sudo aticonfig --initial and then reboot.

That newly created package should work for the entire 2.6.38 or 2.6.39 series.

Ubuntu 10.10 Maverick with 2.6.38 kernel and fglrx 8.812

glxgears

X-Swat has not updated their ati packages in a long time which means that Natty users and Maverick users with 2.6.38 (64-bit) cannot run with fglrx video drivers.

In order to get the latest 2.6.38 kernel and fglrx playing nicely together you will need to build these packages yourself.

Custom build procedure:

  1. Install the latest 2.6.38 kernel revision from Ubuntu Mainline.
  2. Download 11.1 from AMD
  3. Extract the files from the package: sh ./ati-driver-installer-11-1-x86.x86_64.run --extract ati
  4. Download the patch here, then apply it: cd ati; patch -p1 < ../2.6.38_console.patch
  5. Build our new ati/fglrx deb packages: ./ati-installer.sh 8.812 --buildpkg Ubuntu/maverick
  6. Install our newly created deb packages: sudo dpkg -i ../fglrx*.deb
  7. If your /etc/X11/xorg.conf is missing you will need to run: sudo aticonfig --initial and then reboot.

That newly created package should work for the entire 2.6.38 series.

Ubuntu 10.10 Maverick with 2.6.37 kernel

glxgears

If you want the latest (read bleeding edge) kernel that the Ubuntu developers are working, then have a look here:

Ubuntu Dev Kernels

Be sure to download the 3 files matching your architecture and install.

I am currently using 2.6.37-rc3-natty which will be the kernel that Natty Narwhal (11.04) will be based on. It just works, everything is detected and there is a noticeable increase in responsiveness.

Previously I posted about the 200~ kernel patch to increase desktop responsiveness. You do not need to wait for a new kernel or recompile one yourself to test the benefits. According to this Linux kernel mailing list: While the correct way is to implement it in kernel to be transparent to the user, you can enable it with a few quick entires in to your ~/.bashrc file. if [ "$PS1" ] ; then mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$ echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks fi

Then, as the superuser do this: mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu mkdir -m 0777 /sys/fs/cgroup/cpu/user

"Done. Same effect. However: not crazy."

Thank you Lennart.

xorg 1.9 versus fglrx

With the release of Ubuntu (Meerkat) 10.10 just 10 days away, the ubuntu x-swat people have been busy getting fglrx ready for release. The fglrx now compiles against latest Meerkat kernel and finally resolves the unknown symbol issue.

xswat-64

In the laptop is a ATI Mobility Radeon HD 3670 and with the latest fglrx driver usability is awful. There is horrible tearing when using "Appearance -> Visual Effects -> Normal", which had to be set back to "None" just to be usable. Even on "None", scrolling down in documents, chrome, firefox and Skype all give blurred or stuttered graphics.

These are for me "do not use" releases.

There are so far two updates. The first one gets fglrx up to date to latest Meerkat.

fglrx-installer (2:8.780-0ubuntu1) maverick; urgency=low * New upstream release. - Fix build issues with kernel fix for CVE-2010-3081 (LP: #642518). - Add compatibility with 2.6.35 kernels (LP: #573748). - Add compatibility with xserver 1.9 (LP: #630599). * Make the driver Depend on the appropriate xserver-xorg-video-$ABI (LP: #616215).

The latest update adds 2.6.36 kernel support:

fglrx-installer (2:8.780-0ubuntu2) maverick; urgency=low * debian/fglrx.postinst: - Call dpkg-trigger with "--by-package". * Add add-compatibility-with-2.6.36-kernels.patch: - Fix build issues with 2.6.36 kernels. * Add use-cflags_module-together-with-modflags.patch: - Fix build issues with kernels that don't have MODFLAGS and use CFLAGS_MODULE.

There will hopefully be more releases soon that help to resolve these issues

Ubuntu 10.10 Maverick Meerkat on Dell Studio XPS 1640

After a brief time with Karmic (10.04), the laptop was upgraded to the beta of Maverick. Everything works out of the box with no additional tricks necessary in getting the Dell Studio XPS 1640 fully functional.

ubuntu-maverick-meerakat

The only drawback I found in upgrading from Karmic was the loss of fglrx as a xorg-server driver. Maverick is shipping with the 1.9 version of xorg-server which is ABI incompatible with what fglrx is compiled against.

The exact error is: undefined symbol: savedScreenInfo which causes X not to start.

The rumour is that ATI will release a fglrx package that is compiled against 1.9 version of xorg-server when Maverick ships on Sunday, October 10th.

Compiling the fglrx against the latest kernel is also not a problem if you follow the advice found here.

This does not impact a good desktop experience with your "Visual Effects" set to "Normal". By default, Maverick ships with the latest radeon driver that xorg-server which is good enough to handle all those lovely desktop effects. I recommend this driver over fglrx because:

  • it is opensource
  • has acceptable 2d/3d performance
  • it is not a resource hog
  • the laptop will no longer burn your lap

I will continue testing against fglrx and I look forward to the final release.

Maverick Meerkat Release Schedule

UPDATE: If you have upgraded to Maverick and switched to the radeon driver after first having fglrx, you will need to purge your fglrx drivers. What happens is that X will start with the radeon driver but load your fglrx glx libraries and cause a segmentation fault or garbled screen.

To fix this: aptitude purge fglrx fglrx-amdcccle fglrx-modaliases xorg-driver-fglrx fglrx-dev