My thoughts on Slackware, life and everything

Month: June 2010 (Page 1 of 2)

Release candidate 1 of KDE SC 4.5

The sources of KDE Software Compilation 4.4.90 (which is  in fact Release Candidate 1 of the upcoming KDE 4.5) have been available on KDE’s ftp server for some days now.

There is still no official announcement from KDE team about this RC1 but it will without doubt appear soon on after the weekend.

In the meantime I have been building packages (32-bit and 64-bit) that you can install on Slackware 13.1 or -current. See my ktown repository for installation/upgrade instructions.

Please note that this release candidate will likely still have bugs – if you find any please report them to so that we can expect a great 4.5 release in august.

You can download 4.4.90 from the server using http:

lftp -c “open ; mirror 4.4.90”

or using rsync (mind the dot at the end):

rsync -av rsync:// .

Also next week, there will be a release of KDE SC 4.4.5 (the last in the 4.4 series) and if everything goes as planned, this should end up in slackware-current – meaning, I won’t have to build packages for 4.4.5.

Cheers, Eric

VLC 1.1.0 has been released

VideoLAN team has released version 1.1.0 of their VLC player.

This  release has many improvements over the previous 1.0.0 version of this “swiss army knife of media players“.

A detailed description of the changes can be found in the team’s announcement of the new release. You can also have a look at the supported features of the player.

Slackware packages are available for you: . I’ll be happy with feedback from you, if you are using my package. Please note that you do not have to install any other package if you use mine. There are no package dependencies (except for libdvdcss which you have to install additionally if you want to watch “encrypted” DVDs – which means almost all DVDs).

Please note that the VideoLAN developers have decided to deprecate all older versions of their player. This means that as soon as a vulnerability is discovered in releases before 1.1.0, this vulnerability will not be patched and you will be urged to upgrade to 1.1.0 (or later) instead.

This decision was made because the developer team is currently stretched thin and is unable to maintain more than one stable and one development branch.

Have fun with this great piece of software!


Decoding HD video in VLC

In past posts, I talked a bit about video decoding in VLC, particularly using the GPU (your graphics card’s processor) to decode frames instead of letting the software do all the work. My previous posts mostly revolved around the fact that this did not yet work in the release candidates of VLC 1.1.0 (which will hopefully be released soon).

There is good news however! Last weekend, the bug in VLC was fixed which made the player crash as soon as the VAAPI functions were called. My updated packages (32-bit and 64-bit) for vlc-1.1.0-rc3 are available now, with the patch included, and indeed I have no more crashes. Get those new RC3 packages and enjoy!

So, what is this GPU supported hardware decoding of video and why is it beneficial?

High Definition video has become a de facto standard on the internet, and lots of home video recorders save in HD format too. Playback of a HD video on your computer will stretch the limits of what your CPU can do… resulting in stuttering playback (dropped video frames) or display artefacts because the CPU can not keep up.

This is where the Video Acceleration API (VAAPI) originally drafted by Intel, and adopted by other hardware vendors (Nvidia and Ati of course) comes into play. VAAPI is a software interface which provides access to hardware accelerated video processing, using your computer’s  GPU which is very much suited for computationally intensive operations. For instance, owners of a Nvidia graphics card will notice that VAAPI-supported HD playback will drop the CPU usage from 100 to 30 or less percent.

My VLC package supports VAAPI hardware acceleration, if you add the following package(s):

  • libva: your computer will at least need this one. This is the library which exposes the VA API and adds the driver which VLC will use if your graphics card is an Intel one.
  • vdpau-video: this is only needed if your graphics card is an Nvidia. Vdpau is Nvidia’s own acceleration API and this package adds a VDPAU backend to libva.
  • xvba-video: this is only needed if you own an Ati-powered graphics card. This package adds a XvBA backend to libva. Unfortunately (for you) I do not own an Ati card, so I can not compile this software into a Slackware package. Get the sources here and compile them yourself, after you installed my libva package.

I should mention one caveat:

It depends on your hardware, how good the support for GPU-accelerated video processing is. An Intel card can only accelerate MPEG-2 video, whereas Nvidia and Ati cards will also support acceleration for MPEG-4/H.264/VC-1 video formats. Note that hardware-acceleration is not limited to HD video. VAAPI will for instance be beneficial to Atom-powered netbooks too, their Intel graphics will allow fluent full-screen playback of DVDs in VLC with low CPU usage, thereby saving your battery.

You can easily determine what your card’s capabilities are. After installing libva, run the “vainfo” command and examine the output. This is what my T410 laptop reports:

$ vainfo
libva: libva version 0.31.0-sds6
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/va/drivers/
libva: va_openDriver() returns 0
vainfo: VA API version: 0.31
vainfo: Driver version: i965 Driver 0.1
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple            : VAEntrypointVLD
VAProfileMPEG2Main              : VAEntrypointVLD

Have fun! Eric

Beta alert: KDE 4.5 beta2 for the adventurous

I hinted at this in my previous post; I have been building packages for the second beta of KDE SC 4.5.

I was not so sure if I should make them publicly available after I had installed them on my laptop running Slackware64 and very soon, noticed some serious issues:

  • I can not have virtual desktops with separate widget sets for instance.
  • I had some initial problems with KDM which is now configured to run as a non-existing “kdm” user – but I patched “/etc/kde/kdm/kdmrc” and reverted to the old, working, situation.
  • The drop-down menu when you click on the “cashew” in the top-right corner has many double or even triple entries, which is very annoying

However, in the meantime I received positive feedback from people who are eager and willing to test the beta packages. Good, thank you! That made me feel all warm inside!

All the joking aside, I am glad with the reponses to my blog posts. It’s what drives me to create these packages for you.

Here they are (64-bit as well as 32-bit):

You’ll notice that there are a few updated dependencies and one new package, libdbusmenu-qt. Grab those too! There are no pre-compiled language packs for now (I just lacked the time), but I have added the sources and updated the build script for “KDEI” so you can easily build a single package yourself. For example, compile the “nl” language pack with this command:

# PKGLANG=nl  ./kde-l10n.SlackBuild

Good luck! Don’t forget to report the bugs you find at and feel free to discuss them in the comments section of this post.

By the time KDE4.5 sees its first Release Candidate, I will have updated the Qt4 package too. At this moment I did not want to diverge too much from Slackware 13.1.

Cheers, Eric

Fiddling with the KDE 4.5 beta

Although it seems (by looking at the changelog between 4.4.3 and 4.4.4) that there were no spectacular updates in the latest stable KDE Software Compilation, I got some feedback that 4.4.4 does feel “snappier” than the 4.4.3 which is part of Slackware 13.1.

Good news (that people actually use my packages)!

It made me think again about the upcoming KDE SC 4.5 for which the second beta was released very recently (the sources at least). I had not really planned on a Slackware build for KDE 4.5 until I had access to the stable sources, which will not happen all too soon.

But if even a small (bugfix) upgrade is received so positively, some people may find it interesting or challenging enough to get their hands dirty with the new beta release. So I decided to move ahead, locate the updated and new dependencies and start building packages.

At this moment there are no kdepim packages planned for KDE 4.5. The kdepim developers decided that the current quality of their software is not high enough to be included in KDE 4.5 – they expect kdepim to be re-integrated into KDE SC 4.5.1 and will release preview versions on their own in the meantime.

The software requirements for 4.5 are not yet written down like they are for older releases, but after reading through the mailing lists I have a feeling that I will have to upgrade Qt to 4.7 in the end. There is no such Qt release yet… so at some point I will start using source snapshots from the Qt git repository.

Not right now however, because the compilation recognized my already installed Qt 4.6.2 and did not complain about that. Tonight I will finish a 64-bit build of KDE SC 4.4.85 (aka 4.5-beta2) and install that to my laptop. If that does not break everything, I will also build a set of 32-bit packages and release the lot to my “ktown repository“.

Let me know if you are interested in tying out the beta! If there is no interest, I may leave it at just the 64-bit packages and use the time to debug my VLC package (which seems to crash on VAAPI support).

Watch this space for more news, soon (I hope).


« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑