That’s what I’m using for MeeGo now. Autoconf parameters, theeere we go:

–disable-static –disable-aiglx –disable-config-dbus –disable-config-hal –disable-dbe –disable-dga –disable-dpms –disable-dri –disable-glx –disable-glx-tls –disable-int10-module –disable-ipv6 –disable-screensaver –disable-secure-rpc –disable-tcp-transport –disable-vbe –disable-vgahw –disable-xdm-auth-1 –disable-xinerama –disable-xwin –disable-xaa –disable-xace –disable-xdmcp –disable-xf86vidmode –disable-xfree86-utils –disable-xnest –disable-xvmc –disable-libdrm –enable-config-udev –enable-dri2 –enable-null-root-cursor –enable-record –enable-unit-tests –enable-visibility –enable-xorg –with-sha1=libsha1

PS: stop use kdrive hardware servers (Xfbdev and variants). They are dead!

Last week I’ve been in Brazil at 11th International Free Software Forum (FISL) talking about Linux Graphics for Small Devices*. I tried to cover a bit of everything that I learned in the world I’ve been immersed in some near past - I guess there aren’t many news for freedesktopers though. Anyway, everyone is very welcome to give any kind of feedback and comment on it. Just follow here.

*actually, two nights in Porto Alegre and two nights in Curitiba. Was great to see most of my friends!

Usually faster the number of commits, faster the development process. But development without strict reviewing doesn’t guarantee quality on the code. Unfortunately, rarely you will see people willing or even just being able to review the changes you are proposing. Attract reviewers is hard!

Lemma: The art of writing a good patch series is all about to attract reviewers.

Proof is omitted due to lack of space. Sorry ;)

I’d start to write a post about how to write a nice commit message and patch series, so I could use as a future reference for you.

Previously, the message was for toolkit, now it targets new upcoming developers… okay, if I’d be offensive I could say it targets vendor distributions which care for desktop on Linux :)

I have started hacking on X due the laboratory at my university I was working was running an amazing project to employ computer labs in all high-schools of the state I was living, in Brazil. It was a successful and all 2.100 schools used the multiseat computing model.

We all know since 2006 (?) that the world is turning to use XCB instead Xlib as the interface between X clients and the server. The advantages of using XCB is well know but, even so, it’s being adopted very slowly for some reason - for instance no toolkits yet ported it. If this serves as a motivation, Alan got a really nice measurements porting a simple X app.

Translate your toolkit and application now! :)

So here goes some statistics of the Xorg process running. All the informations were fetch from /proc/pidof Xorg/{smaps, status}. I used also a script found on the Web to parse and organize these informations; Mikhail Gusarov has extended this script to show a very useful output.

Xorg per se

Running just one standalone Xorg -retro. In my system it represents: VmRSS: 5440 kB VmSize: 13620 kB

from those 5440 kB of RSS: 3404 kB (63 %) come from code 1628 kB (30 %) come from malloc/mmap in anonymous memory (heap) 228 kB (4 %) come from other data mapped in memory 180 kB (3 %) come from rodata