1. Installing the Intel GMA 500 graphics driver

The Ubuntu Wiki has all the necessary information here.

Basically one just needs to do as follows:

sudo add-apt-repository ppa:gma500/ppa
sudo apt-get update
sudo apt-get install poulsbo-driver-2d poulsbo-driver-3d poulsbo-config

UPDATE: The following step is no longer required.

Unfortunately the version as of this writing does not support Compiz and thus you won’t get any of the funky special effects. However, there is a workaround available as described in the Ubuntu Wiki:

wget http://dl.dropbox.com/u/1338581/poulsbo/poulsbo-config_0.1.2%7E1004um3_all.deb
sudo dpkg --install poulsbo-config_0.1.2~E1004um3_all.deb
sudo apt-get install compiz

2. Installing the Fujitsu Buttons driver (fjbtndrv)

In order to get the buttons and auto-rotation functionality working we will need to compile and install the latest version of fjbtndrv.
The most current version as of this writing is 2.2.1. Please make sure you download the latest version here.

sudo apt-get install libxrandr-dev libxtst-dev libxi-dev libhal-dev
wget http://sourceforge.net/projects/fjbtndrv/files/fjbtndrv/2.2.1/fjbtndrv-2.2.1.tar.gz/download
tar xvzf fjbtndrv-2.2.1.tar.gz
cd fjbtndrv-2.2.1
./configure
make
sudo make install

3. Installing the Fujitsu Touchscreen driver

The touchscreen is working somewhat with the included evdev driver. I could not find a way to calibrate the touch screen via xinput etc. So I went back to using zmiq2‘s touch screen driver available here.
Version 0.3.7 won’t compile because some important USB functions were renamed in kernel 2.6.35.
Straight from the kernel 2.6.35 changelog:

USB: rename usb_buffer_alloc() and usb_buffer_free() users

For more clearance what the functions actually do,

usb_buffer_alloc() is renamed to usb_alloc_coherent()
usb_buffer_free() is renamed to usb_free_coherent()

So, one either needs to patch the fujitsu_usb_touchscreen.c manually and replace every occurrence of the aforementioned function names or we just move on and use the already patched version provided by nerd65536. I mirrored the file he posted to the hosting service linked to in the comments section of zmiq’s blog post.

wget http://katastrophos.net/downloads/fujitsu-usb-touchscreen-0.3.8.tar.gz
tar xvzf fujitsu-usb-touchscreen-0.3.8.tar.gz
cd fujitsu-usb-touchscreen-0.3.8
make
sudo make install

In order to have the auto-rotation functionality of fjbtndrv working with the fujitsu-usb-touchscreen driver we need to add a new startup item: Click on System -> Preferences -> Startup Applications and click Add. Enter following

    Name: Fujitsu Touchscreen Auto-Rotation
    Command: /usr/bin/fujitsu-touchscreen-rotate.py
    Comment:

Click Add and Close the preferences dialog.

Finally, reboot the system.
Enter the BIOS and make sure that the setting Advanced -> Miscellaneous Configurations -> Touch Panel Setting is set to Tablet, ie. the same setting that is required to use the Tablet functionality in Win XP Tablet, Vista or Seven.

3.1. Calibrating the touchscreen

Once the system has booted and you are back on the Gnome desktop, start a Terminal session and run

fujitsu_touchscreen_calibration.py

to calibrate the touchscreen. Click on any corner of the visible screen (repeat a few times) and press the S key to save the settings.

3.2. Configuring the Right-Click feature

In order to get the feature “right-click by press and hold” go to System -> Preferences -> Mouse, click the tab “Accessibility” and check the option “Trigger secondary click by holding down the primary button“.

4. Fixing the repeating sound issue

If you are experiencing the Ubuntu startup jingle repeating over and over again, the snd_hda_intel module might have problems coping with the ALC269 chip in your device. In this case run the following command:

sudo gedit /etc/modprobe.d/alsa-base.conf

and add the following line to the end of the file:

options snd-hda-intel enable_msi=0

Save and finally reboot the system.

The process is quite involving and not for the faint of heart. Here are some snapshots of the process:

Some of the pictures show my 3G/HSDPA mod.
Also check out the interesting forum thread over at pocketables.

Today I’m releasing QScrobbler: a Last.fm / Audioscrobbler add-on for Quasar Media Player.

As with Quasar, I’ve been using QScrobbler for almost a year now and finally decided it is ready for the public. ;)
For more details please visit the project’s homepage here.

Finally! Almost a year after the first mentioning of my new media player for the Sharp Zaurus and after several development hiati, I’m today officially releasing the Quasar Media Player for SharpROM- and pdaXrom-based distributions.
For more details please visit the project’s homepage here.

• ability to set and control Treble, Bass and 3D stereo sound enhancement;
• ability to set and control various cut-off frequencies supported by the sound chip;
• output source selection (Autodetect, Internal Speaker, Headphone).

These features can be easily accessed via a Qt based mixer control app or directly via a /proc/driver/wm8750 kernel interface.

Both, the driver and the control app are available for Sharp ROM / Cacko ROM and pdaXrom beta 3 / pdaXii13.

Kernel patches are available for Sharp’s Linux kernel 2.4.20 and can be downloaded here:
http://www.katastrophos.net/zaurus/sources/wm8750mixer/
(No kernel 2.6.x support yet. Sorry folks.)

By default the audio driver is compiled into the kernel. Sharp didn’t compile it as module, so it can’t be easily replaced. Same goes for most third party ROMs. You’ll have to reflash your kernel to install the new driver.
In case you don’t want to roll your own kernel, I’ve made pre-compiled kernels available for all supported ROMs and models here:

http://www.katastrophos.net/zaurus/kernels/v55/

The control app and start up scripts are available as IPK here:

wm8750mixer_0.9_arm.ipk – WM8750 mixer for Sharp ROM / Cacko ROM
wm8750mixer_0.92_armv5tel.ipk – WM8750 mixer for pdaXrom beta 3 / pdaXii13

On a side note, we’ve been discussing the extended features of the WM8750 audio chip for quite some while in this thread over at the OESF forums. I have the feeling the driver and the Qt application have received a fair bit of testing. So, that’s why I am officially releasing it today.

So, here is a short update on the media player that I’m currently developing for my Zaurus. Well, actually it’s been in long-term testing mode for ages now… :)
I finally have a name for it. It will be called “Quasar Media Player” – or shorter “Quasar”. Below are some screenshots of the current development version running on Qtopia. I hope to have a release ready soon.

Again, I’ve been working on improving performance – this time on the performance when loading playlists.
Before I continue, let me give a brief overview of the structure:

Library -> Playlists < -> Media Cache

YAZMP doesn’t manage a library similar to i*Tunes. Instead it solely relies on playlists. Metadata (title, artist, album, etc.) is kept in the database and will be associated to once the playlist is loaded. The reason for this is pretty simple: Scanning audio files (and media files in general) each and every time a playlist is loaded will definitely take a lot of time. So, for every file the gathered metadata will be saved in the DB. Think of it as a cache.

ZPlayer, which YAZMP is based on, follows a similar approach. However, in my opinion it’s ill-conceived in the current version. It keeps the media cache in memory all the time. With lots of files this can get very expensive. Also, ZPlayer isn’t very efficient at saving the media cache to disk. It does so for the whole cache, not just changed entries. Furthermore, when saving the cache on quitting, ZPlayer sometimes simply truncates the cache file and all metadata is lost. So, next time you open it, it has to scan all files again…
Perhaps I’m nitpicking, perhaps I’m an optimization dork, whatever it is, please forgive my harsh words for the otherwise excellent work atty and Atmark have done in ZPlayer!

Technical ramblings

For YAZMP I rewrote the metadata cache management from scratch and extended it to do a lot more.
As I already mentioned above, YAZMP doesn’t manage any library, it only knows about filenames in playlist files.
For that to work correctly and efficient especially in combination with the media cache, there are four cases that need to be taken care of:

1. A new file has been added to the playlist which doesn’t exist in the media cache.
   This case is very simple: The player has to scan the file no matter what.
2. A file has been physically removed and it’s metadata is still in the cache.
   In this case the player has junk entries in its database, which need to be cleaned once in a while.
3. A file has been renamed, that is, it’s basename changed
4. A file or a whole directory / sub-tree of files have moved to another location.
   In a naive implementation both cases would trigger a lengthy rescan of the file(s) that are about to be added in the playlist, because new location can’t be associated with any data in the cache.
   For YAZMP I’ll use several approaches + fallbacks to try to limit the impact. The following messy pseudo-code illustrates this:

     get attributes filename, directory  from current playlist item to be added
     get attributes filesize, lastmoddate for file (directory + filename)
   
     // NOTE: check via checksum / hash for faster lookup
     if exactly one entry by hash value of (directory + filename) in DB then
       // NOTE: did the file change since the last scan?
       if entry.filesize not equal filesize or entry.lastmoddate not equal lastmoddate in FS then
         rescan file (directory + filename) and update entry in DB
       return entry
     else if exactly one entry by tuple of (filename, filesize, lastmoddate) in DB then
       // Was the file moved to a new directory? (case 4)
       // If so, check for other files in the old directory and change them
       // to the new location...
       // NOTE: this is purely predictive. It might not always yield a benefit.
       if directory by value of entry.location not in FS then
         change every siblingentry in DB where siblingentry.location is entry.location
           set siblingentry.location to directory
           set siblingentry.locationHash to hash value of (directory + siblingentry.filename)
         until no siblingentry is left
       // NOTE: did the file change since the last scan?
       if entry.filesize not equal filesize or entry.lastmoddate not equal lastmoddate in FS then
         rescan file (directory + filename) and update entry in DB
       return entry
     // NOTE: For case 3 one could check for a smaller tuple of (filesize, lastmoddate)
     // which would result in the almost the same code as above
     // The likeness of wrong results is a lot higher though.
     else
       scan file (directory + filename) as newentry and add newentry to DB
       return newentry
   

Conclusion

What that means is pretty simple: You can move your media files to a different location, perhaps a SD-Card, and the player will still be able to associate the new location in the playlist file with the data it has in cache. And that means: No useless scanning of files and fast playlist load times.

Yet another feature…

I tend to copy several albums to my Zaurus for listening on the road. So, once I’ve copied new stuff, it’s always the same mindless and inconvenient procedure in most players: Clear the playlist, add files or directories, play stuff.
And that brings me straight to another new feature: Dynamic Playlists
In general the idea is pretty simple: Instead of just listing every file’s location in a playlist file, one may also list folders that are automatically scanned for audio or video files. Here is an example:

Music.dynplaylist

/hdd3/Music/test1.mp3
/mnt/card/Music/Mozart/
/hdd3/Music/Beethoven/**

This will add a single file “test1.mp3″, all files in “/mnt/card/Music/Mozart/” and all files in “/hdd3/Music/Beethoven/” including all files in its sub-directories.

Conclusion

Instead of adding files, you just define what the layout of the playlist should look like and the player does the rest automatically. It can even rescan for changes. It’s all wrapped up in a nice UI.
Combined with the flexibility of the metadata cache and the fact that one isn’t forced into this library thing, I think this makes for a pretty unique solution. What do you think?

• Simplify the database schema as much as possible – even if that means redundant data or illogical structure
• Don’t generalize the database schema – generalization will mostly sacrifice performance and one can’t afford that on an embedded system with its tight restrictions, even if it is more convenient for the developer.
• Only use relations (via IDs etc.) where absolutely necessary. The overhead for lookup and joining tables is considerable, even with an index on the relation.
• Order the tables correctly in SELECTs. Put a table left-most if it is lacking an index on the relation. More details are here.
  In general: Check the order of tables in the SELECT statement. A different permutation may be more optimal. Profile.
• Prepare your statements and bind values where applicable. This way you can get rid of the parser and VM creation overhead in tight loops (e.g. when inserting and updating).
• Use transactions – even if you’re just reading the data. This may yield a few milliseconds.
• Use temporary tables for intermediate results. They are fast and stay in cache most of the time. Depending on how your SQLite instance is set up, data will only be swapped into an external file if the cache is saturated.
• Try to avoid using views for data you’re constantly accessing. If you can afford it, create temporary tables and insert data there. This will eliminate the overhead imposed by the view evaluation.
• Avoid sub-queries since they tend to create temporary tables and insertion of the intermediate results into those tables may be expensive.
• Try to use indices only on static data or data that changes rarely. Building an index on live or temporary data can be expensive performance-wise. Only do so if the time required for the data lookup considerably outweights the time required for building the index.
• Alternative to indices: hashkeys – Instead of using indices on very long strings, you may store the hash values of those strings as keys in the same table. A lookup via hash values may be a whole lot more efficient. This method is also very effective when you can’t afford the creation of an index due to performance reasons. Downside: You have to take care of the hashkeys. (See remarks in the comments below.)
• No useless indices. Create indices only if your queries actually use the indices on the table (check with EXPLAIN). Having useless indices around may pollute otherwise precious database cache space.
• Be cache-friendly. Depending on the memory conditions, creating temporary tables and indices may bash the cache. Reloading data back into the cache is expensive.
• Double-check your queries and profile them. The SQLite optimizer doesn’t perform as well as the optimizers of big DBs (Firebird / Interbase, PostgreSQL, Oracle etc.).
• Check compiler settings. A higher optimization setting in your C-compiler may very well yield a few tens of milliseconds. Make sure to inline functions (-O3 for GCC 2.95.x, -O2 for GCC 3.x.x and higher). Optimize for architecture and CPU. Omit stack frame pointers (-fomit-frame-pointer) if you’re not producing executables with debug symbols. This may free an additional register for the compiler to use.
• Disable unused SQLite features. This helps to reduce binary size and may also affect performance.

Here are some additional docs to consider:

http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning
http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuningWindows
http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations
http://www.sqlite.org/optoverview.html
http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

Development progress

I’ve been optimizing a lot under the hood. Tons of blood, sweat and tears have already run into optimizing the core parts.
Coming from a different background in programming, namely a desktop background, doing embedded development is a whole new experience for me. And let me say this: it’s definitely a refreshing one.
Development for embedded devices can be quite challenging if you have hard memory limitations and performance restrictions CPU-wise. These limitations go even further than the ones I’m used to when doing component or graphics development. And I’m doing quite a lot of that…

Just so you get the idea:
My essential requirement for this project is that the player is able to cope with thousands of files in a playlist.

With that being said, I’ve already rewritten the playlist management four times. :)
The first approach was fast but ate RAM for breakfast. Incremental searching on a playlist was fast but also required additional memory. The second approach was more memory-friendly, but searching was slow. Besides, some Qt widgets make development a real pain – at least in Qt/E 2.3.x. For instance, QListView can pose an incredible hog on performance. I’m currently using several hacks to speed things up. However, I’m still thinking about replacing the whole component or doing some custom coding to improve it…

Anyway, since I couldn’t really get rid of the memory problems, I finally decided to give SQLite a try. SQLite offers very sophisticated caching, which helps getting rid of the RAM problem. I really could use the enhanced features of a SQL database. And let me say this: SQLite is awesome. And it’s as fast as it could be on such a small device – that is, if you know how to use it…

With that being said, different rules in database design apply for embedded systems:
In the third approach I already created a pretty decent database schema. Something I naturally would have done on a desktop system. Keeping the layout clean, using relations where applicable, minimizing data storage requirements.
On a desktop system dereferencing and joining tables is fast. However, not so on my Zaurus: Simple left-joins over three tables would take up to a few hundred milliseconds. In contrast, these queries are almost unmeasurable on my desktop system, meaning they were faster than 10 ms.
Now add a few other equally expensive queries to that and imagine, you’re doing a search on your playlist with 2000 items. Do you want to wait 3 seconds or longer for the result? That’s not what I call interactive.
So, I had a nice profiling, optimizing and testing marathon last weekend. To make a long story short, after analyzing the bottlenecks and also having a lengthy discussion with a DB-guru friend, I ended up simplifying the database schema in a direction I wouldn’t normally take on a desktop system. It’s not totally ugly now, but it’s just not as relational as you might expect a SQL database to be. Also, some data is redundantly held in temporary tables, which isn’t nice either, but helps performance A LOT.
In order to do the profiling I made some changes to the SQLite codebase, which I will post shortly along with some optimization hints. Update: Hints here, patch here.

Screenshots

No release yet, sorry! I have to finalize some features first.
However, here are some new screenshots that show the new overview feature in action. The design of the application is temporary, stay tuned! :)