Glider
"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"

Current filter: »Nerd« (Click tag to remove it or click and/or to switch it.)

Powered by Blosxom &Perl onion
(With plugins: logerror, config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, entries_index, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
Changing the gdm3 (login screen) background in Gnome3

Gnome

I upgraded to Gnome3 this week, and after half a day of debugging I got my (quite non-standard) setup working completely again. One of the things that got broken was my custom wallpaper on the gdm3 login screen. This used to be configured in /etc/gdm3/greeter.gconf.defaults, but apparently Gnome3 replaced gconf by this new "gsettings" thingy.

Anyway, to change the desktop background in gdm, add the following lines to /etc/gdm3/greeter.gsettings:

[org.gnome.desktop.background]
picture-uri='file:///etc/gdm3/thinkpad.jpg'

For reference, I also found some other method, which looks a lot more complicated. I suspect it also doesn't work in Debian, which runs gdm as root, not as a separate "gdm" user. Systems that do use such a user might need the more complicated method, I guess (which probably ends up storing the settings somewhere in the homedir of the gdm user...).

Thinkpad X201 mute button breaking speaker output

Thinkpad

Recently, I was having some problems with the internal speakers on my Lenovo Thinkpad X201. Three times now, the internal speakers just stopped producing sound. The headphone jack worked, it's just the speakers which were silent. Nothing helped: fiddling with volume controls, reloading alsa modules, rebooting my laptop, nothing fixed the sound...

When trying to see if the speakers weren't physically broken, I discovered that booting into Windows actually fixed the problem and restored the sound from the speakers. It's of course a bit of a defeat to accept Windows a fix for my problem, but I was busy with other things, so it sufficed for a while.

When migrating my laptop to my new Intel SSD, I broke my Windows installation, so when the problem occured again, I had no choice but to actualy investigate it.

I'll skip right to the conclusion here: I had broken my sound by pressing the mute button on my keyboard... Now, before you think I'm stupid, I had of course checked my volume controls and the device really was unmuted! But it turns out the mute button in Thinkpads combined with Linux is a bit weird...

This is how you would expect a mute button to be implemented: You press the mute button, it sends a keypress to the operating system, which then tells the audio driver to mute.

X201 volume buttons

This is how it works on my Thinkpad: You press the mute button, causing the EC (embedded controller) in the thinkpad to directly mute the speakers. This is not visible from the normal volume controls in the software, since it happens on a very low level (though the thinkpad_acpi kernel module can be used to expose this special mute state through a /proc interface and special audio device).

In addition to muting the speakers, it also sends a MUTE acpi keypress to the operating system. This keypress then causes the audio driver to mute the audio stream (actually, it's pulseaudio that does that).

Now, here's the fun part: If you now unmute the audio stream through the software volume controls, everything looks like it should work, but the hardware is still muted! It never occured to me to press the mute button again, since the volume wasn't muted (or at least didn't look like it).

I originally thought that the mute button handling was even more complex, when I found some register polling code that faked keypresses, but it seems that's only for older Thinkpads (phew!).

In any case, the bottom line is: If you have a Thinkpad whose speakers suddely stop working, try pressing the mute button!

Opening attachments on another machine from within mutt

For a fair amount of years now, I've been using Mutt as my primary email client. It's a very nice text-based email client that is permanently running on my server (named drsnuggles). This allows me to connect to my server from anywhere, connect to the running Screen and always get exactly the same, highly customized, mail interface (some people will say that their webmail interfaces will allow for exactly the same, but in my experience webmail is always clumsy and slow compared to a decent, well-customized text-based client when processing a couple of hundreds of emails per day).

Attachment troubles

So I like my mutt / screen setup. However, there has been one particular issue that didn't work quite as efficient: attachments. Whenever I wanted to open an email attachment, I needed to save the attachment within mutt to some place that was shared through HTTP, make the file world-readable (mutt insists on not making your saved attachments world-readable), browse to some url on the local machine and open the attachment. Not quite efficient at all.

Yesterday evening I was finally fed up with all this stuff and decided to hack up a fix. It took a bit of fiddling to get it right (and I had nearly started to spend the day coding a patch for mutt when the folks in #mutt pointed out an easier, albeit less elegant "solution"), but it works now: I can select an attachment in mutt, press "x" and it gets opened on my laptop. Coolness.

How does it work?

Just in case anyone else is interested in this solution, I'll document how it works. The big picture is as follows: When I press "x", a mutt macro is invoked that copies the attachment to my laptop and opens the attachment there. There's a bunch of different steps involved here, which I'll detail below.

See more ...

Adobe dropped 64 bit Linux support in Flash again

Only recently, Adobe has started to (finally) support 64 bit Linux with its Flash plugin. I could finally watch Youtube movies (and more importantly, do some Flash development work for Brevidius).

However, this month Adobe has announced that it drops support for 64 bit Linux again. Apparently they "are making significant architectural changes to the 64-bit Linux Flash Player and additional security enhancements" and they can't do that while keeping the old architecture around for stable releases, apparently.

This is particularly nasty, because the latest 10.0 version (which still has amd64 support) has a couple of dozens (!) of security vulnerabilities which are fixed in a 10.1 version only (which does not have Linux amd64 support anymore).

So Adobe is effectively encouraging people on amd64 Linux to either not use their product, or use a version with critical security flaws. Right.

Using fcsh as a drop-in replacement for mxmlc

Adobe Flash

I've recently been hacking a bit with Flash (or rather, with Adobe's Flex compiler. This is a freely available commandline compiler, which actually works on Linux as well.

However, out of the box the commandline compiler, mxmlc, is obnoxiously slow. It takes nearly 10 seconds to compile a simple Hello, world! example, and compiling the video player I'm working on takes over 30 seconds. Not quite productive.

This is a documented "flaw" in the mxmlc compiler, caused by the fact that it has to start up a big java program everytime, loading thousands of classes and because it always recompiles the entire source.

The official solution to get faster compile times is to use the Flex Compiler Shell (fcsh), which is included with the Flex SDK. Basically, it's a caching version of the mxmlc compiler, that keeps running in the background and caches compiled files.

fcsh is intended to be used by IDEs. The IDE starts fcsh and then communicates with it through its stdin/stdout. This means fcsh is really a simple thing, without any support for listing on sockets or properly daemonizing.

Using fcsh speeds up the build time from nearly 40 seconds to just a few seconds (depending on how many changes were made). The first compilation run is still slow, of course.

I've been trying to use fcsh with the ant build system, which makes things a bit tricky. Since there is no long-running process (like an IDE) which can keep fcsh running, this needs some way for fcsh to be run in the background, connected to some fifo or network socket so we can start it on the first compilation run and then connect to it in subsequent compilation runs.

A quick google shows that there are already a few fcsh wrappers to do this, some of which intended to work with ant as well. At a quick glance, it seems that the flex-shell-script-daemonizer seems the most useful one. It is created in Java and runs as a daemon (unlike the alternatives I saw, which were Windows-only due to some useless GUI). It has two modes: In server mode it starts fcsh and connects it to a TCP network socket and in client mode it takes a command to run and passes it over the netowrk to the running server.

There is also some stuff to integrate make ant use fcsh for compiling actionscript files. However, this requires changing the build methods and stuff in build.xml, which I don't want to do (I'm trying to minimize my changes to the sources, since I'm modifiying someone else's project).

So, I created a small shell script that can be used as a drop in replacement for mxmlc. It simply takes joins together all its arguments to a single command and passes that to the flex-shell-script-daemonize command. If the fcsh daemon is not yet running, it automatically starts it (and does some half-baked daemonization, since neither fcsh nor flex-shell-script-daemonizer does that...)

While writing the script, I also found out that the fcsh "shell", doesn't have any way to quote spaces in arguments in the command (at least, I couldn't find any and there was no documentation about it). This means that, AFAICS, there is no way to support spaces in paths. How braindead is that... I guess FlexBuilder, the official IDE from Adobe doesn't use fcsh after all and instead just includes the compiler classes directly...

Of course, just as I finished the script, I encountered flexcompile, which basically does the same thing (and includes the network features of flex-shell-script-daemonizer as well). It's written in python. However, it does require the path to flex and the mxmlc part of the path to be passed in as arguments, so it's not a 100% drop-in replacement (which I needed due to the way the build system I was using was defined). Perhaps it might be useful to you.

Anyway, here's my script. Point the JAR variable at the jar generated by flex-shell-script-daemonizer and FCSH to the fcsh binary included with the Flex SDK.

#!/bin/sh

# (Another) wrapper around FlexShellScript.jar to provide a mxmlc-like
# interface (so we can just replace the call to mxmlc with this script).

# For this, we'll have to call FlexShellScript.jar with the "client"
# argument, and then the entire mxmlc command as a single argument
# (whereas we will be called with a bunch of separate arguments)

JAR=/home/matthijs/docs/src/upstream/fcsh-daemonizer/FlexShellScript.jar
FCSH=/usr/local/flex/bin/fcsh
PORT=53000

# Check if fcsh is running
if ! nc -z localhost "$PORT"; then
    echo "fcsh not running, trying to start..."
    # fcsh not running yet? Start it (and do some poor-man's
    # daemonizing, since the jar doesn't do that..)
    java -jar "$JAR" server "$FCSH" "$PORT" > /dev/null 2> /dev/null <
/dev/null &

    # Wait for the server to have started
    while ! nc -z localhost "$PORT"; do
    echo "Waiting for fcsh to start..."
    sleep 1
    done
fi

# Run the client. Note that this does no quoting of parameters, since I
# can't find any documentation that fcsh actually supports that. Seems
# like spaces in path just won't work...
# We use $* instead of $@ for building the command, since that will
# expand to a single word, instead of multiple words.
java -jar "$JAR" client "mxmlc $*" "$PORT"
URL-encoding in Flash: Be careful of plus signs!

Adobe Flash PHP

Recently I have been doing some Flash debugging for my work at Brevidius. In a video player we have been developing (based on work done by Jeroen Wijering) we needed to escape some url parameter, since our flash code could not be certain what would be in the value (and characters like & and = could cause problems). The obvious way to do this is of course the escape function in ActionScript. This function promises to escape all "non-alphanumeric characters", which would solve all our problems.

However, afters implementing this, we find that there are spaces magically appearing in our GET parameters. Upon investigation, it turns out that there are plus signs in our actual values (it's Base64 encoded data, which uses the plus sign). However, the escape function apparently thinks a plus sign is alphanumeric, since it does not escape it (note that the flash 10 documentation documents this fact). Which shouldn't be a problem, since a plus sign isn't special in an url according to RFC1738:

Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.

(Note that RFC3986 does recommend escaping plus signs, since they might be used to separate variables, but that's not the case here).

However, the urls we generate in flash point to PHP scripts and thus pass their variables to PHP. Unfortunately, PHP does not adhere to the RFC's strictly: It interprets plus signs in an url as spaces. Historically, spaces in an url were replaced by plus signs, while spaces should really be encoded as %20 nowadays. There is of course a simple way get Flash (or any other url-generating piece of code) work properly with PHP: Simply encode plus signs in your data as %2B (which is the "official" way). This makes sure you get a real plus in your $_GET array in PHP, and the problem is resolved.

After some searching, and asking around in ##swf on Freenode, I found the encodeURIComponent function, which is similar to escape, but does encode the plus sign. If we use this function, we can again send data with spaces to PHP! And since encoding more than needed is still fine according to the specs, there are no downsides (except that you need Flash >= 9.0).

So, if you're developing in Flash, please stop using escape, and use encodeURIComponent instead.

XDebug javascript snippet for Firefox (and whitespace fix for vim)

I've been toying around with XDebug this week, which allows me to debug php scripts interactively, by setting breakpoints, watching variables and stepping through the code from within Vim (it's a bit rudimentary, but it works). Marijn tipped me about this and I used his useful howto to set it up.

I'm still battling with python and vim to properly support spaces in filenames, I'll post my solution once I found it (I found it, see below). If you want to toy around with XDebug and Vim, you should definately check out this comment about other (non-space) special characters in urls.

Anyway, I started out this post because I made something pretty and wanted to share it. To use the XDebug extension, you need to pass XDEBUG_SESSION_START=id with the request you want to debug. Because I kept forgetting how this parameter was called exactly and because it is annoying to insert it at the end of some long url, especially when the url also uses # to jump to an anchor, I created a nifty bookmark.

Screenshot

var loc, tmp, anchor, url, args;

tmp = document.location.href.split('#');
if(tmp[1]) 
    anchor = "#" + tmp[1];
else 
    anchor = "";
tmp = tmp[0].split('?');
url = tmp[0];
if (tmp[1]) 
    args = "?" + tmp[1] + "&";
else 
    args = "?";
args += "XDEBUG_SESSION_START=id";
document.location.href = url + args + anchor;

This script splits the current location in url, args and anchors, adds the argument, and puts the location back together. Simple as that. You can create a bookmark from this script by right-clicking this link and pick "Bookmark this link..." or whatever your browser calls it. You can also use the link to test the script (watch the address bar).

I've tested this script on Firefox, but it should work on most browsers, for it doesn't do anything really complex.

Update: I've managed to convince the XDebug vim script to handle spaces in filenames properly. I've put up a fixed version and a diff with the fixes. Both include the above mentioned special characters fix.

And the saga continues....

As you might have read in my previous post, I have been vastly unimpressed by MSI's warranty department. Or actually, I have been actually been quite impressed by the amount of incompetence that they have managed to concentrate in that department. But, I digress.

A few weeks back, MSI managed to take weeks to not replace my hard drive. I have been complaining about this, and they offered that I sent them the faulty drive (again) so they could replace it. Yet they could not send me a new drive, before they had received the old drive, since "the system would not allow it". They would not, however, require me to send back my entire notebook again, as a courtesy. It's not like I could use it for anything but decoration without a hard drive (it does not support booting from an USB stick, I discovered after installing debian om my stick), but well.

See more ...

So much for MSI support....

I was going to write a nice piece about MSI support here, as soon as I got my notebook back from MSI. About their nice service (pick up and return with UPS!) even though they are a little slow-ish. About their nice battery warranty (minimal 80% of capacity after a year) and their flexibility in applying that warranty (I was a few days too late, technically) But, I've decided not too.

There are several reasons for this. First of all, my notebook HD broke in the first place. Not a nice thing to do, though I should probably blame WD for not making HD's that can sustain repeated writes resulting from hibernation in the same area of the disk.

It could also be because it took them nearly a week to respond to my service request when I complained about a bad HD (with complete smart status and error logs to back up my case). All I got back was a UPS label, but I reckoned it took them a while to fully read through my case and decide what to do with it. As it turns out now, it seems they didn't even read it and just needed 6 days to send me a UPS label.

See more ...

Linux-2.6.19 FTW!

For the last couple of months, I've been having issues with my Linux hibernation. I had it working from the start, but for some unknown reason, it ceased working as of kernel 2.6.16. For the past months I have been unable to upgrade my kernel, since I did not have enough time to find and solve the problem.

This was nasty, since the newer versions of my wireless network drivers require > 2.6.16, the wacom tablet drivers have a few new features in 2.6.18 and there should be support for my (built-in) SD card reader since 2.6.18 (really generic support for SD host controllers ). None of which I could use, since upgrading would break my hibernation (and I really can't use my notebook without hibernation).

Last week, 2.6.19 was released. Even though I couldn't find anything in the changelog that would fix my hibernation (I'm nearly done reading it), I decided to give it a try anyway. Well, waddayaknow? It worked right away! I have to admit that suspend and resume is slower than it used to be (5s vs 2s for the actual writing/reading to/from disk), but it at least it works.

Also, the generic SD card reader support worked straight away, despite a warning in my kernel log:

sdhci:slot0: Unknown controller version (16). You may experience problems.

So far, I've not experienced any problems, though I haven't really done any real testing yet...

Another weird side effect of this new kernel is the occurrence of APIC errors:

APIC error on CPU0: 40(40)

So far, there have been no ill effects apart from this message, so I'll just ignore it for now. It is typical however, that I get this error roughly every 1000 seconds. Oh well...

As an added bonus, 2.6.19 introduces "MSI laptop extras". This allows me to query the state of my WLAN/Bluetooth button and allows my to set the display brightness programmatically. Real nifty, though I'm not sure how to use it just yet...

Update: It seems that suspend code now no longer swaps out applications before writing the memory to disk. This means the actual writing takes longer but starts earlier. In particular it also means that after desuspending, I don't have to wait until firefox gets unswapped first.

Showing 1 - 10 of 35 posts
Copyright by Matthijs Kooijman