Random ramblings of Tommi Komulainen

Just when we were leaving DAM3 Jim Gettys mentioned some fancy code generating technology. Apparently it can be used, among other things, to write a javascript VM that is an order of magnitude faster than current ones. He also mentioned having just finished a meeting (with Carl Worth, Alan Kay and others) where they implemented the core parts of cairo using this new thingamagic and got it correct in a few hours. It is conceivable that this thing could be used for selected parts of cairo and render extension and get big performance benefits. Can’t wait to hear more about this.

Here’s some random notes from the Desktop Architects Meeting-3. Follow the link for summary and presentations.

The format was somewhat different from what I was expecting; I think we spent too much time (too many and too long) on the presentations, at the expense of breakout sessions. Breakouts themselves were great, but in some cases the problems can not be solved with technology (codecs, DRM) or we did not have the right people present to get a concrete action plan (upstream/downstream co-operation.) All in all, it was good, could’ve been better.

The DAM is a good place to meet the people working on different aspects of the Linux desktop and have a glance to the big picture on what’s happening in different areas. Following are some things we discussed during the two days.

ISVs want one stable platform. Never ever remove or change anything, adding is OK. ISVs do not want to keep on porting the software. Once an applications is released it should run (everywhere.) You can rebuild the distribution to migrate from libstdc++.so.5 to libstdc++.so.6 and drop the former without affecting the distribution, but that easily breaks independent applications. Having compatibility libraries is nice in theory, but in practice there is no distribution independent way for getting them installed.

If ISVs agree on some common set of libraries and APIs they’d all be happy about, there might be enough incentive for distributions to keep making that set of libraries available. Have them all installed by default, or get distributions provide a single well known way to get them installed on end user systems.

At least in theory we currently have two totally incompatible Nokia 770’s out there. Some (really few I’d expect) with the 2005 and the rest with the 2006 OS release. This presents a problem to ISVs, what does “runs on Nokia 770″ really mean? And when/if we release new hardware/software combinations, how can we get the message clear to both ISVs and end users about platform compatibility?

Audio on Linux is in a sorry state. On Windows there’s one audio API, on Mac there’s one API, on Linux there’s 6-7 incompatible APIs. It’s relatively futile to talk about video if even audio doesn’t work. And with codecs/DRM the problems are not really technical anyway. Focusing on the needs of application developers is the way to go here.

In Maemo we’re using GStreamer and ESD basically for the same reason, there is no one API that would work for all, or even the most common, cases.

Improving upstream/downstream co-operation.
Currently the technology (read: bugzilla) does not help as much here as it could, there’s much manual work involved; forwarding bugs to upstream, searching through all (other) distribution bugzillas for bugfixes, etc. It would be nice to have an overview of the state of a bug across all distributions. Does any distribution have a proposed fix? Is the bug officially fixed upstream? Where can one find a patch to backport to maintenance release? And so on.

Unfortunately we could only collect use cases as we didn’t have the right people present to concretely plan for getting things done.

Qt applications should look native. Qt4 adds lots of support to make this possible (cleanlooks theme, integrating with glib mainloop, button order.) In Maemo integrating with the input methods is the only thing I can think of that might be tricky to do. Theming and other overall look and feel is simply straightforward work that just needs to be done methinks.

D-Bus 1.0 guarantees API/ABI stability. No more need for “I know this is unstable” defines. No more worries about changing APIs.

Arrived in Portland this morning (Portland time, my local time was 9pm or so) as I’ll be attending the desktop architects meeting next two days. Ought to be interesting.

Turns out the X bug (about motion events) was in fact bug #380281 in gtk. Basically gtk widgets just won’t work correctly if you use gtk_widget_set_extension_events() on them. Arguably that could be considered acceptable for stock widgets and gtk_widget_set_extension_events() intended only for custom widgets.

Unfortunately we need extension events to work on stock widgets so that we can do different things on thumb press and stylus press. I’ve fixed most relevant issues to our gtk+ but it would be nice to have things fixed upstream. Maintaining a fork is not so much fun.

Got this bug which lead me into looking at some code in the X server. If you use gtk_widget_set_extension_events(w, GDK_EXTENSION_EVENTS_ALL); on a GtkEntry or GtkTextView motion notify events stop working. This effectively prevents selecting text.

Button press is always generated at 0,0 (root window coordinates) and the next motion notify is at the “right” position so it looks like a really quick drag and I think here gtk is getting confused. After that you get one more motion notify and then everything stops. Dragging the pointer outside the widget and back in again emits exactly one motion notify event for each time the pointer enters the widget again.

Who’s eating the motion notify events? Ideas?

Anyway.. When I first started replicating the problem I fired up the test program in Xephyr and *BOOM* Xephyr crashed. Long story short I ended up looking at the following pieces of code:

--- fb/fbpict.c:
void fbCompositeSolidMask_nx8x8888 (FbComposeData *params)

--- fb/fbmmx.c:
void fbCompositeSolidMask_nx8x8888mmx (CARD8      op,
                                       PicturePtr pSrc,
                                       PicturePtr pMask,
                                       PicturePtr pDst,
                                       INT16      xSrc,
                                       INT16      ySrc,
                                       INT16      xMask,
                                       INT16      yMask,
                                       INT16      xDst,
                                       INT16      yDst,
                                       CARD16     width,
                                       CARD16     height)

--- fb/fbpict.c:
if (fbHaveMMX())
    func = fbCompositeSolidMask_nx8x8888mmx;
else
    func = fbCompositeSolidMask_nx8x8888;

[and then later on]
(*func) (&params);

I have a pretty good idea what/who happened but to protect the guilty let’s not name any names.

Disabling MMX there let me move on to figure out the actual problem. After fixing a potential issue in gtk (no help there) I found myself staring at more X server code:

--- hw/kdrive/src/kinput.c:
if (some test) {
    [nested if doing conditional coordinate transformation]
}
else {
    [exactly the same code as in previous branch]
}

…and…

--- include/inputstr.h:

#define POINTER_RELATIVE (1 

I’ve no idea whether that’s related, but if the bug is in X server (the same testcase works with desktop X) and the rest of the code is equally (un)obvious it’s going to be fun to track down.

You can’t make this stuff up… Nice example why you should start doing code reviews earlier rather than later, while you still have more options than just sucking it up and throwing away the crapcode.

The S stands for Simple

You might even begin to entertain the sneaking suspicion that half of code review work could be done by a trained chimpanzee, a 10-line script, or someone from marketing.

– Valerie Henson in LWN.net

Funny. Sometimes, often while reading The Daily WTF, I get the feeling this is how some code is being reviewed. Except that it’s not half the work, but all of it.

Learn C in two minutes.

I still think no one should be writing applications in C these days. Only on devices with limited resources it makes some kind of sense. Otherwise the overwhelming (un)necessary boilerplate, memory management, chasing pointers and other bookkeeping is just distracting. Wouldn’t you rather concentrate on the application logic?

This must be the best Nokia recruitment ad ever.

Makes me wonder… Should we have a “Jobs” page/RSS feed in maemo.org?