Topic’s name is a funny (and friendly) devotion to GNOME Census. So let’s take a look at some numbers from the time Xorg 1.9 was in development – raw data is here.

Would be unfair to measure only the work that happened e.g. in X server or in the drivers being developed and come up with the statistics about “who developed X”. X and X development community are quite extensive and don’t concern only “graphics” related, i.e., pixel information that appears on your display screen. This is a very common mistake.

—
X does input device event processing, device keys mapping (e.g. keyboard), pixel rasterization, output and input devices hotplug and configuration, devices and user session pairing, (different) 2D/3D graphics implementation, frame-buffer content management, X application and session security, application memory resources testing, analysis and debugging and etc. So it’s far from just pixel showing up on screen.
—

X is a generic graphical system. I prefer to see X as an implementation that doesn’t handle (or should not) system-level resources like memory or frame-buffer content. Other people see a bit differently. Given so, I divided all X development in the following groups, that you’ll see below as bold. Statistics were generated from the time people were working on 1.9 Xorg (02 Apr to 20 Aug):

The proto set of repositories represents the X11 core protocol description together with its extensions. The implementation of X11 and extensions to be used by clients are inside lib and xcb. lib also contains some few libraries to be used within xserver. xserver contains the server implementation of X. So here are the numbers for X implementation (xserver, proto, lib and xcb repositories):

Processed 874 csets from 74 developers
59 employers found
A total of 291730 lines added, 155222 removed (delta 136508)

Developers with the most changesets
Alan Coopersmith 134 (15.3%)
Jamey Sharp 106 (12.1%)
Gaetan Nadon 84 (9.6%)
Keith Packard 66 (7.6%)
Tiago Vignatti 55 (6.3%)
Peter Hutterer 54 (6.2%)
Mikhail Gusarov 41 (4.7%)
Jeremy Huddleston 38 (4.3%)
Matt Dew 21 (2.4%)
Fernando Carrijo 19 (2.2%)

Developers with the most changed lines
Matt Dew 172273 (53.2%)
Alan Coopersmith 75739 (23.4%)
Gaetan Nadon 13199 (4.1%)
Mikhail Gusarov 8979 (2.8%)
Keith Packard 6438 (2.0%)
Jeremy Huddleston 5750 (1.8%)
Jamey Sharp 5535 (1.7%)
Tiago Vignatti 5227 (1.6%)
Marko Myllynen 5154 (1.6%)
Yaakov Selkowitz 3614 (1.1%)

Developers with the most lines removed
Marko Myllynen 4729 (3.0%)
Tiago Vignatti 3922 (2.5%)
Mikhail Gusarov 3670 (2.4%)
Yaakov Selkowitz 3523 (2.3%)
Josh Triplett 3141 (2.0%)
Adam Jackson 2521 (1.6%)
Jamey Sharp 2036 (1.3%)
Daniel Stone 312 (0.2%)
Fernando Carrijo 221 (0.1%)
Pierre-Loup A. Griffais 91 (0.1%)

Developers with the most signoffs (total 1007)
Keith Packard 184 (18.3%)
Alan Coopersmith 155 (15.4%)
Gaetan Nadon 105 (10.4%)
Jamey Sharp 103 (10.2%)
Peter Hutterer 88 (8.7%)
Tiago Vignatti 56 (5.6%)
Mikhail Gusarov 42 (4.2%)
Jeremy Huddleston 39 (3.9%)
Fernando Carrijo 19 (1.9%)
Adam Jackson 18 (1.8%)

Developers with the most reviews (total 530)
Keith Packard 74 (14.0%)
Peter Hutterer 63 (11.9%)
Jamey Sharp 62 (11.7%)
Alan Coopersmith 46 (8.7%)
Adam Jackson 44 (8.3%)
Julien Cristau 34 (6.4%)
Dan Nicholson 30 (5.7%)
Daniel Stone 23 (4.3%)
Alex Deucher 21 (4.0%)
Tiago Vignatti 18 (3.4%)

Developers with the most test credits (total 42)
Gaetan Nadon 11 (26.2%)
Tiago Vignatti 8 (19.0%)
Jeremy Huddleston 2 (4.8%)
Colin Harrison 2 (4.8%)
Richard Barnette 2 (4.8%)
Eric Anholt 2 (4.8%)
Keith Packard 1 (2.4%)
Peter Hutterer 1 (2.4%)
Dan Nicholson 1 (2.4%)
Dave Airlie 1 (2.4%)

Developers who gave the most tested-by credits (total 42)
Jamey Sharp 11 (26.2%)
Alan Coopersmith 9 (21.4%)
Keith Packard 8 (19.0%)
Tiago Vignatti 2 (4.8%)
Yaakov Selkowitz 2 (4.8%)
Kristian Høgsberg 2 (4.8%)
Jon TURNEY 2 (4.8%)
Peter Hutterer 1 (2.4%)
Mikhail Gusarov 1 (2.4%)
Pierre-Loup A. Griffais 1 (2.4%)

Developers with the most report credits (total 13)
Richard Barnette 2 (15.4%)
Jamey Sharp 1 (7.7%)
Dave Airlie 1 (7.7%)
Robert Hooker 1 (7.7%)
Fabio Pedretti 1 (7.7%)
Julien Cristau 1 (7.7%)
Matt Turner 1 (7.7%)
Kalle Olavi Niemitalo 1 (7.7%)
Chris Ball 1 (7.7%)
邓逸昕 1 (7.7%)

Developers who gave the most report credits (total 13)
Julien Cristau 3 (23.1%)
Tiago Vignatti 2 (15.4%)
Peter Hutterer 2 (15.4%)
Jamey Sharp 1 (7.7%)
Dave Airlie 1 (7.7%)
Alan Coopersmith 1 (7.7%)
Chris Wilson 1 (7.7%)
Michel Dänzer 1 (7.7%)
Pauli Nieminen 1 (7.7%)

Top changeset contributors by employer
Oracle 135 (15.4%)
jamey@minilop.net 106 (12.1%)
Intel 89 (10.2%)
Red Hat 87 (10.0%)
memsize@videotron.ca 84 (9.6%)
Nokia 75 (8.6%)
dottedmag@dottedmag.net 41 (4.7%)
Apple 38 (4.3%)
matt@osource.org 21 (2.4%)
fcarrijo@yahoo.com.br 19 (2.2%)

Top lines changed by employer
matt@osource.org 172273 (53.2%)
Oracle 77967 (24.1%)
memsize@videotron.ca 15840 (4.9%)
Red Hat 9684 (3.0%)
dottedmag@dottedmag.net 9029 (2.8%)
Intel 7898 (2.4%)
Apple 6162 (1.9%)
jamey@minilop.net 5986 (1.8%)
Nokia 5548 (1.7%)
yselkowitz@users.sourceforge.net 3652 (1.1%)

Employers with the most signoffs (total 1007)
Intel 207 (20.6%)
Oracle 155 (15.4%)
Red Hat 119 (11.8%)
memsize@videotron.ca 105 (10.4%)
jamey@minilop.net 103 (10.2%)
Nokia 78 (7.7%)
dottedmag@dottedmag.net 42 (4.2%)
Apple 39 (3.9%)
fcarrijo@yahoo.com.br 19 (1.9%)
yselkowitz@users.sourceforge.net 17 (1.7%)

X drivers, although decreasing in functionality with the time, they still touching kernel and system-level tasks. And that’s why I prefer see those separated from the rest of X implementation. The numbers of development of X input drivers and input event processing tools (xf86-input-*, xkbcomp, xkeyboard-config repositories):

Processed 285 csets from 28 developers
24 employers found
A total of 20679 lines added, 17716 removed (delta 2963)

Developers with the most changesets
Gaetan Nadon 115 (40.4%)
Peter Hutterer 62 (21.8%)
Sergey V. Udaltsov 45 (15.8%)
Chris Bagwell 7 (2.5%)
Daniel Stone 7 (2.5%)
Stephan Hilb 5 (1.8%)
Simon Thum 4 (1.4%)
Adam Jackson 3 (1.1%)
Julien Cristau 3 (1.1%)
Oliver McFadden 3 (1.1%)

Developers with the most changed lines
Sergey V. Udaltsov 17613 (74.3%)
Gaetan Nadon 3096 (13.1%)
Peter Hutterer 1024 (4.3%)
Stephan Hilb 479 (2.0%)
Daniel Knittl-Frank 272 (1.1%)
Simon Thum 189 (0.8%)
Daniel Stone 152 (0.6%)
Chris Bagwell 81 (0.3%)
Michel Dänzer 66 (0.3%)
Patrick Curran 46 (0.2%)

Developers with the most lines removed
Gaetan Nadon 2244 (12.7%)
Peter Hutterer 206 (1.2%)
Fernando Carrijo 10 (0.1%)
Alan Coopersmith 7 (0.0%)
Julien Cristau 2 (0.0%)
Paulo Ricardo Zanoni 1 (0.0%)

Developers with the most signoffs (total 238)
Gaetan Nadon 115 (48.3%)
Peter Hutterer 79 (33.2%)
Daniel Stone 9 (3.8%)
Chris Bagwell 7 (2.9%)
Alan Coopersmith 6 (2.5%)
Fernando Carrijo 3 (1.3%)
Oliver McFadden 3 (1.3%)
Bartosz Brachaczek 2 (0.8%)
Adam Jackson 2 (0.8%)
Ævar Arnfjörð Bjarmason 2 (0.8%)

Developers with the most reviews (total 52)
Rémi Cardona 14 (26.9%)
Fernando Carrijo 9 (17.3%)
Jamey Sharp 9 (17.3%)
Peter Hutterer 8 (15.4%)
Alan Coopersmith 4 (7.7%)
Dan Nicholson 3 (5.8%)
Gaetan Nadon 1 (1.9%)
Simon Thum 1 (1.9%)
Julien Cristau 1 (1.9%)
Magnus Kessler 1 (1.9%)

Developers with the most test credits (total 5)
Peter Hutterer 2 (40.0%)
Bartek Iwaniec 2 (40.0%)
Magnus Kessler 1 (20.0%)

Developers who gave the most tested-by credits (total 5)
Bartosz Brachaczek 2 (40.0%)
Peter Hutterer 1 (20.0%)
Chris Bagwell 1 (20.0%)
Patrick Curran 1 (20.0%)

Developers with the most report credits (total 3)
Peter Hutterer 1 (33.3%)
Julien Cristau 1 (33.3%)
Gabor Z. Papp 1 (33.3%)

Developers who gave the most report credits (total 3)
Gaetan Nadon 2 (66.7%)
Gabor Z. Papp 1 (33.3%)

Top changeset contributors by employer
memsize@videotron.ca 115 (40.4%)
Red Hat 65 (22.8%)
svu@gnome.org 45 (15.8%)
daniel@fooishbar.org 7 (2.5%)
chris@cnpbagwell.com 7 (2.5%)
Oracle 5 (1.8%)
stephan@ecshi.net 5 (1.8%)
simon.thum@gmx.de 4 (1.4%)
VMWare 4 (1.4%)
Nokia 3 (1.1%)

Top lines changed by employer
svu@gnome.org 17683 (74.6%)
memsize@videotron.ca 3304 (13.9%)
Red Hat 1273 (5.4%)
stephan@ecshi.net 479 (2.0%)
knittl89+git@googlemail.com 272 (1.1%)
simon.thum@gmx.de 189 (0.8%)
daniel@fooishbar.org 181 (0.8%)
chris@cnpbagwell.com 81 (0.3%)
VMWare 67 (0.3%)
pjcurran@wisc.edu 46 (0.2%)

Employers with the most signoffs (total 238)
memsize@videotron.ca 115 (48.3%)
Red Hat 81 (34.0%)
daniel@fooishbar.org 9 (3.8%)
chris@cnpbagwell.com 7 (2.9%)
Oracle 6 (2.5%)
Nokia 3 (1.3%)
fcarrijo@yahoo.com.br 3 (1.3%)
simon.thum@gmx.de 2 (0.8%)
avarab@gmail.com 2 (0.8%)
b.brachaczek@gmail.com 2 (0.8%)

for userspace video drivers (libdrm, mesa and all xf86-video-*):

Processed 5608 csets from 107 developers
84 employers found
A total of 528511 lines added, 1345893 removed (delta -817382)

Developers with the most changesets
Brian Paul 599 (10.7%)
Eric Anholt 597 (10.6%)
Gaetan Nadon 431 (7.7%)
Vinson Lee 426 (7.6%)
Marek Olšák 415 (7.4%)
José Fonseca 357 (6.4%)
Kenneth Graunke 326 (5.8%)
Ian Romanick 321 (5.7%)
Carl Worth 233 (4.2%)
Chris Wilson 208 (3.7%)

Developers with the most changed lines
Eric Anholt 957175 (56.3%)
Jeremy Huddleston 146459 (8.6%)
Kenneth Graunke 58744 (3.5%)
Jakob Bornecrantz 46941 (2.8%)
xgi0007 37147 (2.2%)
Brian Paul 36067 (2.1%)
Carl Worth 25201 (1.5%)
Jerome Glisse 22808 (1.3%)
Kristian Høgsberg 20469 (1.2%)
José Fonseca 18998 (1.1%)

Developers with the most lines removed
Eric Anholt 930476 (69.1%)
Jakob Bornecrantz 37952 (2.8%)
Kristian Høgsberg 6935 (0.5%)
Keith Whitwell 3829 (0.3%)
Gaetan Nadon 3113 (0.2%)
Daniel Vetter 956 (0.1%)
Chia-I Wu 451 (0.0%)
George Sapountzis 269 (0.0%)
Owain Ainsworth 58 (0.0%)
Joakim Sindholt 26 (0.0%)

Developers with the most signoffs (total 926)
Gaetan Nadon 363 (39.2%)
Chris Wilson 186 (20.1%)
Jerome Glisse 50 (5.4%)
Dave Airlie 42 (4.5%)
Daniel Vetter 37 (4.0%)
Brian Paul 27 (2.9%)
Alex Deucher 22 (2.4%)
Jeremy Huddleston 18 (1.9%)
Adam Jackson 16 (1.7%)
José Fonseca 14 (1.5%)

Developers with the most reviews (total 24)
Alan Coopersmith 6 (25.0%)
Rémi Cardona 4 (16.7%)
Ian Romanick 2 (8.3%)
Eric Anholt 2 (8.3%)
Corbin Simpson 2 (8.3%)
George Sapountzis 2 (8.3%)
Gaetan Nadon 1 (4.2%)
Chris Wilson 1 (4.2%)
Adam Jackson 1 (4.2%)
José Fonseca 1 (4.2%)

Developers with the most test credits (total 11)
Nick Bowler 2 (18.2%)
Calvin Walton 2 (18.2%)
Aaron Plattner 1 (9.1%)
Marek Olšák 1 (9.1%)
Tom Fogal 1 (9.1%)
Brian Rogers 1 (9.1%)
Arkadiusz Miśkiewicz 1 (9.1%)
Krzysztof Halasa 1 (9.1%)
Sven Arvidsson 1 (9.1%)

Developers who gave the most tested-by credits (total 11)
Daniel Vetter 5 (45.5%)
Chris Wilson 2 (18.2%)
Dan Nicholson 1 (9.1%)
Marcin Slusarz 1 (9.1%)
Francisco Jerez 1 (9.1%)
Tom Stellard 1 (9.1%)

Developers with the most report credits (total 17)
Aaron Plattner 1 (5.9%)
Brian Rogers 1 (5.9%)
Arkadiusz Miśkiewicz 1 (5.9%)
Julien Cristau 1 (5.9%)
Kenneth Graunke 1 (5.9%)
Thomas Bächler 1 (5.9%)
Niels Ole Salscheider 1 (5.9%)
Roy Spliet 1 (5.9%)
Gianluca Anzolin 1 (5.9%)
Sergey Samokhin 1 (5.9%)

Developers who gave the most report credits (total 17)
Chris Wilson 11 (64.7%)
Marek Olšák 2 (11.8%)
Julien Cristau 1 (5.9%)
Ian Romanick 1 (5.9%)
Gaetan Nadon 1 (5.9%)
Maarten Maathuis 1 (5.9%)

Top changeset contributors by employer
VMWare 1870 (33.3%)
Intel 1552 (27.7%)
memsize@videotron.ca 431 (7.7%)
maraeo@gmail.com 415 (7.4%)
kenneth@whitecape.org 326 (5.8%)
LunarG 195 (3.5%)
Red Hat 183 (3.3%)
luca@luca-barbieri.com 127 (2.3%)
mostawesomedude@gmail.com 72 (1.3%)
AMD 64 (1.1%)

Top lines changed by employer
Intel 1057613 (62.3%)
Apple 238512 (14.0%)
VMWare 173210 (10.2%)
kenneth@whitecape.org 67387 (4.0%)
Red Hat 47856 (2.8%)
xgi0007@linux.site 37148 (2.2%)
LunarG 29790 (1.8%)
maraeo@gmail.com 15014 (0.9%)
memsize@videotron.ca 9531 (0.6%)
luca@luca-barbieri.com 6345 (0.4%)

Employers with the most signoffs (total 926)
memsize@videotron.ca 363 (39.2%)
Intel 210 (22.7%)
Red Hat 110 (11.9%)
VMWare 58 (6.3%)
daniel.vetter@ffwll.ch 36 (3.9%)
AMD 22 (2.4%)
Apple 18 (1.9%)
Oracle 12 (1.3%)
maraeo@gmail.com 11 (1.2%)
NVidia 11 (1.2%)

Pixman library (pixman) is a special one because can be used inside X and for other components on the system like cairo. It’s used for pixel manipulation, e.g. fast path to get advantages of CPU features:

Processed 78 csets from 8 developers
8 employers found
A total of 3088 lines added, 1270 removed (delta 1818)

Developers with the most changesets
Søren Sandmann Pedersen 54 (69.2%)
Siarhei Siamashka 9 (11.5%)
M Joonas Pihlaja 6 (7.7%)
Jeff Muizelaar 3 (3.8%)
Andrea Canciani 2 (2.6%)
Brad Smith 1 (1.3%)
Marek Vasut 1 (1.3%)
Siddharth Agarwal 1 (1.3%)

Developers with the most changed lines
Søren Sandmann Pedersen 2207 (64.7%)
Siarhei Siamashka 462 (13.6%)
M Joonas Pihlaja 185 (5.4%)
Andrea Canciani 119 (3.5%)
Marek Vasut 69 (2.0%)
Brad Smith 24 (0.7%)
Jeff Muizelaar 20 (0.6%)
Siddharth Agarwal 2 (0.1%)

Developers with the most lines removed

Developers with the most signoffs (total 5)
Egor Starkov 1 (20.0%)
Rami Ylimaki 1 (20.0%)
Jeff Muizelaar 1 (20.0%)
Marek Vasut 1 (20.0%)
Siarhei Siamashka 1 (20.0%)

Developers with the most reviews (total 0)

Developers with the most test credits (total 0)

Developers who gave the most tested-by credits (total 0)

Developers with the most report credits (total 0)

Developers who gave the most report credits (total 0)

Top changeset contributors by employer
Red Hat 54 (69.2%)
Nokia 9 (11.5%)
jpihlaja@cc.helsinki.fi 6 (7.7%)
jmuizelaar@mozilla.com 3 (3.8%)
ranma42@gmail.com 2 (2.6%)
brad@comstyle.com 1 (1.3%)
sid.bugzilla@gmail.com 1 (1.3%)
marek.vasut@gmail.com 1 (1.3%)

Top lines changed by employer
Red Hat 2320 (68.1%)
Nokia 666 (19.5%)
jpihlaja@cc.helsinki.fi 185 (5.4%)
ranma42@gmail.com 123 (3.6%)
marek.vasut@gmail.com 69 (2.0%)
brad@comstyle.com 24 (0.7%)
jmuizelaar@mozilla.com 20 (0.6%)
sid.bugzilla@gmail.com 2 (0.1%)

Employers with the most signoffs (total 5)
Nokia 3 (60.0%)
marek.vasut@gmail.com 1 (20.0%)
jmuizelaar@mozilla.com 1 (20.0%)

A very important work for X11 comformance testing is XTS, that was broken for while and now is working again:

Processed 41 csets from 4 developers
4 employers found
A total of 2244 lines added, 4078 removed (delta -1834)

Developers with the most changesets
Peter Hutterer 17 (41.5%)
Aaron Plattner 12 (29.3%)
Dan Nicholson 9 (22.0%)
Jon TURNEY 2 (4.9%)

Developers with the most changed lines
Aaron Plattner 3854 (74.1%)
Peter Hutterer 245 (4.7%)
Dan Nicholson 141 (2.7%)
Jon TURNEY 5 (0.1%)

Developers with the most lines removed
Aaron Plattner 2000 (49.0%)
Dan Nicholson 1 (0.0%)

Developers with the most signoffs (total 42)
Peter Hutterer 19 (45.2%)
Aaron Plattner 12 (28.6%)
Dan Nicholson 9 (21.4%)
Jon TURNEY 2 (4.8%)

Developers with the most reviews (total 10)
Dan Nicholson 7 (70.0%)
Peter Hutterer 3 (30.0%)

Developers with the most test credits (total 0)

Developers who gave the most tested-by credits (total 0)

Developers with the most report credits (total 0)

Developers who gave the most report credits (total 0)

Top changeset contributors by employer
Red Hat 17 (41.5%)
NVidia 12 (29.3%)
dbn.lists@gmail.com 9 (22.0%)
jon.turney@dronecode.org.uk 2 (4.9%)

Top lines changed by employer
NVidia 4726 (90.9%)
Red Hat 245 (4.7%)
dbn.lists@gmail.com 225 (4.3%)
jon.turney@dronecode.org.uk 5 (0.1%)

Employers with the most signoffs (total 42)
Red Hat 19 (45.2%)
NVidia 12 (28.6%)
dbn.lists@gmail.com 9 (21.4%)
jon.turney@dronecode.org.uk 2 (4.8%)

X documentation (doc repository):

Processed 22 csets from 6 developers
6 employers found
A total of 315 lines added, 45930 removed (delta -45615)

Developers with the most changesets
Alan Coopersmith 12 (54.5%)
Gaetan Nadon 3 (13.6%)
Thomas Hellstrom 2 (9.1%)
Julien Cristau 2 (9.1%)
Yaakov Selkowitz 2 (9.1%)
Dirk Wallenstein 1 (4.5%)

Developers with the most changed lines
Alan Coopersmith 45843 (99.3%)
Julien Cristau 52 (0.1%)
Gaetan Nadon 36 (0.1%)
Yaakov Selkowitz 23 (0.0%)
Thomas Hellstrom 4 (0.0%)
Dirk Wallenstein 2 (0.0%)

Developers with the most lines removed
Alan Coopersmith 45627 (99.3%)
Gaetan Nadon 18 (0.0%)

Developers with the most signoffs (total 23)
Alan Coopersmith 13 (56.5%)
Gaetan Nadon 3 (13.0%)
Thomas Hellstrom 2 (8.7%)
Julien Cristau 2 (8.7%)
Yaakov Selkowitz 2 (8.7%)
Dirk Wallenstein 1 (4.3%)

Developers with the most reviews (total 4)
Alan Coopersmith 2 (50.0%)
Gaetan Nadon 1 (25.0%)
Dan Nicholson 1 (25.0%)

Developers with the most test credits (total 0)

Developers who gave the most tested-by credits (total 0)

Developers with the most report credits (total 0)

Developers who gave the most report credits (total 0)

Top changeset contributors by employer
Oracle 12 (54.5%)
memsize@videotron.ca 3 (13.6%)
yselkowitz@users.sourceforge.net 2 (9.1%)
jcristau@debian.org 2 (9.1%)
VMWare 2 (9.1%)
halsmit@t-online.de 1 (4.5%)

Top lines changed by employer
Oracle 46053 (99.7%)
jcristau@debian.org 52 (0.1%)
memsize@videotron.ca 36 (0.1%)
yselkowitz@users.sourceforge.net 23 (0.0%)
VMWare 4 (0.0%)
halsmit@t-online.de 2 (0.0%)

Employers with the most signoffs (total 23)
Oracle 13 (56.5%)
memsize@videotron.ca 3 (13.0%)
jcristau@debian.org 2 (8.7%)
yselkowitz@users.sourceforge.net 2 (8.7%)
VMWare 2 (8.7%)
halsmit@t-online.de 1 (4.3%)

Nothing or close to nothing was done in the old font scheme (font repo), bitmap and cursor data. Also, from the total of 85 X traditional applications (apps), only 180 changesets were made and mostly concerning autoconf clean up.

—

Of course lines of code and changeset are far from being a good metric to see actually how the development happened. But still, it does represents something. For sure, there’s also a lot of other inaccurate information that I’m missing from this all. For instance, companies like Collabora does X development but sometimes get the merits for Nokia. Is that fair? I don’t know. And I don’t want to discuss this either :)

PS: Canonical, where are you here? Hint hint hint.

Code changed to protect the guilty, but the approach is the same. Also, this pseudo-code below is actually more streamlined, more sensible and slightly saner than the original.

static char* array[10];
static int other_array[10];

void get_values(int n)
{
        for (i = 0; i  n; i++)
            other_array[i] = get_val(array[i]);
}

int main (void) {
        array[0] = "somestring";
        array[1] = "some other string"
        array[2] = "lalala"
        array[3] = "bananas"

        get_values(4);

        for (i = 0; i  4; i++)
            blah(other_array[i]);

        return 0;
}

If you think of writing code like that, don't. Google for function parameters and try to understand how they work. Some poor sod will eventually have to figure out wtf you're trying to do [1]. I've encountered this bit of code a few weeks back and I am still flabbergasted.

/me hopes this venting makes the anger go away.


[1] as I stated in an early post, any software project is a collaborative project. It has at least two developers [...]. The person you may end up hating for the above may be you.

Dave Airlie made a small commit changing the name of the R300 gallium driver from radeong to r300.

And what does that mean? It basically means that the classic r300 driver and the gallium based one share the same filename. So you can switch between the two drivers by simply replacing the one with the other.

This is really helpful for developers. And it might also be the first sign that the gallium based driver might become the default driver for r300.

Update:

From an anonymous comment:

It also means that you cannot easily package both drivers in rpm packages.

So the preparations for this year GStreamer Conference 2010 is progressing at a healthy pace. Today I put the list of speakers and abstracts online, which combined with the conference timetable should let you plan the event pretty well.

I recommend everyone to look over the list of speakers and abstracts, because I am sure there will be things there everyone will find interesting.

I would also like to remind everyone that we got some great talks happening as part of CE Linux as well like Benjamin Gaignard of ST Ericsson talking about Android and GStreamer, Stefan Kost of Nokia talking about Meego and GStreamer and finally Arun Raghavan from Collabora Multimedia speaking about Pulse Audio. So make sure not to miss the CE Linux days.

You find registration information on the main conference website and be sure to register early as space is limited, so if you wait to long you might not be able to register at all.

It has been a while since my original announcement of systemd. Here's a little status update, on what happened since then. For simplicity's sake I'll just list here what we worked on in a bulleted list, with no particular order and without trying to cover this comprehensively:

• systemd has been accepted as Feature for Fedora 14, and as it looks right now everything worked out nicely and we'll ship F14 with systemd as init system.
• We added a number of additional unit types: .timer for cron-style timer-based activation of services, .swap exposes swap files and partitions the same way we handle mount points, and .path can be used to activate units dependending on the existance/creation of files or fill status of spool directories.
• We hooked systemd up to SELinux: systemd is now capabale of properly labelling directories, sockets and FIFOs it creates according to the SELinux policy for the services we maintain.
• We hooked systemd up to the Linux auditing subsystem: as first init system at all systemd now generates auditing records for all services it starts/stops, including their failure status.
• We hooked systemd up to TCP wrappers, for all socket connections it accepts.
• We hooked systemd up to PAM, so that optionally, when systemd runs a service as a different user it initializes the usual PAM session setup and teardown hooks.
• We hooked systemd up to D-Bus, so that D-Bus passes activation requests to systemd and systemd becomes the central point for all kinds of activation, thus greatly extending the control of the execution environment of bus activated services, and making them accessible through the same utilities as SysV services. Also, this enables us to do race-free parallelized start-up for D-Bus services and their clients, thus speeding up things even further.
• systemd is now able to handle various Debian and OpenSUSE-specific extensions to the classic SysV init script formats natively, on top of the Fedora extensions we already parse.
• The D-Bus coverage of the systemd interface is now complete, allowing both introspection of runtime data and of parsed configuration data. It's fun now to introspect systemd with gdbus or d-feet.
• We added a systemd PAM module, which assigns the processes of each user session to its own cgroup in the systemd cgroup tree. This also enables reliable killing of all processes associated with a session when the user logs out. This also manages a secure per-user /var/run-style directory which is supposed to be used for sockets and similar files that shall be cleaned up when the user logs out.
• There's a new tool systemd-cgls, which plots a pretty process tree based on the systemd cgroup hierarchy. It's really pretty. Try it!
• We now have our own cgroup hierarchy beneath /cgroup/systemd (though is will move to /sys/fs/ before the F14 release).
• We have pretty code that automatically spawns a getty on a serial port when the kernel console is redirected to a serial TTY.
• systemctl got beefed up substantially (it can even draw dependency graphs now, via dot!), and the SysV compatiblity tools were extended to more completely and correctly support what was historically provided by SysV. For example, we'll now warn the user when systemd service files have changed but systemd was not asked to reload its configuration. Also, you can now use systemd's native client tools to reboot or shut-down an Upstart or sysvinit system, to facilitate upgrades.
• We provide a reference implementation for the socket activation and other APIs for nicer interaction with systemd.
• We have a pretty complete set of documentation now, some of it even extending to areas not directly related to systemd itself.
• Quite a number of upstream packages now ship with systemd service files out-of-the-box now, that work across all distributions that have adopted systemd. It is our intention to unify the boot and service management between distributions with systemd, and this shows fruits already. Furthermore a number of upstream packages now ship our patches for socket-based activation.
• Even more options that control the process execution environment or the sockets we create are now supported.
• Earlier today I began my series of blog stories on systemd for administrators.
• We reimplemented almost all boot-up and shutdown scripts of the standard Fedora install in much smaller, simpler and faster C utilities, or in systemd itself. Most of this will not be enabled in F14 however, even though it is shipped with systemd upstream. With this enabled the entire Linux system gains a completely new feeling as the number of shells we spawn approaches zero, and the PID of the first user terminal is way < 500 now, and the early boot-up is fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE and Debian and distilled from this a list of functionality that makes up the early boot process and reimplemented this in C, if possible following the bahaviour of one of the existing implementations from these three distributions. This turned out to be much less effort than anticipated, and we are actually quite excited about this. Look forward to the fruits of this work in F15, when we might be able to present you a shell-less boot at least for standard desktop/laptop systems.
• We spent some time reinvestigating the current syslog logic, and came up with an elegant and simple scheme to provide /dev/log compatible logging right from the time systemd is first initialized right until the time the kernel halts the machine. Through the wonders of socket based activation we first connect the /dev/log socket with a minimal bridge to the kernel log buffer (kmsg) and then, as soon as the real syslog is started up as part of the later bootup phase, we dynamically replace this minimal bridge by the real syslog daemon -- without losing a single log message. Since one of the first things the real syslog daemon does is flushing the kernel log buffer into log files, all logged messages will sooner or later be stored on disk, regardless whether they have been generated during early boot, late boot or system runtime. On top of that if the syslog daemon terminates or is shut down during runtime, the bridge becomes active again and log output is written to kmsg again. The same applies when the system goes down. This provides a simple an robust way how we can ensure that no logs will ever be lost again, and logging is available from the beginning of boot-up to the end of shut-down. Plymouth will most likely adopt a similar scheme for initrd logging, thus ensuring that everything ever logged on the system will properly end up in the log files, whether it comes from the kernel, from the initrd, from early-boot, from runtime or shutdown. And if syslogd is not around, dmesg will provide you with access to the log messages. While this bridge is part of systemd upstream, we'll most likely enable this bridge in Fedora only starting with F15. Also note that embedded systems that have no interest in shipping a full syslogd solution can simply use this syslog bridge during the entire runtime, and thus making the kernel log buffer the centralized log storage, with all the advantages this offers: zero disk IO at runtime, access to serial and netconsole logging, and remote debug access to the kernel log buffer.
• We now install autofs units for many "API" kernel virtual file systems by default, such as binfmt_misc or hugetlbfs. That means that the file system access is readily available, client code no longer has to manually load the respective kernel modules, as they are autoloaded on first access of the file system. This has many advantages: it is not only faster to set up during boot, but also simpler for applications, as they can just assume the functionality is available. On top of that permission problems for the initialization go away, since manual module loading requires root privileges.
• Many smaller fixes and enhancements, all across the board, which if mentioned here would make this blog story another blog novel. Suffice to say, we did a lot of polishing to ready systemd for F14.

All in all, systemd is progressing nicely, and the features we have been working on in the last months are without exception features not existing in any other of the init systems available on Linux and our feature set already was far ahead of what the older init implementations provide. And we have quite a bit planned for the future. So, stay tuned!

Also note that I'll speak about systemd at LinuxKongress 2010 in Nuremberg, Germany. Later this year I'll also be speaking at the Linux Plumbers Conference in Boston, MA. Make sure to drop by if you want to learn about systemd or discuss exiciting new ideas or features with us.

As many of you know, systemd is the new Fedora init system, starting with F14, and it is also on its way to being adopted in a number of other distributions as well (for example, OpenSUSE). For administrators systemd provides a variety of new features and changes and enhances the administrative process substantially. This blog story is the first part of a series of articles I plan to post roughly every week for the next months. In every post I will try to explain one new feature of systemd. Many of these features are small and simple, so these stories should be interesting to a broader audience. However, from time to time we'll dive a little bit deeper into the great new features systemd provides you with.

Verifying Bootup

Traditionally, when booting up a Linux system, you see a lot of little messages passing by on your screen. As we work on speeding up and parallelizing the boot process these messages are becoming visible for a shorter and shorter time only and be less and less readable -- if they are shown at all, given we use graphical boot splash technology like Plymouth these days. Nonetheless the information of the boot screens was and still is very relevant, because it shows you for each service that is being started as part of bootup, wether it managed to start up successfully or failed (with those green or red [ OK ] or [ FAILED ] indicators). To improve the situation for machines that boot up fast and parallelized and to make this information more nicely available during runtime, we added a feature to systemd that tracks and remembers for each service whether it started up successfully, whether it exited with a non-zero exit code, whether it timed out, or whether it terminated abnormally (by segfaulting or similar), both during start-up and runtime. By simply typing systemctl in your shell you can query the state of all services, both systemd native and SysV/LSB services:

[root@lambda] ~# systemctl
UNIT                                          LOAD   ACTIVE       SUB          JOB             DESCRIPTION
dev-hugepages.automount                       loaded active       running                      Huge Pages File System Automount Point
dev-mqueue.automount                          loaded active       running                      POSIX Message Queue File System Automount Point
proc-sys-fs-binfmt_misc.automount             loaded active       waiting                      Arbitrary Executable File Formats File System Automount Point
sys-kernel-debug.automount                    loaded active       waiting                      Debug File System Automount Point
sys-kernel-security.automount                 loaded active       waiting                      Security File System Automount Point
sys-devices-pc...0000:02:00.0-net-eth0.device loaded active       plugged                      82573L Gigabit Ethernet Controller
[...]
sys-devices-virtual-tty-tty9.device           loaded active       plugged                      /sys/devices/virtual/tty/tty9
-.mount                                       loaded active       mounted                      /
boot.mount                                    loaded active       mounted                      /boot
dev-hugepages.mount                           loaded active       mounted                      Huge Pages File System
dev-mqueue.mount                              loaded active       mounted                      POSIX Message Queue File System
home.mount                                    loaded active       mounted                      /home
proc-sys-fs-binfmt_misc.mount                 loaded active       mounted                      Arbitrary Executable File Formats File System
abrtd.service                                 loaded active       running                      ABRT Automated Bug Reporting Tool
accounts-daemon.service                       loaded active       running                      Accounts Service
acpid.service                                 loaded active       running                      ACPI Event Daemon
atd.service                                   loaded active       running                      Execution Queue Daemon
auditd.service                                loaded active       running                      Security Auditing Service
avahi-daemon.service                          loaded active       running                      Avahi mDNS/DNS-SD Stack
bluetooth.service                             loaded active       running                      Bluetooth Manager
console-kit-daemon.service                    loaded active       running                      Console Manager
cpuspeed.service                              loaded active       exited                       LSB: processor frequency scaling support
crond.service                                 loaded active       running                      Command Scheduler
cups.service                                  loaded active       running                      CUPS Printing Service
dbus.service                                  loaded active       running                      D-Bus System Message Bus
getty@tty2.service                            loaded active       running                      Getty on tty2
getty@tty3.service                            loaded active       running                      Getty on tty3
getty@tty4.service                            loaded active       running                      Getty on tty4
getty@tty5.service                            loaded active       running                      Getty on tty5
getty@tty6.service                            loaded active       running                      Getty on tty6
haldaemon.service                             loaded active       running                      Hardware Manager
hdapsd@sda.service                            loaded active       running                      sda shock protection daemon
irqbalance.service                            loaded active       running                      LSB: start and stop irqbalance daemon
iscsi.service                                 loaded active       exited                       LSB: Starts and stops login and scanning of iSCSI devices.
iscsid.service                                loaded active       exited                       LSB: Starts and stops login iSCSI daemon.
livesys-late.service                          loaded active       exited                       LSB: Late init script for live image.
livesys.service                               loaded active       exited                       LSB: Init script for live image.
lvm2-monitor.service                          loaded active       exited                       LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
mdmonitor.service                             loaded active       running                      LSB: Start and stop the MD software RAID monitor
modem-manager.service                         loaded active       running                      Modem Manager
netfs.service                                 loaded active       exited                       LSB: Mount and unmount network filesystems.
NetworkManager.service                        loaded active       running                      Network Manager
ntpd.service                                  loaded maintenance  maintenance                  Network Time Service
polkitd.service                               loaded active       running                      Policy Manager
prefdm.service                                loaded active       running                      Display Manager
rc-local.service                              loaded active       exited                       /etc/rc.local Compatibility
rpcbind.service                               loaded active       running                      RPC Portmapper Service
rsyslog.service                               loaded active       running                      System Logging Service
rtkit-daemon.service                          loaded active       running                      RealtimeKit Scheduling Policy Service
sendmail.service                              loaded active       running                      LSB: start and stop sendmail
sshd@172.31.0.53:22-172.31.0.4:36368.service  loaded active       running                      SSH Per-Connection Server
sysinit.service                               loaded active       running                      System Initialization
systemd-logger.service                        loaded active       running                      systemd Logging Daemon
udev-post.service                             loaded active       exited                       LSB: Moves the generated persistent udev rules to /etc/udev/rules.d
udisks.service                                loaded active       running                      Disk Manager
upowerd.service                               loaded active       running                      Power Manager
wpa_supplicant.service                        loaded active       running                      Wi-Fi Security Service
avahi-daemon.socket                           loaded active       listening                    Avahi mDNS/DNS-SD Stack Activation Socket
cups.socket                                   loaded active       listening                    CUPS Printing Service Sockets
dbus.socket                                   loaded active       running                      dbus.socket
rpcbind.socket                                loaded active       listening                    RPC Portmapper Socket
sshd.socket                                   loaded active       listening                    sshd.socket
systemd-initctl.socket                        loaded active       listening                    systemd /dev/initctl Compatibility Socket
systemd-logger.socket                         loaded active       running                      systemd Logging Socket
systemd-shutdownd.socket                      loaded active       listening                    systemd Delayed Shutdown Socket
dev-disk-by\x1...x1db22a\x1d870f1adf2732.swap loaded active       active                       /dev/disk/by-uuid/fd626ef7-34a4-4958-b22a-870f1adf2732
basic.target                                  loaded active       active                       Basic System
bluetooth.target                              loaded active       active                       Bluetooth
dbus.target                                   loaded active       active                       D-Bus
getty.target                                  loaded active       active                       Login Prompts
graphical.target                              loaded active       active                       Graphical Interface
local-fs.target                               loaded active       active                       Local File Systems
multi-user.target                             loaded active       active                       Multi-User
network.target                                loaded active       active                       Network
remote-fs.target                              loaded active       active                       Remote File Systems
sockets.target                                loaded active       active                       Sockets
swap.target                                   loaded active       active                       Swap
sysinit.target                                loaded active       active                       System Initialization

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

221 units listed. Pass --all to see inactive units, too.
[root@lambda] ~#

(I have shortened the output above a little, and removed a few lines not relevant for this blog post.)

Look at the ACTIVE column, which shows you the high-level state of a service (or in fact of any kind of unit systemd maintains, which can be more than just services, but we'll have a look on this in a later blog posting), whether it is active (i.e. running), inactive (i.e. not running) or in any other state. If you look closely you'll see one item in the list that is marked maintenance and highlighted in red. This informs you about a service that failed to run or otherwise encountered a problem. In this case this is ntpd. Now, let's find out what actually happened to ntpd, with the systemctl status command:

[root@lambda] ~# systemctl status ntpd.service
ntpd.service - Network Time Service
	  Loaded: loaded (/etc/systemd/system/ntpd.service)
	  Active: maintenance
	    Main: 953 (code=exited, status=255)
	  CGroup: name=systemd:/systemd-1/ntpd.service
[root@lambda] ~#

This shows us that NTP terminated during runtime (when it ran as PID 953), and tells us exactly the error condition: the process exited with an exit status of 255.

In a later systemd version, we plan to hook this up to ABRT, as soon as this enhancement request is fixed. Then, if systemctl status shows you information about a service that crashed it will direct you right-away to the appropriate crash dump in ABRT.

Summary: use systemctl and systemctl status as modern, more complete replacements for the traditional boot-up status messages of SysV services. systemctl status not only captures in more detail the error condition but also shows runtime errors in addition to start-up errors.

That's it for this week, make sure to come back next week, for the next posting about systemd for administrators!

This is a totally radeon-unrelated rant:

<rant>

I decided to import some old photos into f-spot today to check for duplicates and organize them to folders corresponding to the date (i.e. yyyy/mm/dd). I assumed that f-spot would read the EXIF-metadata to extract the date (which is what it did before). After the import I was shocked to see that all images where put into 2001/01/01 ... which is totally wrong (the pictures dated 2005)! After looking at the images names (e.g. "01010008.jpg") I found out that the date was extracted from the filename (which is wrong as the camera does not name the images by date but by whatever else). I though: Ok, forget f-spot and let's use shotwell. Sadly shotwell imported the pictures into the same folders. I looked at the exif metadata of the images before and after the f-spot import ... before the date was correct, after the import the date was wrong.

f-spot replaced the exif timestamp by something that it assumed to be the correct timestamp. That's really evil.

Next to that f-spot was not able to import a large library (~10000 pictures) without using ~2.5GB RAM ... which caused my system to be swapping a lot (while still importing). This slowed down importing a single photo to ~5 seconds. Unusable.

I happily dropped f-spot and will never return. Shotwell performs much better (though it's still not as feature-rich). I'm happy to use a .NET/mono application less and I can only recommend that to you, too.

</rant>

Next to that Jerome Glisse and Dave Airlie keep rocking implementing r600g.

TWIMC. The keyboard indicator to be shipped with Ubuntu 10.10 has little to do with the standard gnome keyboard layout indicator. Canonical moved the thing to libappindicator library which was not officially adopted by GNOME.

So, there are some important consequences:

• If you are end-user running ubuntu 10.10 and you have complains about gnome keyboard indicator, you’re not really welcome to bugzilla.gnome.org. First, you should file your problem at Launchpad. If the Ubuntu team finds the problem down the stack, they sure will escalate it.
• A lot of Ubuntu users (including myself) were happy to utilize non-documented but working support for flags in GNOME. In Ubuntu’s implementation that feature is not supported, AFAIK. You’re welcome to complain in Launchpad.
• Single-click layout switching does not work any more (I was told). You’re welcome to complain in Launchpad

As a GNOME developer, I am very concerned about the fact that Ubuntu is starting to create its own version of GNOME. All distrovendors have patches, but Canonical seems to be gone a bit too far, on my taste.

As an end-user, I am quite irritated. I am thinking about switching back to Debian or Fedora (considering the fact that Ubuntu’s support for PowerPC is not great anyway).

I would appreciate if someone provides explanation on how to get original gnome keyboard indicator in Ubuntu 10.10. I did not install that version yet – but people are asking.

As mentioned in my previous post, Bugzilla and translations project setup were still pending.

First, some background: KDB (a kernel debugger shell) and KMS (kernel mode-setting) combine to let you drop into a graphical shell when something debugger-worthy happens on your Linux machine. That thing might be a panic, or a breakpoint, or a hardware trap, or a manual entry into the kdb shell. Inside the shell you can, for example: get a backtrace, inspect dmesg or ps, look at memory contents, and kill tasks.

This is a big improvement over the previous model of "something bad happens to your laptop while it's in X, and the keyboard LEDs start blinking, and you hard-reboot and wonder what happened and wish your laptop had a serial port".

Here's a video of KDB+KMS in action — it's from Jason Wessel at Wind River, who deserves massive kudos for having enough patience to get all of this debugging code merged into mainline Linux to everyone's satisfaction:



Jesse recently wrote about how to give KDB+KMS a spin on Intel graphics chipsets, and now I've written patches that allow radeon and nouveau users to join in too. The method for testing them is similar to Jesse's:

• git clone git://dev.laptop.org/users/cjb/linux-2.6
• cd linux-2.6
• git checkout kgdb-next
• Config the kernel as in Jesse's post, and build/install it.
• Boot with kgdboc=kms,kbd kernel arguments.
• Enter KDB with sysrq-g, or echo g > /proc/sysrq-trigger, and type go to leave KDB.

If you test with radeon or nouveau, please let me know what hardware you tested on, and whether everything worked. Thanks!

does anybody know how to decode those Lenovo ThinkPad model IDs? I am interested in the T410s. For example, there's the model NUK3AGE, and there's NUHFXGE, and there's NUHYXGE. Some web sites claim NUK3AGE has Nvidia graphics, others claim VGA is Intel-only. Some web sites claim it has a touch screen, others say the contrary. The Lenovo web site isn't helpful to figure out the differences between the models and what the feature set of the various models really is. I figured out the GE suffix indicates a german keyboard, but what about the remaining code? Anybody knows how to decypher those IDs or knows a reliable source explaining their feature set?

Love,

Lennart

The latest set of patches for udlfb, the Linux kernel framebuffer driver for DisplayLink chips, has been submitted and looks on track for kernel 2.6.37. This will catch the kernel up to everything on http://git.plugable.com/

Linux is a big and constantly shifting platform. With our USB graphics products (and generally for DisplayLink based products, since we try to make them work for all devices), it’s easy to output a few pixels, but configuring a USB display as an X terminal, or certainly for an extended desktop, is still a process on Linux that requires manual xorg.conf editing and is for very advanced users only. But we try to contribute what we can at Plugable, and that has meant focusing on making the kernel driver that actually talks to the hardware and everything else builds on, as solid as possible.

The contributed patches start with this post to the linux driver project list.

————–
To: devel-request@linuxdriverproject.org
[PATCH 0/11] staging: udlfb: patches from udlfb development branch (Bernie Thompson)

This patch series contains all current fixes and features from
the udlfb development branch.

udlfb is a framebuffer driver for DisplayLink USB 2.0 era chips.

Diffstat of this 11 part patch series:

udlfb.c | 989 +++++++++++++++++++++++++++++++++++++++++———————–
udlfb.h | 41 +-
2 files changed, 664 insertions(+), 366 deletions(-)

Major changes:

* Added summary documentation for users of udlfb
* Added logic to query DisplayLink chip for max area mode,
so low-end chips on high-end monitors no longer get black screen
* Added support for DPMS. X servers now control monitor
power with existing standard interface
* Added back in support for char interface (e.g. cat file > /dev/fb0)
* Systems without EDID or with failing EDID can now supply fixed
EDID to sysfs interface, also avoiding black screen
* Fixed big-endian (PowerPC) rendering
* Fixed teardown race conditions that could result in shutdown hang
* Added fb_defio and fb console module options (default off)
* Fixed udlfb’s fb_defio client code so no longer incorrectly shares
state across udlfb device instances – fixes hangs and errant rendering
* Removed IFDEFs for building against older kernels – those will
be retained in the udlfb development branches at git.plugable.com

Todo:

There have been no additional reported bugs in the last few months,
although there are several wishlist features. Udlfb may be ready
to move out of staging at this point.

Patches are against Linus’ latest 2.6 tree.

This complete quilt patch series can be downloaded from http://plugable.com/udlfb-patches-2.6.35.tar.gz

After bashing Java so brutally, I have to add another thing to the list of Java features that I wish C++ (or even just a GCC extension) had: @override notation. Imagine this scenario...

You have a base class that implements a bunch of methods, and some of the methods have numerous overloads. We'll call this class base.

You have a bunch of classes that derive from base. Each of the derived classes only override some of the methods provided by base.

These derived classes are used by other infrastructure that just takes pointers to objects of type base.

For example:

class base {
    virtual void do_something(float x);
    virtual void do_something(int x);
    virtual void do_something(char *str);
};

class d1 : public base {
    virtual void do_something(float x);
};

class d2 : public base {
    virtual void do_something(int x);
};

class d3 : public base {
    virtual void do_something(char *str);
};

Everyone with me so far? Sound like every large C++ you've ever seen? Good.

Now the signature of some of the methods in base changes, perhaps by adding a parameter. While making that change, n-1 of the derived classes are correctly modified.

class base {
    virtual void do_something(float x, int y);
    virtual void do_something(int x, int y);
    virtual void do_something(char *str, int y);
};

class d1 : public base {
    virtual void do_something(float x, int y);
};

class d2 : public base {
    virtual void do_something(int x, int y);
};

class d3 : public base {
    virtual void do_something(char *str /* FAIL!!! */ );
};

Try to find the bug or go to drinking island?

In Java this bug would never happen. All of the do_something methods in the derived classed would be annotated with @override. When the compiler found do_something in d3 that didn't match the signature of any do_something in base, it would complain. With C++ you just spend hours trying to track down the bug.

P.S.: I still hate Java.

It seems to be a well-kept secret that the new gdbus(1) command available in the latest GLib releases does bash completion. So here's a quick screencast demonstrating this very useful feature!



Enjoy!

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!

Today's fun idea was to put all my contacts stored into BBDB on a Google Maps' map, using my Google Maps extension for Emacs.

With the help of a few lines of Lisp glue:

(google-maps-static-show
 :markers
 (mapcar
  (lambda (address-entry)
    `((,(concat
         (mapconcat
          'identity
          (elt address-entry 1) ", ") ", "
          (elt address-entry 2) ", "
          (elt address-entry 3) ", "
          (elt address-entry 4) ", "
          (elt address-entry 5)))))
  (mapcan
   (lambda (record)
     ;; We need to copy the returned list, because mapcan will modify it later
     (copy-list (bbdb-record-addresses record)))
   (bbdb-records))))

we can make that:

It's really simplistic, but I did not need more to have fun. :-) This could be extended to set a specific marker and/or color for each contact, with a legend. I'll let that as an exercise for my readers.

Wireless router

I've been at Novell for two years and a half now, and it's been an interesting ride. I must say I've had two amazing bosses who understand the way I work and who have been really supportive, so that definitely helps! I don't know if Klaas will stand me much longer, though ;-) In addition to that, being part of the Boosters is a good way to be with people as crazy as I am, working on weird stuff like me.

Of course, it has been hard to see good people leave the company in the past few months — they are generally still involved upstream, though, so that's positive :-) But recently, we've been joined by two friends: Frédéric, who's working on SUSE Meego, and Jos, the new openSUSE community manager. And guess what? We expect more! Because we're still hiring:

• the very same team I'm part of (remember, the crazy people) is looking for a new member. The job description is, well, you know, a job description ;-) What is most important, in my opinion, is that we're looking for someone who understands free software communities: the goal of the team is to grow the openSUSE community by enabling the community, and we're having fun with that! You can have the right profile even if you don't know the openSUSE community well at the moment: for example, it's totally fine to come from upstream (some of us do have an upstream-only background). I heard that some people even wonder if it's normal to get paid for such a job. But yes, you will get paid. To apply, go here and use the openSUSE booster keywords.

• our SLED team is looking for a GNOME developer to help with the maintenance and the development of SLED, and I certainly hope that this developer will also work with the GNOME team in openSUSE :-) If you enjoy fixing bugs and adding some nice features that make a difference to users, this could be a good position for you! To apply, go here and use the SLED GNOME keywords.

If you want to chat about any of those jobs or about how it feels to work at Novell, don't hesitate to ping me!

The Debian package of Emacs Muse was maintained by Michael W. Wolson, who is also the upstream author of that software.

He announced months ago that Muse needed a new upstream maintainer. That's not something I'm willing to do, since I really think Muse has been superseded by Org mode nowadays.

However, I'm still using Muse to maintain this blog with my muse-blog extension, since Org still lacks some infrastructure to maintain and publish a blog.

Therefore, I adopted the Emacs Muse Debien package and updated it to the latest version!

GUADEC Open Space by Sense Hofstede (Creative Commons by-sa)

See my previous post for the first GUADEC tidbits.

• Of course, Fernando and Xan's talk was a great moment!

• Apparently, I was not for sale (I didn't know, or well, I knew it). And the result is that someone I won't name (let's call this someone Kat) tried to buy me. Without success.

• Sílvia and Gil won the GNOME Pants this year! Woo! It's a bit sad that they chose to wear it only during the Collabora party: they pretended they were not the right size...

• I had quit an interesting chat with Luis during the Collabora party. I liked his keynote.

• Gustavo and I are invincible at table football when in the same team. Mwahahaha!

• Some people didn't know how to easily get GNOME Shell running from GDM. I hope that by now, most distributions do something like openSUSE, where you can select a GNOME 3 Preview session in GDM.

• Ryan made some I support the release team stickers. Sweet. He also made some that used a cryptic vuntz 3.0 message...

• Bastien didn't win the FreeFa Cup 2010. Good: it's a tradition :-)

• Jos, the new openSUSE community manager, happens to live just a few kilometers away from the Hague. He was still at his previous work back then, but we were able to share a dinner before the Canonical party.

• I got a very nice Openismus t-shirt (thanks Kat!). I was told there's a fox on it. I see a cat.

• Lennart now loves me.

• In reaction to the I support the release team stickers, we got a great "Down with the release team" banner. I loved it :-)

• It was great to have more time with Dominique, one famous openSUSE hero.

• I finally found two secret git repositories used by designers: gnome-design and gnome-shell-design.

• Bastien and I tried to send a poster to a generous Friends of GNOME donor. During 45 minutes, we walked around, asked people, looked on maps, etc. to find a post office. And when we found one, it didn't have what we needed to send the poster. Oops!

• Didier helped me find a real post office on Saturday. And there we were able to send the Friends of GNOME poster.

• I was finally able to chat with Adam from Yorba. I've been wanting to meet the great people at Yorba for a long time!

• Some people are talking about a French Conspiracy. I don't know why. Anyway, after Reinout's closing speech, Bastien and I went on with the closing ceremony together.

• The Foundation released three press release this week. Many thanks to Zonker for his help for this!

• The next GUADEC will be in Berlin, with Akademy! I'm already excited!

I came back from the Hague after GUADEC nearly two weeks ago, and I still haven't posted anything about it. Bad me. The short summary: it was a really great event! I don't know exactly why, but I'm thinking it's the GUADEC I enjoyed the most. Many thanks to all the organization team who did a fantastic job! Also a big thank you to the sponsors who made this event possible!

GUADEC Group Photo by Nicolas Christener (Creative Commons by)
See the whole set or download the full sized pictures.

The first few days of the events were quite busy between a good board meeting on Sunday (woo, and the last one for me!), a Monday where Frédéric and I chatted with various teams about the current status of GNOME and an advisory board meeting with useful feedback on Tuesday. Busy but good busy. And after that, the event simply went well. I don't think I attended many presentations since I used most of my time to chat with people — that's what is most useful for me at events.

Some tidbits about the event (I have more coming in a later post):

• The first thing I did when I got at the hotel: I slept for a few hours. Jetlag. When traveling from France to the Netherlands.

• Apparently, Diego and Germán slept together, and took a shower together. I'm happy for them!

• Quote from the very first evening: This is not javascript, this is real code. -- Diego, who works on a web browser.

• The Love Wall was filled. We still have some hate, obviously!

• Somehow, I couldn't stop saying we when talking about the board. I guess that's what happens after four years and a half.

• Daniel (or David? ;-)) has a twin, Adrien, and it turns out they were sharing the same room.

• We had a release team meeting during the event. On IRC. (only two release team people were in the Hague on Monday).

• I was surprised to see the GNOME roadmap we've started working on in Jon's slides. But good surprise :-)

• People loved the openSUSE Geekos we gave away! We need more of that!

• GUADEC was the first event worldwide to be streamed in WebM! Thanks to Flumotion and Fluendo!

• Oh, and we decided to release GNOME 3.0 in March 2011.

HTML is not the Holy Grail

There were a few talks at GUADEC that were around the topic of web and trying to figure out ways to build bridges to the web world from the GNOME community and technologies.

It was praised by some, most notably Luis Villa, that HTML/CSS/JS was the way to go. However I think that this is grabbing the stick from the wrong end in many ways.

The interesting parts of the web are not its front end technologies as such (the fact that they are standards and you can assume everybody has a browser is though). The interesting bit of the Web as a platform is the ability to syndicate, publish and aggregate content.

I actually think that the so called fact that people love HTML+CSS+JS is sort of a myth. The reason there's so many people doing stuff with it is not because it is a great technology, it's because:

• You can reach a huge user base deploying a web app
• It has a lean learning curve

People go through the pain of building apps with these technologies because it's worth the pain, and actually, for a lot of applications it's the better option. But it's still a pain.

However, suggesting that this is how GNOME should move ahead is in my opinion not the fastest path to provide a great user experience. Which is what GNOME is all about.

It's all about the data!

In my opinion, what we really fail at is at providing tools to create rich user experiences for data driven applications, and ways to feed data from the web more specifically. This has a lot to do with the poorness of our platform when it comes to ways to talk HTTP, libsoup for example is not such a great API for application developers for many reasons.

Then there's Gtk+'s lack of proper views for large datasets and GtkTreeModel is not necessarily a general purpose data model API. This is why, by the way, we developed libmodel at Codethink and created a GtkTreeModel wrapper around it.

I think the ones really pioneering in this field are the Intel guys with libsocialweb and Adrien Bustany on online providers for Tracker. But we still miss the "glue" for our great front end technologies (Gtk+/Clutter/MX) so that application developers can put together apps consuming and pushing online data real quick.

The browser is nice and all but...

There is a reason why Google, one of the main pushers of the web technologies, still have Java based apps in the android platform. There is a reason flash is not going away and Silverlight and JavaFx are here to stay as well. The closer you are to the hardware, the better the user experience can be. The quicker you can put together your apps, the better.

Pushing the boundaries of HTML is a nice thing and I'm happy to see Flash, Silverlight and JavaFx going away as substitutes of content that could be deployed as web content in the first place, but innovation and design by committee are not real good friends. We need a platform that can move as quick as hardware does, as much as we need a web platform as well that can cherry pick the innovations

Opportunities for collaboration, our friends from Mozilla

There is however a huge opportunity for the GNOME community, if we start making steps towards a better toolchain for data driven applications, I think building bridges with the Mozilla community can be a major win. I know what you're thinking, Gecko. No, I actually think WebKit is the way to go as our rendering engine, Gecko is there to follow Firefox's agenda. Fair enough.

There's a space in which building bridges with the Mozilla community can be even a biggest win for both ends, the web services space. Mozilla is creating amazing web services and tools, Firefox Sync, Bespin, Contacts.

GNOME seriously lacks of a community of people dedicated to build web services around the platform, and Mozilla is has that sort of focus. Together I think we can join forces solve this ongoing problem of closed source web services and all the privacy concerns around them by building a truly rich and open ecosystem of server and client side technologies.

I guess a few people remember that Clutter was proposed for inclusion one year ago. Most of the GNOME community loves it, so there was no real question about accepting it. Except that it required copyright assignment, and the release team didn't really know how to handle this. So we contacted the Foundation Board to see what should be done. And the Board did two things: talk to Intel about it, and work on a more general solution.

First, we talked to Intel to understand if the copyright assignment for Clutter was really needed, or if it could be removed in the future. As this is a discussion involving some legal magic, it obviously took some time. But Emmanuele kept pushing this internally to get a resolution, and in June, it was announced that everybody could contribute to Clutter without signing anything :-) Thanks Intel! It's my guess that this happened not just thanks to GNOME, but I don't have any details on that...

Still, we wanted to have some general guidelines to know how to proceed in case this happens again in the future. The Board discussed this topic with the Advisory Board in December, and after the discussion, we felt that Bradley and Michael had a position that reflected best what would be the position of the community. So we asked them to work on the topic. They wrote some blog entries about the topic, and drafted a first document providing a policy for copyright assignments in GNOME. This got discussed again with the Advisory Board, and finetuned. The whole process took quite some time — and Bradley talked about it during a lightning talk at GUADEC.

As a result, we got two documents that were published in July on the wiki, but I actually only really announced them now. You can read the policy and the additional document, but here's the short version for the lazy ones (quoting my mail):

The inclusion of a new module in GNOME that requires copyright assignment has to be explicitly approved on a case-by-case basis by both the Release Team and the GNOME Foundation Board. The decision will be made based on criteria explained in the policy as well as in this additional document.

It was a great experience to work with Bradley and Michael on this, especially as I was doing nothing and they did all the hard work :-) So I'm glad this is finally out, and even though I personally hope we won't have to look at copyright assignments in the future, at least, now, we will know what to do if the original issue occurs again.

Just a reminder that the linux.conf.au 2011 call for papers is closing THIS SATURDAY, 14th August! If you haven't already submitted your talk, get in now while you still can ...

I mentioned the GPU Ray Casting of Virtual Globes poster in a previous post. The author has since sent me a link to an updated version of an older blog post with the poster, a five minute video, and source code. Cool stuff. The video is 18MB, so be prepared.

Patrick is also working on a book called, "Virtual Globe and Terrain Rendering". I'll watch for that at the next SIGGRAPH.

There are a few frequency meter implementations available for Atmel's microcontroller series, but I haven't come across a reasonable reciprocal frequency counter implementation, let alone one without extra hardware.

Thus I created a software only reciprocal frequency counter running on an ATtiny2313 (ATmega not tested yet) with a usable frequency range of 0Hz..10MHz (when running at 20MHz), sub-Hz resolution, and 10ppm accuracy or better.

This requires 64bit arithmetics, for which the libgcc routines are prohibitively expensive on ATtiny. The 64bit routines in C and assembler I thus implemented for this project require much less space.

rainbow-mode had a big success and good feedbacks when I released it for the first time a couple of months ago.

Several users asked to me request its inclusion into Emacs. Therefore, some days ago, I proposed to merge it inside Emacs trunk. My request has been denied, but the mode has been added to the Emacs 24 package repository.

In the mean time, I've added support for hsl() and hsla() support, and added CSS 3/SVG color names.

These weeks have been a little bit crazy for me(my bachelor thesis need to be wrote ). And a bug in my fill pattern code was make me crazy. Finally last week I fix it and implement some blend operations(CLEAR, SOURCE, IN, OUT, ATOP, XOR and others)  and in parallel began to learn about font rendering.

I already have something working.

But it is a little bit ugly because it does not have antialiasing =/. So these weeks i have plans to improve the code and fix bugs, bug and bugs. After that work in font support and finally  make some work with anti aliasing techniques. I already have studied some papers[1][2] but if someone had others ones would be fine .

[1] http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter22.html

[2] http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html

In case you're not subscribed to xorg-devel, I've sent off the first draft for the multitouch X protocol specification (as part of the X Input Extension 2.1) today. If you have interest in multitouch, please read through it and see if you can poke holes into the current approach.

http://lists.freedesktop.org/archives/xorg-devel/2010-August/011759.html

Note that this is very low-level stuff. The data described by the protocol is what's sent on the wire to the client. Most applications are separated from this data by toolkits (GTK, Qt, etc.) and only few people are unlucky enough to have to care about the protocol itself.

So the registration system for the GStreamer Conference 2010 is now open together with the registration for CE Linux Conference Europe 2010.

You find the registration for both conferences here so I hope to see as many of you as possible registered. I think we have a great program and some really interesting talks!

I spent the last 3 weeks working on adding presubtract support to the r300 compiler. It turned out to be quite an undertaking. I had to make some major changes to some core parts of the compiler to get it working. I think it is pretty stable at the moment, but I would like to refactor some of the code and add support for the add and subtract operations before I merge it in to master. I would really like to create a sort of optimization framework that makes writing new optimizations a lot easier, so that will be part of what I do when I add the remaining presubtract operations. I'll probably pick this up again after my GSoC project is finished. For now, I am going to focus on loops again. Right now, I am working on handling breaks and continues for r500 fragment shaders. Once I get that working, I'll see what I can do about loops in Vertex shaders.

While trying to autogenerate C interfaces for XKB during the last 2 months it sometimes felt like an attempt to "behead the Hydra": Whenever I fixed a problem, a number of new issues arose (deep from the intestines of the python code generator). At the moment it seems I have reached a state where no new heads emerge, and I even managed to cut off a number of the most ugliest...
The cause of most (all?) troubles is a very basic way of distinguishing data types into fixed size (everything you can feed to sizeof), variable size data types (lists, valueparams, ...) and padding. In the X protocol fixed size fields are normally grouped together, so e.g. in a request all fixed size fields are collected before any variable size fields.
XCB, whose purpose it is to translate between X server and client, takes advantage of this ordering: Several grouped fixed size fields are conveniently mapped to a C struct, so it is fairly easy to deal with. The treatment of variable size data is more difficult and involves the use of (autogenerated) accessors and iterators. Also the specific number of elements in a variable size data type can depend on expressions that are specified in the protocol, but need to be evaluated at runtime.
Now XKB breaks with the "pure doctrine" of the X core protocol: Fixed and variable size fields are intermixed in several cases and new expressions are introduced. Further problematic cases include a variable size union, lists with a variable number of variable size elements, ... And finally, the keyboard extension defines a new datatype (ListOfItems), which is referred to as 'switch' in XCB.
Switch is a kind of list, but the 'items' are not necessarily of the same type, and whether an item is included or not depends on expressions that have to be evaluated for each item separately. Defining a C mapping for 'switch' was one of the main goals of my work, and it turned out that a set of new functions was needed. These new functions must either 'serialize' a switch into a buffer, depending on the concrete switch conditions, or 'unserialize' it to some C struct. As 'switch' can contain any other data type valid in the X protocol (which means especially that it also can contain other switches...), 'serialize'/'unserialize' had to be defined for all those data types.
Once I had the autogenerator spill out '_serialize()' and '_unserialize()', it turned out they can be used to deal with some other special cases as well - most notably the (above-mentioned) intermixing of fixed and variable size fields.
But probably the most appealing feature of the serializers is that they are invisible to anyone who wants to use XCB as they get called automatically in the autogenerated helper functions.

A last note on the current status:
+ xkb.c (autogenerated from xkb.xml) compiles!
+ the request side should be finished (more tests needed however)
+ simple XKB test programs run
- on the reply side, special cases still need special treatment
- _unserialize() should be renamed to _sizeof() in some cases
- some special cases also need special accessors

The code is currently hosted on annarchy, but I will export the repos shortly.

I too forgot to mention that my accommodation at GUADEC was sponsored by the GNOME Foundation. Thanks guys!

I been working on a web page for my wedding in November. This has turned out to be quite a lot more painful
than I expected and I have to admit my respect for web developers have increased a lot due to it. Getting a webpage to look nice across all browsers seems to be a really painful job.

Currently the only browser in which my page works perfectly is Firefox, Opera also does a mostly fine job, while Chrome fails on handling a dynamic SVG image I embedded in the page, and IE8, well lets not talk about what horrendous results it gives

I guess it's a bit beating a dead horse, but I had a good laugh today when I learned that I alone contributed more to GNOME than the entirety of Canonical, and only 800 additional commits seperating me from being more awesome than Nokia.

/me is amused

It’s not quite upstream yet, but there’s enough code out there for it to be useful. And by describing it maybe a few contributors will step forward to help with the remaining pieces. :)

First off, you’ll need Jason’s KGDB tree with a few fixes from me on top. I’ve collected them all at git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/kgdb-2.6.git in the kdb-kms branch.

Go ahead and build that kernel, and make sure you have CONFIG_KGDB_KDB=y and CONFIG_KDB_KEYBOARD=y set in your kernel config. After installing the kernel, add “kgdb=kms,kdb” to your boot command line. This enables the KMS enter/exit hooks and allows KDB to be driven from the locally attached keyboard.

Once you’ve rebooted, you should be able to enter KDB using SysRq-G or “echo g > /proc/sysrq-trigger", or by hitting a bug or breakpoint. Resuming from where you left off is as simple as typing ‘go’ from the kdb prompt.

The above should work ok for simple cases today, but there are several outstanding issues:

1. console unblank support - currently when you enter KDB it will try to unblank the console. Since this path takes locks in the console, fb and drm layers, it can cause problems. Fixing this shouldn’t be too hard though; the kdb enter hook should take care of actually unblanking the console (e.g. if it had been DPMS’d off before), so all KGDB needs to do is make sure console I/O is enabled, which is a smaller console and fb bookkeeping activity. So the console hook needs to be split and the fb enter hook needs to handle preparing fbcon for I/O.
2. cursor save/restore - right now, when you enter KDB you’ll still see the cursor if it was enabled when you entered. Saving and restoring cursor state should be handled by the fb hooks, but the DRM hooks currently don’t bother.
3. driver support - I’ve only tested on i915, but adding radeon and other KMS support should be fairly straightforward. Likewise, adding support for plain fb drivers should be pretty easy as well, they just need a small function to write the scanout base register, ideally to the previously allocated fbcon memory location.
4. enhance the DRM KMS layer to allow the reservation of a dedicated debug crtc, encoder and connector tuple - this would allow keeping the kernel console active on e.g. the VGA port, making debugging of desktop applications and the graphics stack easier.

That’s it for now, hopefully we can get at least some of this merged for 2.6.36 (the fb and DRM changes in particular are very small).

Here's a podcast interview with yours truly where I speak a little about PulseAudio and systemd. Seek to 64:43 for my lovely impetuous voice. There's also an interview with Owen just before mine.

Here are the slides at least. They are of course missing the fullscreen demos.

Cairo: 2D in a 3D World

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!

You can share files on your N900 via Bluetooth, E-Mail and web services (Flickr and Facebook) thanks to libsharing-dialog. But there is no file transfers to a contact through instant messaging.

The sharing dialog with Bluetooth, E-Mail and web services features

But look, the sharing dialog is obviously missing a fourth button named “Share via IM”!

Jonny Lamb wrote Monorail, a file transfer application for the N900. Monorail is a standalone application using the Telepathy framework but so far it does not integrate with libsharing-dialog. Libsharing-dialog is supposed to be extensible by plugins (see the Sharing Plug-in documentation). Unfortunately the API is more suitable for web services than for file transfers through instant messenging so it makes the work more difficult.

So I implemented that fourth button with some hacks to workaround the limitations of the libsharing-dialog API:

• The Monorail package dpkg-diverts libsharingdialog.so into /var/lib/funsharing/
• Monorail implements a new library (aka libfunsharing) replacing libsharingdialog.so with the same ABI
• Libfunsharing calls dlopen() on the real libsharingdialog.so
• It also patches the class GtkTable in memory (see struct GObjectClass->constructed) just before calling the real function from libsharingdialog.so, and restore it after the call. I use this hack to get a reference to the GtkDialog and the GtkTable containing the three buttons (the libsharing-dialog API does not give us any reference to these objects)
• In the constructed function of GtkTable, it adds a 4th button “Share via IM” which sends the filenames to share via D-Bus to Monorail
• Monorail receives the filenames from libfunsharing via D-Bus, shows the contact selector and send the files as usual.

The sharing dialog after installing Monorail 0.3

It works fine in the file manager and the image viewer. Do you know any other application with a file sharing feature?

The address book can share contact cards via SMS, Bluetooth and E-Mail but it does not use libsharing-dialog, so Monorail does not automatically add my “Share via IM” button.

Send a contact card from the address book

But since PR1.2, the address book has a new plugin API and it automatically links to your plugins installed in /usr/lib/osso-addressbook/plugins.  The plugin API is designed for menu extensions and does not have helper functions for the sharing dialog. But with Marco’s help, I replaced OssoABookSendContactsDialog’s constructed function to add the fourth button:

Send a contact card from the address book after installing Monorail 0.3

Monorail 0.3 is available in maemo extras-devel.

I wrote a new script to launch a gdm login screen when a Plugable Docking Station is attached on the machine. To use this script, I reduced the number of ConsoleKit display.d, session.d and seat.d files. Now there is only one of each kind of file. The current version of my work is hosted at my git repository. To test it just follow the same tutorial of the last post and then attach a Dock Station on the machine. A gdm login should appear at the monitor.

Even though I'm completely exhausted, it was well worth the effort to get up for the Large Steps Toward Open Source panel. It seems that the movie industry is today where the computer industry was 10 years ago w.r.t. open source. They want to join the cool kids, but they don't quite "get" it yet. The biggest failing is that they only want to open source something when it's 1.0... after it has been used on a couple movies. ur doin it rong. sigh...

The single exception seems to be Sony Pictures / Imageworks. They have realized that the community is an integral stakeholder at every step of a successful open source project. The first slide from Rob Bredow's part of the talk said, in big letters, "Develop a community." YES!!!

In any case, there were a couple choice quotes and some cool projects. The best was Andy Henrickson from Disney Animation saying, "Disney isn't in the habbit of giving things away for free." He made another comment that I think really strikes to the core of why open source is so important across industries. He said, "Some things have no value unless you give them away."

I also liked a couple of comments from Florian Kains (of ILM). When talking about their move to Linux, he said, "All our production used to be on SGI machines at one point, but that ceased to be viable." I have to give some credit back to George Lucas. Apparently he was the one who got the "no value unless you give it away" argument that ultimately led to OpenEXR being open source. Florian siad, "Once George signed off, all the lawyers said, 'Yes sir, Mr. Lucas.'"

Here's a run down of current and future projects from the various presenters:

• Disney Animation - current projects

  • Ptex

  • Pythoscope is test generator for Python. Next time I have to do a large Python project, I'll take a closer look at this.

  • Maya Dynamica front end for Bullet Physics

  • Partio -> Particle input / output library to abstract many, many different formats. It is intended to be "the" interchange library for the various particle systems used in production.

  • Disney's (mathematical) expression editor. This was a pretty rhobust set of widgets and a parser for mathematical expressions. It looked pretty damn cool.

• Pixar Animation Studios

  • Rhobust, accurate, readable subdivision surface reference library. They have big plans for this, but it looks like they're going to do it wrong. They're going to develop it completely in house, in isolation, then release it when it's "done."

• ILM

  • OpenEXR

  • Alembic

  • A couple other projects that I didn't write down. Sorry.

• Sony

  • Open Shading Language As an aside, Rob mentioned that Rhythm & Hues plans to use OSL in a future project.

  • Alembic

  • OpenColorIO

  • Field3D

  • Imageworks SP Reticle

  • Scala Migrations

  • Pystring

I was also impressed that both Sony and ILM give money (ILM to Python) and machines (Sony to some "small" Linux distro) to "pay" for the open source software that they use. Florian did comment that it's often really, really hard to pay people for stuff. He gave a hypothetical example of trying to donate to some random guy in Wales. What's his tax ID? How do I notify the government? Etc.

The Games & Real Time had some good presentations, but by the time it came around (the last session on the last day), I was exhausted.

User-Generated Terrain in ModNation Racers had some pretty cool ideas. They let the user draw the terrain map using brushes. Instead of storing the drawing, they store the brush strokes. This allows them to have a very small in-core foot print. Of course, all the terrain "drawing" is done on the GPU. New terrain is combined with existing terrain using the alpha blend unit. They even use min/max blending! I'll have to rent this game (sorry!) to try out the editor.

Irradiance Rigs is largely based on several algorithms (irrandiance volumes and spherical harmonics lighting) that I'm not familiar with. meh. I need to get on that.

Practical Morphological Anti-Aliasing on the GPU was a GPU implementation of an algorithm presented last year at SIGGRAPH. Basically, you scan the rendered image from certain types of sharp features and blur them. It's a major hack, but it does fix may unappealing artifacts. It's still pretty slow, and it doesn't handle some common cases (e.g., breaks in rendered telephone lines).

One of my favorite phrases in graphics: "[This algorithm is] not physically correct, but plausible." Curvature-Dependent Reflectance Function for Rendering Translucent Materials reminds me a bit of a poster that I saw at SIGGRAPH last year, but I couldn't find any information about that. I might have a flyer or something at home. It's also similar to the curvature based AO technique that I mentioned yesterday. A preprocess step determines the curvature at each point. This curvature is then used in a different sort of lighting equation boost lighting. The equation is fairly complex, and the fast implementation uses a look-up texture based on the material properties.

The biggest failing seems to be a variety of unfortunate interactions with shadows. The precomputation step also hurts, but not as much. Still, it seems pretty cool.

Even if I recently stated I lost some of my faith in XCB, I still sometimes hack things to add support for it.

These last days, I've worked on a D-Bus port from Xlib to XCB. The port was quite straight forward, since there's only a little piece of D-Bus using X, which is dbus-launch.

I though D-Bus was a good candidate, since it's part of the Freedesktop initiative. Therefore, I was expecting a warm welcome and some enthusiasm from a fellow project.

My contribution got one useful review, and a cold reply from Thiago Macieira (a KDE/Qt/Nokia developer):

No, sorry, I don't agree.. I've just checked and my Solaris machine doesn't have XCB. Please do not remove the X11 code. You may add the XCB code, but you cannot remove the X11 code.

This is not really the kind of answer I expected, actually. I then reworked the code to please Thiago, and added some #ifdef to add XCB support to D-Bus, with a fallback to libx11 where XCB would not be available.

Havoc Pennington replied:

Given that libX11 now uses xcb as backend, I don't understand the value of porting to use libxcb directly when there isn't an issue of round trips or other stuff. It will just make #ifdef hell, while the X11 API is an API that works on both xcb and non-xcb platforms. Maybe people should be thinking about porting xcb to non-Linux platforms? The X protocol should be the same on other UNiX, so xcb in theory ought to work fine if you just compiled it on Solaris/BSD, same as GTK or dbus or Qt would work fine.

The last part "Maybe people should be thinking about porting xcb to non-Linux platforms?" is still unclear to me, even though I asked Havoc to explain what he meant.

Finally, Thiago refused to merge the patch:

[…] thanks for the patch, but like Havoc I am unsure of the value. We can't drop the X11 codepaths now because too many systems exist without XCB. Adding the XCB codepaths only made it more complex, even though you did a good job.

I can't disagree with that conclusion: using both XCB and X11 make the code unreadable for little gain. That's why I did replace libx11 by XCB directly in the first version of the patch. On the other hand, D-Bus people does not seems to really care about making their software evolve in the right direction, even if that requires users to upgrade their systems.

I think D-Bus using and depending on XCB would have been a good point to push adoption of XCB. Unfortunately, it seems you can't even rely of projects of the same initiative (i.e. Freedesktop) to work together to make things a little bit better.

After 5 years of existence, XCB is still not so obvious to people, and making it adopt is going to be a challenge for the next years. The upside is that new X.org 7.6 will bring XCB with it, as part of the katamari.

I got to the Textures session a bit late because I went to Nvidia's "OpenGL 4.0 for 2010" session, and the session went over by 20 minutes. It was a good overview of OpenGL 4.0 / 4.1. Nvidia (Mark Kilgard, more precisely) continues to spread mis-information about the compatibility profile, and that's really frustrating.

I missed all of By-Example Synthesis of Architectural Textures and everything except the results of Synthesizing Structured Image Hybrids. The results in the later were very cool. I especially liked the synthesized pirate flags.

Every year there's some piece of cool tech at SIGGRAPH that I want to implement. I think Vector Solid Textures is it this year. It's a very clever method of compactly storing volumetric textures as a sort of voxelized SVG. The complex step, of course, is generating the texture data. Any algorithm that utilizes sub-algorithms with names like "L-BFGS-B minimizer" and "teleportation" is bound to be frightening. lol.

The Mesh Colors presentation started with an excellent overview of all the problems with 2D texture mapping. If he had stopped there, I would have called it a useful presentation. Of course, he didn't stop there. The idea behind mesh colors is that a set of colors are stored for each triangle (one per vertex, one per edge, and N per triangle) along a tessellation grid (basically). At run-time the UV value is used to weigh the nearest colors. The frustrating bit of the presentation was the massive amount of hand waving (shown in the photo below) about the implementation. I suspect the details are in the paper. The hair farm shirt was a nice touch.

It also seems like there is a lot of area for future research. The filtered performance is pretty poor. I had a brief discussion with Cem about using hardware tessellation (to a level that matches the mesh colors pattern) to solve some of the filtering issues. It seems like it could work in some cases, but it presents problems of its own (i.e., potentially a lot more work for the rasterizer).

I may have to implement this algorithm too.

There were a bunch of cool things in the poster session, and I took the opportunity today to talk to some of the authors. There were several useful posters about soft-shadow algorithms, a couple about image enhancement, and a couple about ambient occlusion. I especially liked Curvature depended Real-Time Ambient Occlusion (sic). They use a preprocess to determine the concave curvature at each vertex. At run-time, this is interpolated, and the interpolated to determine the AO. The interpolation here gives a better result vs. per-vertex AO in the same way that interpolating light parameters gives better results than interpolating per-vertex light calculations.

My two favorite posters were GPU Ray Casting of Virtual Globes and, I kid you not, A Physical Rendering Model for Human Teeth. I plan to add both of these to my VGP curriculum. The tooth shader is useful because it shows a case of a lighting model developed for a specific type of surface.

The other poster that really caught my eye was the WebGLU poster. It sounds like Benjamin is doing a lot of the same things for WebGL that I'm doing for desktop GL. He and I talked, and there may be some colaboration in our future.

There are some things to really like about Open Shading Language. Being able to arbitrarily connect shaders (via matching inputs and outputs) in a DAG is something that I've been talking about doing in OpenGL for years. Pulling data out by specifying an arbitrary expression on shader outputs is also genius. In OSL the data gets dumped as an image, but I still see use for this in GL.

The implementation of automatic differentiation is really, really smart. I suspect that something like this could even be implemented in our hardware shaders. This would allow higher quality derivatives in some cases. I guess I need to read the Piponi paper from journal of graphics tools.

And they now use LLVM.

Since this system has texture mapping support in this system, this might make an interesting test bed for my thesis work. Hmm...

REYES Using DirectX 11 wasn't too interesting to me. During the Q-and-A period, someone (the previous presenter, in fact) asked what could be changed in either DirectX or the hardware to make this either easier or faster. Being able to insert compute shaders directly into the pipeline (to eliminate the intermediate buffers, synchronization, etc.) would have helped a lot. This isn't the first time I've heard a request for this.

The WebGLot: High-Performance Visualization in the Browser (slides available) guys are doing some really cool stuff on top of WebGL. We'll need to use this app to test WebGL on our drivers!

The Gazing at Games: Using Eye Tracking to Control Virtual Characters course didn't feel like a course. It felt like a presentation of a survey paper on what people have done related to eye tracking in games. I got references to a bunch of papers that seem interesting, but that's about it. I do like the idea of "smart text." Text (dialog, etc.) is displayed until you look away from it. I had to leave early to go to the OpenGL BoF, so I probably missed the best parts. shrug

The highlight of the OpenGL BoF was, of course, the announcement of GLU3 as part of the OpenGL SDK. Getting a round of applause was cool.

One of the trivial questions was, "What ARB extension has not been shipped in any publicly available driver?" Answer? GL_ARB_shading_language_include. Damnit!!! Okay, we need to add that to our compiler todo list. Ugh. It's a cool feature, and John Kessenich, Jon Leech, and I spent a lot of time working on it. In all fairness, GLSL needs a much better module mechanism than it currently has. I have some ideas, but they'll have to wait until our new compiler actually ships at least GLSL 1.30.

The Importance Sampling for Production Rendering course was interesting, but a lot of it was review. I hadn't noticed that the first presenter in the course was also the author of the GPU-Based Importance Sampling from GPU Gems 3 that I use in VGP352. The bits about multiple important sampling and the bits about resampled importance sampling for shadows from the second presenter were new to me. There was a question from the audience about the Lafortune BRDF. Matt's response echoed what I say in VGP352 every year. He says that the Lafortune BRDF is not used at IMD beause it is "too uncontrollable for many artists."

I don't really know anything about REYES, so most of Micropolygon Ray Tracing With Defocus and Motion Blur was lost on me. The hyper-trapezoid BVH was interesting, though. Real-Time Lens Blur Effects and Focus Control was similarly a loss. The foreground occlusion image may find a place in VGP352 when I talk about depth-of-field effects. OptiX: A General Purpose Ray Tracing Engine was mostly an advertisement for Nvidia's ray tracing engine. There were a couple interesting bits about their compiler architecture, but meh.

To this point, I wish I would have gone to the An Introduction to 3D Spatial Interaction With Videogame Motion Controllers session instead.

That changed with Reducing Shading on GPUs using Quad-Fragment Merging. One of the opening tidbits will annoy keithp to be sure. "...one of the better ideas of real-time rendering [is] multisample anti-aliasing." In any case, their method of merging quads (2x2 pixel blocks processed by the fragment shading hardware) is fairly straight forward, but still clever. They track facing and connectivity for covered pixels in each quad. Multiple quads that have connected triangles with the same facing are merged. This can save a lot of processing.

Much to my joy, the Making of TRON: Legacy session got moved to Tuesday evening... when it didn't conflict with anything that I wanted to attend! w00t! Yes folks, that is the line...

EIGHT MINUTES of footage from the movie. A new trailer (I want one of those lightcycle throw pillows from 0:12 in the trailer). Full on awesome.

A couple interesting bits:

• Daft Punk is doing the music, and they have a cameo.

• Some of the concept drawings from the original movie that couldn't be done on computers at the time was used. For example, the original lightcycles had the rider on the outside. There was no way the computers of 1982 could render that, so the design was changed.

• It was filmed in 3D, but, in the words of the director, there's no "spear poking you in the eye" business.

In the Q-and-A session I asked a semi-smart ass question. That's how I roll. "My biggest disappointment with the film industry came when I was 8 and the original TRON wasn't nominated for an Oscar because it "cheated" [by using computers]. Come January, is it going to be lightcycles or broomsticks? TRON or Harry Potter?" Yes, I know the Oscars are in March. I was nervous. Unfortunately, their answer was way, way too serious. "Ultimately that's up to you, but we think our work will stand on it's own." meh.

UPDATE: One thing I forgot before, there was an off-hand mention by the director that some effort was going into doing a "re-imagination" of The Black Hole. That was such a creepy movie! A re-make could be awesome... or horrible.

Ryan, Juerg and myself are all at Den Haag for GUADEC already for the whole week, Rob will be around by Wednesday. We will be giving away Codethink tshirts during the next few days, so come to poke us if you want one (we have a batch for girls btw!)

See ya around!

This year I was finally smart enough to register at the conference the day before it starts. Yay me. That made is so much easier the first day.

I wasn't expecting a lot from envLight: An Interface for Editing Natural Illumination, but I was pleasantly surprised. There were a couple of surprises in their results. I keep meaning to implement some sort of parameter editing interface for my BRDF demos, and I would have done it quite differently before seeing this paper.

I understand the method in Interactive On-Surface Signal Deformation, but I don't really get how it would be implemented in a real system. I guess that's what I get for not reading the paper before attending the presentation. I would have read the paper if I had remembered to bring the DVD drive for my laptop. That's the one annoying thing about the X200s... no built-in optical drive. In any case, it seems like this approach could be used to great effect in a demo. I imagine a scene where, say, the shock wave from a heavy object hitting the ground causes shadows on the ground to get pushed away.

My first Avatar presentation, PantaRay: Fast Ray-Traced Occlusion Caching was impressive. I guess rendering scenes with 10M to ONE BILLION DOLLARS... er... one billion polygons needs some new acceleration techniques. And a petabyte of "live data" needs some kick ass I/O. There are so many different optimizations implemented here that I think they could have gotten multiple papers out of it. Seriously. Just the layers of optimizations in the spatial index calculation should have been sufficient. Showoffs!

On a whim, I went the SIGGRAPH awards presentation. The cool thing there was a visualization app that shows, on a map of the world, where every technical paper ever published at SIGGRAPH originated. It will supposedly be posted on the web, so I'll link it here soon. The talk by Don "The Tornado" Marinelli really made it worth it, though. You can tell that he comes from a drama background. They also said that some of the content would be posted on YouTube, so his talk may get linked here later.

The word(s) of the day: deferred shading. Screen Space Classification for Efficient Deferred Shading was the first of the bunch. The basic technique is to read back the G-buffer to generate a batch of polygons to draw. The screen is divided into tiles, and the tiles are classified by attributes (e.g., in shadow, direct lit, etc.). On both PS3 and Xbox360 it cuts the frame time by about half. They talked a bit about the optimization of the polygon submission. Since the polygons are tile aligned, it seems like some sort of quadtree could be generated and rendered using point sprites. I'll have to think on that a bit more.

"Boom. 60 is better." lol. How to Get From 30 to 60 Frames Per Second in Video Games for "Free" uses the Z-buffer and the velocity buffer from the current frame and the color buffer of the previous frame to generate an in-between frame. The author was inspired by MPEG motion vectors. Here, it's a big hack. It has a bunch of hacks on top of it to fix artifacts. The best part is the way dynamic objects are "erased" from the frame (this is only necessary with deferred shading). I like it.

Split-Second Motion Blur covered some additional work from Split Second. They render a per-pixel 2D motion vector ID. This ID is then used in a blur post-process. In addition, they update the texture sampling derivatives based on the motion vector. Cheap, easy, good results. I'll definitely add this to the motion blur techniques covered in VGP351 next time it comes around.

Over the last couple years systems for indirect lighting in real-time have been all the rage. Pretty much all of them have used deferred shading. A Deferred-Shading Pipeline for Real-Time Indirect Illumination is shock no different. However, they're algorithm has good quality and speed. The other algorithms that I have seen pick one or the other. They incorporated a clever way to include occlusion for bounces, but this costs a lot of memory. I guess that's the trade off. The method for mipmapping the G-buffer was pretty clever. At each downscale they average the attributes from the largest object. This is sort of a bilateral filter in reverse. It's still screen space, so it has some drawbacks:

• losing indirect light from an object that goes off screen

• no support for mirrors reflecting objects behind the camera

Also, if I hear "current console hardware can't" one more time, I'll puke... or just roll my eyes again. I knew realize dynamic branching was bad on PS3, but I didn't it was so bad on Xbox360. sigh...

I wrapped up the day with Live Real-Time Demos. As Eric Haines notes, they were pretty cool. Thinking back to my days as a demo coder, it brings a tear to my eye to see demos on the big screen at SIGGRAPH.

The full Collabora Multimedia crew is in The Hague this week for GUADEC and our annual get together. It is the first time all 12 of us are together and its nice to spend some time face to face to get to know each other beyond IRC.

Currently doing a little hackfest at our hotel, pushing forward some cool stuff like echo cancellation, PiTiVi and more.

Made it to the venue today, and am currently enjoying my 10th GUADEC. I'm still behind jrb :)

Phoronix published a sensationalist article last week claiming that my regular e-mail updates of our biweekly builds somehow signified some out of the ordinary newsworthy event, without bothering to do even the most basic of fact checking. While I pointed this out in their forums within hours of publication, I'm still seeing it cited by other web magazines that don't bother to fact check, as well as in various e-mails and blogs, so am publishing a more complete explanation here of why it really is a non-event.

The article claimed:

As the first email of its kind in months, Alan Coopersmith who is a known X.Org contributor and longtime Sun Microsystems employee now working for Oracle, has written a new email entitled "IPS distro-import changes needed for X packages for nv_145." Alan immediately began this public email by saying, "Just when you thought you'd never see another one of these biweekly mails..."

Sadly, all they needed to do to disprove the claim that it was the “first of its kind in months” was simply follow the links from the e-mail archive page they linked to, to see that I had sent a similar message two weeks earlier for the previous biweekly build nv_144. In fact, if they checked the archives for previous months, they would have found that, except for missing build 143 (a mistake on my part), I've sent these approximately every two weeks for every biweekly build for a very long time.

Perhaps I'd confused the article's author with the offhand comment he seems to have misinterpreted, but explaining that requires a bit of background explaining what these e-mails are and why I send them in the first place.

As many OpenSolaris users know, over the course of the last couple of years, we've been transitioning from the old SVR4 package system used in Solaris 2.0 through Solaris 10 to the new Image Packaging System (also sometimes known as “IPS” or “pkg(5)”) being developed by a team of Solaris engineers and community members. Initially, we maintained two parallel distros, Solaris Express: Community Edition (SXCE), which was built using the SVR4 packages and the old Solaris installer that worked with them, and OpenSolaris (originally codenamed “Project Indiana”), which was built using the IPS packages and the new Caiman install software designed to work with them. The teams providing the package contents continued to deliver SVR4 packages, and the OpenSolaris distro team converted those to IPS.

One of the goals of the OpenSolaris distro was to provide a set of ISO install images and package repository that was completely, freely redistributable, so that it could be easily mirrored, copied, and downloaded without having to deal with the various encumbrances required by some of the third-party licenses in the traditional Solaris and SXCE packages. Unfortunately, at that time, we had not yet finished separating the encumbered code from the open source code in our X packages so that they could be included, since when Sun made its proprietary fork of X11R6 in the early 90's, the engineers never figured we'd be open sourcing Solaris a decade later and need to easily separate out the encumbered bits they were merging into the main code base.

The initial Developer Preview releases of the OpenSolaris distro thus included a set of X packages that Moinak Ghosh built from the Fully Open X (FOX) project work we'd done to rebuild our source trees from the ground up using the open source code from the X11R7 modular releases in order to ensure everything was either open source or cleanly separated out. Over the first few months, we migrated from those to the packages our team delivered to the OS as we integrated the FOX project work into our main source tree. Because these changes weren't always obvious to the external observer, I started sending notes for each biweekly build to let the team maintaining the SVR4 to IPS conversion tables know which parts of our packages they could now include, as well as any other changes they needed to know about, such as version number changes. (Our SVR4 X packages all used the same version number, a holdover from the monolithic X source days, but we've migrated to using the upstream version numbers as much as possible in the new X IPS packages.) I did this not only to try to help the distro building team, but also to help myself keep on top of the changes they made in converting our packages, so that we could understand issues users hit and know how to help them, and to learn better what we'd need to do when it came time for us to start building the IPS packages ourselves.

Last year, Sun announced that the time had finally come to start converting the builds to generate IPS packages directly, taking the next step in transitioning off SVR4 and ending the production of the SXCE distro, since the SVR4 packages used to build it would no longer be made. The ON consolidation went first, converting the packages containing the kernel, drivers and core utilities in build snv_136. The Install consolidation went next, in build snv_143, and X followed in build snv_144.

So, when I wrote “Just when you thought you'd never see another one of these biweekly mails...”, I simply meant that after build 144, all the X packages are already delivered in IPS format, so there are no SVR4 to IPS conversion files to update for them any more, so I won't need to send those - except in cases like we had in 145, where I relocated one of the files that was listed as a dependency in one of the other packages still being converted by the distro builders, so they needed to update the dependency statement for it to list the new path to the file.

Despite what Phoronix seems to have assumed, I was not in any way referring to the limbo state the OpenSolaris distro is currently in (and unfortunately, as much as I'd like to explain that, I can't), nor stating anything about build 145 that is fundamentally different than the previous builds. It should come as no surprise to anyone that while build 134 was the last build to be publicly released, we have continued work on the Nevada builds after that - after all as we've said since 2005, Nevada is the code name for the development branch in which we're working towards the next full release of Solaris (i.e. not another Solaris 10 update release, but the one we may someday call Solaris 11) - while that's been released under various forms, as the OpenSolaris open source code, or via the binary releases of the original Solaris Express, Solaris Express: Community Edition, Solaris Express: Developer Edition, or the OpenSolaris 2008.05, 2008.11, and 2009.06 distros, we've always kept driving towards the same goal, with biweekly builds assembled to test the current progress.

My mail is hardly the only externally visible sign of this - you can see changelogs for the major consolidations (ON, SFW, X, and Desktop/JDS) for build 144 (the last fully finished build, as 145 is just finishing pre-integration testing now, with a delivery deadline of Monday for packages to be included, and the distro build process starting after that. Of course, the sources are also available, and there's plenty of activity on the various commit notification and discussion mailing lists showing that we're continuing to work away on Nevada.

So unfortunately, Phoronix succeeded in making a mountain out of a molehill, confusing their readers and fellow webzine authors, but likely meeting their goal of driving more traffic to their site to generate page views for their ad revenue as people passed the link around twitter, IRC & email or linked to it from their blogs & articles. As others have pointed out, checking the facts or contacting the developers to find out the story is less juicy than it seems doesn't play well with that business model (and that's not just true for Phoronix - look at any number of the columnists for other web-based "trade publications" that generate traffic via controversial posts, and the more outraged the community gets over them and angrily passes them around to denounce, the better their numbers are - you can just imagine how many of their articles are designed to bait Groklaw or Slashdot readers).

I got myself a little Huawei E585 device, so that I can put in a data SIM card when travelling. My attempts at getting a 3G data subscription in the UK that wouldn't cost an arm and a leg when abroad completely failed, and I didn't fancy carrying a phone just to use as a modem when travelling (I use my usual handset through Bluetooth when in the UK).

The 0.9 release is now available! I'm calling this 0.9 because not all of the functionality is available in the C interfaces. Once that is resolved and a couple other GLSL utilities are complete, I'll call it 1.0.

There is a tag in the GIT repo for the release. The glu3-0.9.1 tag is the "real" tag. I pushed the glu3-0.9 before doing make distcheck, and, of course, there were errors.

md5sums:

75032c9aaf2d279738ce3940383439ff  GLU3-0.9-20100721-bin.zip
63ccdbdb8d6799b9a530b661f1d9d0f7  GLU3-0.9-20100721-src.zip
862b22f67dd7d6f087ff6ba497653621  GLU3-0.9-20100721.tar.bz2
6266c6944128eec4149c8b8101e290df  GLU3-0.9-20100721.tar.gz

The last week I've been trying to get presubtract operations working for the r300 compiler. Presubtract operations are basically "free" instructions that modify source values before the are sent to the ALU. The four presubtract operations for r300 cards are (1 - src0), (src1 + src0), (src1 - src0), and (1 - 2 * src0). At this point the compiler only uses (1 - src0), but now that I have one working adding the others shouldn't be too hard. I had to make some major changes to the compiler to get this working, so I am going to let it sit in its own branch (presub branch at http://cgit.freedesktop.org/~tstellar/mesa/) and test it out for a while before I merge it into the the master branch.

I thought I should share a sneak peak on a small patch I've been working on to add support for markers support in GtkScrollbar, the idea is to add support for hints in things like search matching, or where in the backlog someone named you in a chat dialog. Here's a screenshot of the result in the default theme:

This should bring Google Chrome-like search functionality to gEdit and Epiphany! Now if only I had some time to work on a set of standard inline dialogs to avoid windowed ones :-)

The patch, against Gtk+ master, is pretty much done, waiting for a reviewer to point out any pending details. If everything goes alright it should land for 3.0, subscribe to the bug if you want to track its progress. :-)

So, #collabora was putting chunks of code into iwritelike.com, and I decided to join in the fun. While Telepathy, GStreamer and other similarly soft projects are all apparently written like Dan Brown or David Foster Wallace, I put a chunk of xkbActions.c into iwritelike.com, and apparently it's written like Chuck Norris. Brilliant.