Doesn't Not Compute

My log of experiences with GNU/Linux and computers in general.

Category Archives: Experiments

Xbox Tweaking: Jedi Academy

Today’s post will be pretty useless for anybody that doesn’t have a modified Xbox that is NOT a 360, a copy of Star Wars Jedi Knight: Jedi Academy for the Xbox, and said game backed-up to the hard drive of that Xbox. I won’t be describing how to modify the Xbox, as Xbox-scene can describe it quite thoroughly. ๐Ÿ˜‰

Some games that were released for the Xbox have configuration files, even though the final product was intended to be placed on non-changeable discs. :mrgreen: Since these games were also released for a certain computer operating system, and have known tweaks that can be done there, it seems logical that at least some of those tweaks can be used in the Xbox version.

And today I decided to try digging around in the configuration of Star Wars Jedi Knight: Jedi Academy.ย  This game uses the Quake III: Team Arena engine, so theoretically it can use any of the tweaks the engine recognizes, right?

Well, not on the Xbox.ย  It seems that some things work, such as enabling the Frames Per Second display; others do not, such as trying to force the rendering mode to a less intensive method. I suppose those are hard-coded in the executable (default.xbe), and override the configuration file (base/default.cfg). ๐Ÿ˜ฆ

The rest of this post containsย  what tweaks I’ve attempted alongside whether they worked or not. Expect this post to be updated from time to time, and don’t expect me to try anything that has to do with multiplayer ping and such. ๐Ÿ˜€

Read more of this post

Trying To Deal With Compressed SWF

We all know Flash is a major pain — from Adobe’s own Flash player’s lack of performance to the security problems and nonfree status of said plugin. Not to mention the often-poor compatiblity of the free players, such as Gnash and Swfdec. So I won’t be discussing that right now. Nor will I be discussing the somewhat well-known process of using MPlayer to play Flash video files (.flv).

Today’s note is on dealing with those pesky .SWF Flash animations. While Swfdec-gnome is relatively decent at decoding the few I deal with, I’d like to convert these animations to a video format, such as OGG Vorbis or WebM. Why? Because unlike with Flash videos (.flv files) such as found on YouTube, .SWF files are almost always compressed — and FFMPEG can’t deal with compressed .SWF files. The result being, MPlayer can’t play them.

I really don’t expect it to, anyway — MPlayer is an audio and video player, NOT an animation decoder and player. But I’m very tired of needing a Flash decoder just to watch the animations of MSPA‘s Homestuck adventure comic, when it would be better for people with slower computers and a dislike of nonfree software to serve videos.

So, during a couple breaks from my efforts on Project Permafrost, I’ve been trying to find a way to convert these SWF animations. I’ve had very little luck so far — while there is some software for the job, it’s virtually all for a certain operating system from a company in Redmond, WA, USA. Most of this software works by taking the displayed output from a Flash plugin and converting it to a video — a very CPU-intensive and hacky solution. Video files were created, but they were composed only of empty, black frames with no audio.

Since the only converter I could find for my operating system was useless, I next turned to the tools for creating and modifying the SWF animation itself, and thus to the swftools and flasm packages.

Swftools is a collection of tools for working with Adobe Flash files, as you may have guessed. Flasm is for disassembling and modifying the Flash Actionscript bytecode, and supports SWFs produced by Flash 8 and earlier. Sounds complicated? Yeah, seems that way to me too, and sadly I don’t have time to investigate them deeply right now.

What I did find, by reading the help text for both the swfextract tool (found in the swftools package) and Flasm, was two options that inspired some hope. From swfextract:


Sound extraction:
-m , –mp3 Extract main mp3 stream

And Flasm:


-x Decompress SWF

These suggest three courses of action. In each case, “file.swf” should be replaced with the name of the SWF file you’re working with, of course. ๐Ÿ˜‰

The first is simply copying out the audio directly from the SWF animation.

swfextract -m file.swf

This produces a file named “output.mp3” in the same directory you run the command from.

The second course of action is to decompress the SWF file, so MPlayer can work with it.

flasm -x file.swf

This will, obviously, decompress the SWF file. The original is saved with a “$wf” extension. MPlayer can play the resulting uncompressed SWF file, but (in my case, at least) can only play the audio.

The third option, of course, is to ask the author(s) to release a video format conversion themselves. :mrgreen: They may be hesistant to do so, of course — they may wish for people to HAVE to come to their site to view the animation, instead of someone uploading the video to YouTube or someplace similar. This could be slowed by requiring people to pay for the video, I suppose, but also partially defeats the purpose of the entire endeavor — the goal of which was to be able to easily watch the animation on a computer without needing Flash or putting the CPU under maximum load for the several minutes of the animation.

It’s progress, I guess. If one can call only being able to listen to the animation “progress”. ๐Ÿ˜ฆ I’m getting back to work now. ๐Ÿ™‚

iPod Nano 2G Fun: Rockbox r27995 Update

I’ve been poking around at the current build (r27995-1000903 at the time of this writing) of Rockbox today, and other than the occasional random panic (oh joy) that locks up the iPod and requires a reset — harmless but annoying — it’s even better than the previous version I was using (r24509-100204).

For example, I previously had to use iLoader to load Rockbox, as for some odd reason attempting to transfer ANYTHING after the initial Rockbox installation resulted in a White Screen of Death (WSoD) upon the next startup/reboot with the Rockbox bootloader. Now there is a revamped version of iLoader, designed around the new emBIOS, and I have had NO luck getting Rockbox to load at all. iLoader just freezes/stalls at “Booting Rockbox”. I’ve talked with a few of the folks working on that project, and so far only myself and one other person have reported it. Something about my Nano 2G have a revision 7 board, while a developer has a revision 9 that doesn’t have the problem? ๐Ÿ˜ EDIT: Issue fixed in r188 of iLoader, released as iLoader v0.2.1. Kudos to TheSeven!

Meanwhile, the Rockbox bootloader works perfectly and I have no WSoD issues at all, even after transferring several hundred megabytes of OGG files. (And one MP3 . . . ๐Ÿ˜ฎ )

So I think it’s time to replace my how-tos on Rockbox.

Although I prefer to restore the iPod to it’s stock state before installing a new bootloader, this is only necessary if you used an older, pre-emBIOS version of iLoader. It is NOT necessary if you used the Rockbox loader. Feel free to skip to the “Installing Rockbox Software” section if you didn’t use a pre-emBIOS iLoader. (Or if this is your first time “jailbreaking” your Nano)

Also, this is NOT about updating the iLoader version after you’ve installed it. That’s it’s own procedure, one I’m still learning about and isn’t covered in the Wiki yet. You can learn about that on the iLoader webpage.

Restoring to Stock, Apple-firmware State

First, (with permission) borrow someone’s Windows-laden machine and uses iTunes to restore the iPod Nano 2G to stock firmware, if you’ve installed an older version of Rockbox on it before. Allow the restore process to finish — the progress bar beneath the Apple logo will fill completely and the iPod will reboot. Assuming all went well, the iPod will load the stock firmware and a “Do Not Disconnect” message will appear.

Installing the Rockbox Software

Reset the device (Menu+Select) (Select is that button in the center of the scrollwheel) and when the Apple logo appears immediately press Select+Play to enter disk mode. The timing can be a bit tricky, so you might need to do it a few times for it to work.

At this point, you need to extract the Rockbox zipfile directly to the iPod. For example, if your iPod Nano is mounted to /media/IPOD, this command (from the directory you downloaded the zipfile to) will do the job:

unzip rockbox-ipodnano2g.zip -d /media/IPOD

Or if you prefer a GUI, use your GUI’s archive program to extract all of the contents of the zipfile directly to the iPod Nano’s storage partition (which is the folder newly-mounted under /media in distros that mount drives automatically, like Ubuntu).

Installing the Rockbox Bootloader

Now we install the bootloader. We’ll need the ipodpatcher program (32-bit version, 64-bit version) here. Again, change to the directory you downloaded the files from before running this commands.

chmod +x ./ipodpatcher
sudo ./ipodpatcher

Put in your password if necessary, then press “i” and then ENTER to install the bootloader.

If all goes well, something like this will be spouted out at you:

[INFO] Creating OSBK backup image of original firmware
[INFO] Using internal bootloader – 54336 bytes
[INFO] Padding input file from 0x0000d440 to 0x0000d800 bytes
[INFO] Wrote 55296 bytes to firmware partition
[INFO] Bootloader installed successfully.
Press ENTER to exit ipodpatcher :

Safely remove the device (sudo eject /media/IPOD should work well, where IPOD is the folder your iPod Nano 2G was mounted to.)

Now your iPod Nano 2G will reset and quickly load your new firmware. Have fun! I’ll have a couple more posts about this in the next day or two.

Aspirin for the GMA500 Headache

While I haven’t completely figured out the problems I talking about a couple days ago, I’ve made some progress and feel I should share the details with you and my future self — who will undoubtedly have forgotten this and had to look it up. :mrgreen:

While I still can’t can’t get VA-API acceleration working, I did track down the reason I couldn’t get ordinary XVideo acceleration: that’s handled through the Xpsb.so blob, which REQUIRES Xorg-server 1.6.

So, I installed Xorg 1.6, following the directions in the Arch Linux Wiki’s “Poulsbo” article. That includes instaling openssl-compatibility from the AUR, as Xorg 1.6 requires a slightly older version of openssl. Afterwards, I removed, rebuilt, and reinstalled the PSB driver packages (just in case) and started up the Xserver. I then opened a terminal, and used Mplayer try playing the H.264 720p encoding of Big Buck Bunny with XVideo acceleration. (-vo xv, if you didn’t know.)

It worked perfectly.

I have no clue if XVideo offloads the decoding to the SGX 535 chip the GMA500 hardware incorporates, like VA-API supposedly does with the right driver, but the playback is certainly a lot smoother than plain X11 rendering.

As for why I can’t get the VA-API acceleration to work, even after copying a blob to where it’s expected to be, it seems to be because the modern libva used in Arch Linux is not compatible with the older libdrm-poulsbo software. I’ve tried recompiling it, but that doesn’t help at all — and requires the standard, non-Poulsbo-driver-compatible libdrm to compile at all. I’ve tried changing the PKGBUILD to not conflict with the newer, standard libdrm, then compiling and force-installing libdrm-poulsbo, and then compiling and installing libva; when I tried to start Xorg up, though, the conflicting libdrm versions crashed Xorg. As expected.

So, the headaches continue, but are at least partially dealt with. Now, not only do I have backlight control, native resolution, and proper font DPI, but I can even play HD movies comfortably. ๐Ÿ˜€ Now I just have to sort outย  that pesky, pesky libva issue — and perhaps figure out why XvMC still doesn’t work.

GMA500 Headaches on Arch

For the past several days, my free time has been occupied with only a few things: restructuring the Arch Linux wiki’s Poulsbo article, enjoying rather delicious vegan “Sloppy Joes”, and wrestling with the ancient “PSB” binary blob driver. Today I’m just dumping a few things I’ve figured out about it.

First thing is about why I can’t get the accelerated video playback, via VA-API, to work. libva, which is responsible for allowing such things as mplayer-vaapi to use the PSB driver’s capability to access the GMA500’s H.264 acceleration abilities, looks for something called “psb_drv_video.so”. With the current PKGBUILDs in the Arch User Repository, this file is installed, under

/usr/lib/va/psb_drv_video.so

but libva is configured to look for it in

/usr/lib/dri/psb_drv_video.so

So, after copying that over to where its expected to be found, you’d expect everything to work, right? Nope.

libva: libva version 0.31.1
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/psb_drv_video.so
libva: error: /usr/lib/dri/psb_drv_video.so has no function __vaDriverInit_0_31
libva: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Looks like Arch’s current version of libva is looking for something that didn’t need to exist back when the binaries were made. And, although the open-source parts of the driver have been patched to work with Xserver 1.7 and newer, this can’t be done with psb_drv_video.so because it’s a BLOB. ๐Ÿ˜ก So, no mplayer -vo vaapi -va vaapi

Second issue is similar: I couldn’t get XV accelerated video to work. Mplayer either complains that it can’t find an XVideo-capable card or some-such, or a window is drawn for Mplayer — and the Xserver completely locks up, except for the mouse. Progress? :mrgreen:

The reason, according to the GMA500 wiki, is because that capability is handled by another blob: Xpsb.so. So, no mplayer -vo xv. ๐Ÿ˜ก

The third issue is due to both blobs depending on a modified libdrm 2.3.0 — while Arch Linux’s Mesa OpenGL implementation is compiledย  against libdrm 2.4.something. I’ve tried compiling a similarly-patched libdrm 2.3.4 from the tarball in the Ubuntu gma500 PPA, but that didn’t create drm-psb.ko — which is rather necessary for everything to work.

So, pros and cons of using the PSB blob with Arch Linux:

Pros:

  • Can use current kernel (2.6.35-ARCH)
  • Can use current Xorg-server (1.8.1.something)
  • Full, native resolution
  • Backlight control (see my how-to on this)

Cons:

  • No VA-API acceleration
  • No XVideo acceleration (and quite likely will lock up your Xserver — won’t even be able to switch to a terminal)
  • No OpenGL/Mesa ANYTHING.

At least with the FBDEV driver I can try some software raster whatchamacallit for OpenGL. (Yes, that is indeed a word — I misspelled it and Firefox corrected me. :P) The backlight control, however, is more important to me. And I can’t run Xorg with the FBDEV or VESA driver over a PSB-module-set framebuffer, either — it crashes with a static underline cursor with the former and distorts and repeats everything with the latter.

My next attempt will be to use the procedure normally reserved for IEGD driver experimentation to downgrade to Xorg-server 1.6, and try again with the PSB driver. 1.6 was the latest server version that worked completely, I think . . . if the video works then, I’ll try building whatever version of Mesa was current back when libdrm 2.3 was. I think that was 7.0.4, but I could be wrong, and that’s not even in the Mesa repositories anymore. I have to go on Sourceforge for it, and would have to heavily modify the PKGBUILD. *sigh*

Or I could just use Jolicloud — but then I’d have a LOT of hacking-away to do.

Or I could use Ubuntu 10.04 — but then I’d still have a lot of hacking-away to do.

Thus the headaches.

Thank you so much, Intel, for licensing Imagination Technologies’ PowerVR SGX 535 to use in your System Controller Hub series. >_< At least Nvidia keeps their blobs current.

emerge n00b

Lately I’ve been trying out Gentoo Linux. (It’s GNU/Linux, in my view, but that’s a whole different discussion.) For me, someone for whom experimenting with and using various distros has been a major hobby for several years now, it’s a fun operating system. I like having the option to have a full GUI with popular software, a la Linux Mint, if the machine can handle it; I also like the system to be as responsive and fast-booting as possible. Which isn’t always what Linux Mint is — and why I like Arch Linux so much.

But Arch Linux isn’t always perfect for me — I’ve had a great gaming machine put together, running Elder Scrolls 3: Morrowind with some mods in WINE at an enjoyable 34FPS or so before. And then I made the mistake of updating without checking to make sure the FGLRX driver worked with the new kernel, Xorg version, or other software. ๐Ÿ˜ณ And I stupidly cleared my pacman cache before testing anything, just assuming everything would still work as it had for several months. ๐Ÿ˜ณ *insert facepalm here*

So, several months later, I thought back to that.

“You know, I really liked the speed of that Arch gaming rig, and I want to build a home server like that guy at college had. But Arch changes too much. And I don’t like having to edit PKBUILDS to not install things as build-dependencies. I liked those Gentoo Portage USE flags . . . ooh, it’s teh kitteh!”

*several minutes later*

“Hmm, what was I thinking about?”

*twenty more minutes, and a can of spinach, later*

“Oh, right, the Gentoo thing. Hmm. Well, now that I have better machines than that 800MHz PIII Gateway I tried it on before, why not?”

Yes, that was my actual thought-process. ๐Ÿ˜›

Anyway, the Gentoo Handbook was more than sufficient to get me up-to-speed again and install everything — and using only ~20MB of memory with Xorg, IceWM, and a terminal running after a ~10 second boot (after GRUB) was more than sufficient to convince me to stick with it. I later wiped that installation out for another project, despite having taken about five hours to install and another two to get a working fully-minimalized kernel compiled, but I’m too much of a Gentoo-fan to leave it now.

Now, for my point.

I installed Gentoo again on an HP Pavilion a1130n, this time as a 64-bit home-server project. Even though I plan to not allow it to access the internet, I decided to make it Hardened Gentoo for the experience. No problem, just had to switch to a hardened, no-multilib profile, re-emerge the toolchain, and “emerge -e world”, right?ย  Right, I suppose — except I also wanted to bootstrap the install so that EVERYTHING was optimized for my processor.

Both were explained, between the regular Gentoo FAQ and the Hardened Gentoo FAQ — but I didn’t see anything about doing both at once, so I guessed. I changed to the hardened-nomultilib (not it’s real name, but shortest summary) and then ran the bootstrap.sh script as described in the Gentoo FAQ here. Some time later, it finished rebuilding the C library and the toolchain, and I tried the final step listed in the process the FAQ described:

emerge -e world

only to get a rude error on the second package — the compiler couldn’t be found. ๐Ÿ˜ฎ

I did some digging (Scroogled for the error message) and discovered that the GCC profile probably wasn’t valid anymore, and that I needed to change it.

“Well, how do I do that?”

*more Scroogle.org searches*

“Okay . . . gcc-config -c, get the current profile — yep, current profile invalid. List profiles, gcc-config -l . . . and set to that profile. Try emerge -e world again — WHOA, it worked!!”

Don’t you love it when mistakes are that easy to fix? :mrgreen:

So, to summarize: if you try to bootstrap your system according to the Gentoo FAQ’s instructions, and you can’t compile anything afterwards, it might be because by re-emerging the compiler you got a newer version and your gcc profile is no longer up-to-date. Just

  • “gcc-config -c” to see if it says the currently selected profile is invalid
  • “gcc-config -l” to see what profiles are available
  • “gcc-config x”, where x is the profile listed.

No guarantees, but this was the problem in my case and this fixed it. ๐Ÿ™‚ Happy Gentooing, and may the Source be with you.

P.S.: This really helped me figure things out. (Caution, link is to code.google.com — might want to clear your cookies after you visit.)