Serving community

I’m not dead yet (if I continue using this phrase, when I’ll be dead, someone will have to write on my tombstone “he’s dead, finally”), but I’ve been quite swamped out with my job. It’s quite nice when you work on two months on a thing, without test data, and when you get test data and you get to produce the test suite you found that everything you’ve being doing was based on a wrong assumption… nice, really, not.

Anyway, since I left Gentoo, I’ve decided to change a few other things in my style. Although I did report a few bugs on the bugzilla for a couple of issues I had, most of my work lately has been upstream. Yesterday accounted for a few fixes in xine, three patches for Valgrind (that you can find in my overlay, if you want to look at them), and one for FFmpeg (that will pass unnoticed as usual). As working downstream works nice only if you can actually be helpful to users by taking action immediately, it’s less a priority for me to work on that side, although it’s obviously not entirely gone, so you can see my work on an init.d script for rbot (always in my overlay), that I needed so that ServoFlame doesn’t need to be started by hand – and with the new connection handling code in SVN, it’s actually coping nicely even with network failures – and on an updated xine-ui snapshot that is now in portage, solving the obnoxious bug with the doubleclick to go fullscreen. In all this, I stopped writing down the timetable for stable for the packages though.

Today instead I tried working on the Rust project a bit more, mainly by writing a new page (not yet linked on the site, so I won’t link it here just yet) with some step by step guide on how to set up a developer’s repository for Rust, complete with CIA-on-push and mail-on-push so that the rest of the project (users and other devs) would be able to review the change (this was suggested in a nice video from Google’s TechTalks — you can watch the video with your favourite media player, that I hope will be xine, by downloading it for the PSP/iPod; the mp4 H264/AAC file played nice for me on xine even with the green blobs.. see later on this entry); unfortunately the default update script for git installed in the hooks directory does not mail the actual diffs as far as I can see, and it doesn’t really provide a decent subject, so I’ll have to work on it a bit tomorrow.

I wish to thank David who started working on Rust with me, he’s probably the first person who was ever interested in working in a project of mine 🙂 This is why ost of my projects ended up dead, being the only one working on them, I often felt liek they are of no interest to anyone else.

Anyway, let’s move on a bit on the green blobs I named above. If you ever tried to play an H264 stream with xine, you might have experienced this problem: green rectangles touching hte left border of the video appearing through all the stream. It doesn’t happen on all streams, but it does on some. With Valgrind’s help I was able to find the «leaf cause» of this problem, as it reports an “invalid read of size 4” in a section of the MMX code, and I can report that by disabling MMX code in FFmpeg itself the problem is solved, but why this happens it’s still a mystery to me, someone else should look into the issue… Mike that would be you, possibly 🙂

Anyway, tonight I was finally able to stop worrying about Windows’s crazy behaviour when a symlink is stored in a 7zip file (the extracted file is only a few bytes long, but being named .exe is enough for Windows to try running it… luckily it only produced an Invalid Instruction kind of error, rather than killing the system altogether), so tomorrow a new segment of work will start for me, and that might give me more time between one battery of tests and the other.

One of the things I am considering to relax, is to replace my current setup of xmodmap, xbindkeys and xvkbd by writing a new application that binds mouse buttons press with a keysym press, so that I can finally stop patching evdev with Olivier’s patch to use my LX700 keyboard, and finally close that odissey. With XCB the task actually seems way easier than with Xlib, I probably can write an xbindkeys workalike in very little time, but there is more involved in this as I want to replace three programs and not just one.

Right now I have evdev patched so that some of the “buttons” of the keyboard (the ones that are actually on the keyboard rather than on the mouse) are reported as keys again, then I xmodmap their keycode to a keysym (that is also bound on KDE’s shortcuts) and I can use those; for the forward/next buttons on my mouse, I instead use xbindkeys to bind the mouse press to a call to xvkbd to send the keysym, this work with a fork() call which is far from being lightweight. What I want to do is to use a vanilla evdev, no xmodmap, no xbindkeys and no keysym, but a xmouse2sym background process that reads a simple file containing a series of pairs «button = keysym» (similarly to .xmodmaprc), find if the keysym is already registered, in which case the proper keycode would be used, for the keysym that are not already registered, it would take a free slice of unused cods to allocate the key.

I’ve looked up the XCB methods to do this, and it’s mostly straightforward, and it should also be quite fast to implement with XCB compared to Xlib, but the big problem is that the string form of the keysym cannot be used internally, you need to use the number form, which usually is returned by XStringToKeysym() function, client-side… this function is not present in XCB itself, so I have either to use Xlib to get that function, or I’ll need to write my own function to get this data. Such a function would be nice in xcb-util so I might look into it… maybe I’ll be able to finally learn lexers and parsers ^_^

Okay so it’s now quite late and I should be sleeping.. it’s just that I don’t really feel that nice lately after sleeping, probably an aftermath of leaving Gentoo, or just my life that’s trying to tell me I’m not immortal, and I should employ it better, who knows…