Open voting is available for all session submissions until February 23rd at 5pm CST. This is a great way for the community to decide what they want to hear.

 I have submitted a handful of sessions which I hope will be voted for. Below are some short summary's and links to their voting pages.

• Accelerate OpenStack deployment with OpenStack Admin Appliance ( Speaker: Cameron Seader ) 

In an effort to make OpenStack available to the non-tech user and appear much less of a heavy lifting project, I have created the SUSE OpenStack Cloud Admin Appliance. However, no matter if your an OpenStack Noob, Professional, Expert or Developer...

https://www.openstack.org/vote-vancouver/Presentation/accelerate-openstack-deployment-with-openstack-admin-appliance

• Deploying SUSE OpenStack Cloud with the Xen Project Hypervisor ( Speakers: Cameron Seader, Russell Pavlicek, Stefano Stabellini ) 

Its all about choice these days when it comes to selecting your OpenStack hypervisor. But what makes for a good choice of hypervisor? And why should you consider the Xen Project Hypervisor when there are other possible selections? ...

FOSDEM 2015

It was another great FOSDEM this year. Even with their 5-10.000 attendants, the formula of being absolutely free, with limited sponsorship, and while only making small changes each year is an absolute winner. There is just no conference which comes even close to FOSDEM.

For those on ICE14 on Friday, the highspeed train from Frankfurt to Brussels south at 14:00, who were so nice to participate in my ad-hoc visitor count: 66. I counted 66 people, but i might have skipped a few as people were sometimes too engrossed in their laptops to hear me over their headphones. On a ~400 seat train, that's a pretty high number, and i never see the same level of geekiness on the Frankfurt to Brussels trains as on the Friday before FOSDEM. If it didn't sound like an organizational nightmare, it might have been a good idea to talk to DB and get a whole carriage reserved especially for FOSDEM goers.

With the Graphics DevRoom we returned to the K building this year, and i absolutely love the cozy 80 people classrooms we have there. With good airflow, freely movable tables, and an easy way to put in my powersockets, i have an easy time as a devroom organizer. While some speakers probably prefer bigger rooms to have a higher number of attendants, there is nothing like the more direct interaction of the rooms in the K buildings. With us sitting on the top floor, we also only had people who were very actively interested in the topics of the graphics devroom.

Despite the fact that FOSDEM has no equal, and anyone who does anything with open source software in the European Union should attend, i always have a very difficult time recruiting a full set of speakers for the graphics DevRoom. Perhaps the biggest reason for this is the fact that it is a free conference, and it lacks the elitarian status of a paid-for conference. Everyone can attend your talk, even people who do not work on the kernel or on graphics drivers, and the potential speaker might feel as if he needs to waste his time on people who are below his own perceived station. Another reason may be that it is harder to convince the beancounters to sponsor a visit to a free conference. In that case, if you live in the European Union and when you are paid to do open source software, you should be able to afford going to the must-visit FOSDEM by yourself.

As for next year, i am not sure whether there will be a graphics devroom again. Speaker count really was too low and perhaps it is time for another hiatus. Perhaps it is once again time to show people that talking in a devroom at FOSDEM truly is a privilege, and not to be taken for granted.

Tamil "Driver" talk.

My talk this year, or rather, my incoherent mumble finished off with a demo, was about showing my work on the ARM Mali Midgard GPUs. For those who had to endure it, my apologies for my ill-preparedness; i poured all my efforts into the demo (which was finished on Wednesday), and spent too much time doing devroom stuff (which ate Thursday) and of course in drinking up, ahem, the event that is FOSDEM (which ate the rest of the weekend). I will try to make up for it now in this blog post.

Current Tamil Status.

As some might remember, in September and October 2013, i did some preliminary work on the Mali T-series. I spent about 3 to 3.5 weeks building the infrastructure to capture the command stream and replay it. At the same time I also dug deep into the Mali binary driver to expose the binary shader compiler. These two feats gave me all the prerequisites for doing the job of reverse engineering the command stream of the Mali Midgard.

During the Christmas holidays of 2014 and in January 2015, i spent my time building a command stream parser. This is a huge improvement over my work on lima, where i only ended doing so later on in the process (while bringing up Q3A). As i built up the capabilities of this parser, i threw ever more complex GLES2 programs at it. A week before FOSDEM, my parser was correctly handling multiple draws and frames, uniforms, attributes, varyings and textures. Instead of having raw blobs of memory, i had C structs and tables, allowing me to easily see the differences between streams.

I then took the parsed result of my most complex test and slowly turned that into actual C code, using the shader binary produced by the binary compiler, and adding a trivial sequential memory allocator. I then added rotation into the mix, and this is the demo as seen on FOSDEM (and now uploaded to youtube).

All the big things are known.

For textures. I only have simple texture support at this time, no mipmapping nor cubemapping yet, and only RGB565 and RGBA32 are supported at this time. I also still have not figured out how to disable swizzling, instead i re-use the texture swizzling code from lima, the only place where I was able to re-use code in tamil. This missing knowledge is just some busywork, and a bit of coding away.

As for programs, while both the Mali Utgard (M-series) and Midgard (T-series) binary compilers output in a format called MBS (Mali Binary Shader), the contents of each file is significantly different. I had no option but to rewrite the MBS parser for tamil.

Instead of rewriting the vertex shaders binaries like ARMs binary driver does, i reorder the entries in the attribute descriptor table to match the order as described by the shader compiler output. This avoids adding a whole lot of logic to handle this correctly, even though MBS now describes which bits to alter in the binary. I still lay uniforms, attributes and varyings out by hand though, i similarly have only limited knowledge of typing at this point. This mostly is a bit of busywork of writing up the actual logic, and trying out a few different things.

I know only very few things about most of the GL state. Again, mostly busywork with a bit of testing and coding up the results. And while many values left and right are still magic, nothing big is hiding any more.

Unlike lima, i am refraining from building up more infrastructure (than necessary to show the demo) outside of Mesa. The next step really is writing up a mesa driver. Since my lima driver for mesa was already pretty advanced, i should be able to re-use a lot of the knowledge gained there, and perhaps some code.

The demo

The demo was shown on a Samsung ARM Chromebook, with a kernel and linux installation from september 2013 (when i brought up cs capture and exposed the shader compiler). The exynos KMS driver on this 3.4.0 kernel is terrible. It only accepts a few fixed resolutions (as if I never existed and modesetting wasn't a thing), and then panics when you even look at it. Try to leave X while using HDMI: panic. Try to use a KMS plane to display the resulting render: panic.

In the end, i used fbdev and memcpy the rendered frame over to the console. On this kernel, i cannot even disable the console, so some of the visible flashing is the console either being overwritten by or overwriting the copied render.

The youtube video shows a capture of the Chromebooks built in LCD, at 1280x720 on a 1366x768 display. At FOSDEM, i was lucky that the projector accepted the 1280x720 mode the exynos hdmi driver produced. My dumb HDMI->VGA converter (which makes the image darker) was willing to pass this through directly. I have a more intelligent HDMI->VGA adapter which also does scaling and which keeps colours nice, but that one just refused the output of the exynos driver. The video that was captured in our devroom probably does not show the demo correctly, as that should've been at 1024x768.

The demo shows 3 cubes rotating in front of the milky way. It is 4 different draws, using 3 different textures, and 3 different programs. These cubes currently rotate at 47fps, with the memcpy. During the talk, the chromebook slowed down progressively down to 26fps and even 21fps at one point, but i have not seen that behaviour before or since. I do know of an issue that makes the demo fail at frame 79530, which is 100% reproducible. I still need to track this down, it probably is an issue with my job handling code.

linux-exynos.org

With Lima and Tamil i am in a very unique position. Unlike on adreno, tegra or Videocore, i have to deal with many different SoCs. Apart from the difference in kernel GPU drivers, i also have to deal with differences in display drivers and run into a whole new world of hurts every time i move over to a new target device. The information for doing a proper linux installation on an android or chrome device is usually dispersed, not up to date, and not too good, and i get to do a lot of the legwork for myself every time, knowing full well that a lot of others have done so already but couldn't be bothered to document things (hence my role in the linux-sunxi community).

The ARM chromebook and its broken kms driver is much of the same. Last FOSDEM i complained how badly supported and documented the Samsung ARM chromebook is, despite its popularity, and appealed for more linux-sunxi style, SoC specific communities, especially since I, as a graphics driver developer, cannot go and spend as much time in each and every of the SoC projects as i have done with sunxi.

During the questions round of this talk, one guy in the audience asked what needed to be done to fix the SoC pain. At first i completely missed the question, upon which he went and rephrased his question. My answer was: provide the infrastructure, make some honest noise and people will come. Usually, when some asks such a question, nothing ever comes from it. But Merlijn "Wizzup" Wajer and his buddy S.J.R. "Swabbles" van Schaik really came through.

Today there is the linux-exynos.org wiki, the linux-exynos mailinglist, and the #linux-exynos irc channel. While the community is not as large as linux-sunxi, it is steadily growing. So if you own exynos based hardware, or if your company is basing a product on the exynos chipset, head to linux-exynos.org and help these guys out. Linux-exynos deserves your support.

For some months our MacBook Air was broken. Finally good time to replace, I thought. On the other side, the old notebook was quite useful even 6 years after purchasing. Coding on the road, web surfing, SVG/PDF presentations and so on worked fine on the Core2Duo device from 2008. The first breaking symptoms started with video errors on a DVI connected WUXGA/HDTV+ sized display. The error looked like non stable frequency handling, with the upper scan lines being visually ok and the lower end wobbling to the right. A black desktop background with a small sized window was sometimes a workaround. This notebook type uses a Nvidia 9400M on the logic board. Another non portable computer of mine which uses Nvidia 9300 Go on board graphics runs without such issues. So I expected no reason to worry about the type of graphics chip. Later on, the notebook stopped completely, even without attached external display. It showed a well known one beep every 5 seconds during startup. On MacBook Pro/Air’s this symptom means usually broken RAM.

The RAM is soldered directly on the logic board. Replacing @ Apple appeared prohibitive. Now that I began to look around to sell the broken hardware to hobbyists, I found an article talking about these early MacBook Air’s. This specific one is a 2.1 rev A 2.13 GHz. It was mentioned, that early devices suffered from lead-free soldering, which performs somewhat worse in regards to ductility than normal soldering. The result was that many of these devices suffered from electrical disconnections of its circuitry during the course of warming and cooling and the related thermal expansion and contraction. The device showed the one beep symptom on startup without booting. An engineer from Apple was unofficially cited to suggest, that putting the logic board in around 100° Celsius for a few minutes would eventually suffice to solve the issue. That sounded worth a try to me. As I love to open up many devices to look into and eventually repair them, taking my time for dismounting the logic board and not bringing it to a repair service was fine for me. But be warned, doing so can be difficult for beginners. I placed the board on some wool in the oven @120 ° and after 10 minutes and some more for montage, the laptop started again to work. I am not sure if soldering is really solved now or if the experienced symptoms will come back. I guess that some memory chips on the board were resetted and stopped telling that RAM is broken. So my device works again and will keep us happy for a while – I hope.

Again this year the thirteen annual Southern California Linux Expo is in the starting block.

During 3 days you will be able to visit us at our booth (38,39,40).
Yeah 3 booths cause we co-run the KDE and Gnome booth.
The exhibition hall open Friday afternoon at 2pm.

Drew and Peter are working as daemon to get everything ready to spread, Doug have brought also quite numerous goodies there. I will do my best to inform you here or follow my G+ channel

Whatever the way you come, bring your feet there and shake hands.
On Thursday, no one has to miss our full day of openSUSE mini-summit, room Century AB.
There will be interesting talks and also a full green hallway, We’re looking forward SUSE’s team, working together in this promising adventure.

On our side Geeko is ready to cross 9.000 kilometers tomorrow.
Hey cool first time in the famous Airbus A380…
Demo laptop with Tumbleweed and KF5 is also secured.

See you all in Los Angeles

I added tray support to all backends of libgreattao(mWidgets). It’s good information, because is was added to console backend too. In mWidgets look&behavior it works in this way.
1. There’s special window class called system tray
2. This window class uses slots. so you can attach windows to tray window
3. This window is not visible by default, but tray icon are special window, that’s don’t looks of parent visibility
4. By clicking on tray icon you change visibility of tray window

Below you have tray class code

<root>
<variable name="root-name" action="change" value="root-window" />
<variable name="true"  action="change" value="TRUE" />
<variable name="false" action="change" value="FALSE" />
<variable name="root-visibility" action="change" value="FALSE" />
<attr-connect name="widget-name" variable="root-name" />
<variable name="is_first_if_processed" action="change" value="FALSE" />
<hide name="root-name" />
<template path="/icon">
<tray-icon dir-for="icon,label">
<handler>
<if type="equal" variable1="root-visibility" variable2="true">
<hide name="root-name" />
<variable name="root-visibility" action="change" value="FALSE" />
<variable name="is_first_if_processed" action="change" value="TRUE" />
</if>
<if type="equal" variable1="is_first_if_processed" variable2="false">
<if type="equal" variable1="root-visibility" variable2="false">
<variable name="root-visibility" action="change" value="TRUE" />
<show name="root-name" />
</if>
</if>
<variable name="is_first_if_processed" action="change" value="FALSE" />
</handler>
</tray-icon>
</template>

<slot spath="/window" />
</root>

First of all we declare variables. We declare additional variables, because there’s no way to compare variable and value. These variables are:

1. true
2. false

We also remember state of visibility our window, because there’s not implemented toggling of visibility. It’s called root-visibility and default it’s false

We also set’s name of window to hide/display this window.

Also there’s additional is_first_if_processed with default value FALSE, because we don’t support else element type. If this variable is set – we don’t sets visibility to true. And, of course, we sets this variable to FALSE after checking it’s true, so there’s no way to hide/show icon permanently.

dir-for in tray-icon(template of path /icon) attach icon and label of /icon template to our tray icon.

Handler element is attached to default signal of icon and it depends on backend. In most cases it means click event.

Now, let’s look how good programmer you are? How do you like to optimize this file? It’s simple – by moving setting default value of is_first_if_processed before first if element(as first child of handler) and removing element after second if, but I’m not very good in programming, so I don’t seen it before writing this article.

And how writes application using tray icon in libgreatao? It’s simple. There you are code:

#include
#include

void *main_window;

void destroy_main_windopw(void *mesh1, void *mesh2)
{
tao_release_window(main_window);
tao_close();
}

void init_main_window(void)
{
struct tao_image *img;
struct tao_icon_set *iset;
main_window = tao_new_window("/system/tray");

tao_add_handler(main_window, "/:abort", destroy_main_windopw, 0);
img = tao_load_image("internet-indicator.png");
if (img) {

iset= tao_new_icon_set();
tao_add_image_to_icon_set(iset, img);
tao_add_handler(main_window, "/icon", NULL, 0);
tao_set_hint(main_window, "/icon", 3, iset);
tao_set_hint(main_window, "/icon", 0, "Network Management");
}
}

void add_to_main_window(void *window)
{
tao_attach_window(main_window, "/window", window);
}

int main(int argc, char **argv)
{
tao_initialize("tao-network-manager", "", &argc, argv);
init_main_window();
tao_handle_events();
}


Code inserted below load icon and on success add tray icon to our tray window:

img = tao_load_image("internet-indicator.png");
if (img) {

iset= tao_new_icon_set();
tao_add_image_to_icon_set(iset, img);
tao_add_handler(main_window, "/icon", NULL, 0);
tao_set_hint(main_window, "/icon", 3, iset);
tao_set_hint(main_window, "/icon", 0, "Network Management");
}


tao_load_image load image on path given as first argument. We can’t attach single icon to icon element – we must create icon set and attach icon to icon set. In next step we attach icon set tom tray icon. It’s because giving possibilities to provide icons with different size and libgreattao will select the best icon to view.

That’s all!

At the end of the last week we released the new version of LibreOffice Viewer for Android, and I must say, it is a pretty solid release. The app is still in Beta, and some problems (like occasional crashes) should be anticipated, but overall there have been so many stability improvements that I am confident that it's now very usable for daily work.

New components

How does the Viewer look from the technical point of view?  It is the complete LibreOffice that we use on the desktop, but cross-compiled to Android, stripped down to its bare bones, and accessed from the Java part via LibreOfficeKit to provide rendering of 'tiles' -- 256x256 bitmaps that together compose what the user views as a document.

Spot the problem in the above description? "Stripped down to bare bones".  When we initially released, some hard compromises were made, which led to many documents crashing. Did that document contain a drop down box? Ouch! How about a custom shape? Ouch! You get the idea.

To address that, I used the same approach that Markus Mohrard is using for import and export crash testing.  I have collected over 55,000 documents - not so far from the 75,000 that we test with desktop LibreOffice. I discarded documents that were not applicable to the Android Viewer, stripped down the desktop application the same way we are stripping the LibreOffice core that is on Android, and let the tests run for several days.

Based on the output, I have added all the necessary services for text documents; so crashes due to missing components should now be rare.

Documents that remain difficult

Some documents internally provide bindings to features that are intentionally left out of the Android Viewer; namely functionality relating to databases. These documents are still missing the components described above, and thus unfortunately still crash.

We could theoretically add those services too; the problem is that currently we are hitting the 50M .apk size limit that Google imposes on Play store apps.

But don't worry - we have several tricks still up our sleeves. We'll work on them in the following weeks, and eventually include more of the services that are still missing.

More stability improvements

Intents for documents opened from Gmail:  opening documents directly from GMail now works nicely. This was an important use case that we missed in the initial release, and we caught it thanks to the feedback of the users using the Viewer.

Several smaller things have also been fixed, like presentations used with Notes view now switch to the presenting view. We also added preset shape definitions, so .docx files with preset shapes now display nice images.

And finally, we improved recovery from failure -- previously, when the document failed to open, the subsequent open of a document lead to a crash; not any more.

Overall, while the latest LibreOffice Viewer for Android is still a Beta release (and the usual warnings apply), I'm confident it's a really good Beta. Many thanks to Miklos Vajna and Tomaž Vajngerl for their hard work!

Install LibreOffice Viewer Beta from Google Play and enjoy!

The Oyranos library became quite slower during the last development cycle for 0.9.6 . That is pretty normal, as new features were added and more ideas waited for implementation letting not much room for all details as wanted. The last two weeks, I took a break and mainly searched for bottlenecks inside the code base and wanted to bring performance back to satisfactory levels. One good starting point for optimisations in Oyranos are the speed tests inside the test suite. But that gives only help on starting a few points. What I wished to be easy, is seeing where code paths spend lots of time and perhaps, which line inside the source file takes much computation time.

I knew from old days the oprofile suite. So I installed it on my openSUSE machine, but had not much success to get callgraphs working. The web search for “Linux profiling” brought me to a article on pixel beat and to perf. I found the article very informative and do not want to duplicate it here. The perf tools are impressive. The sample recording needs to run as root. On the other hand the obtained sample information is quite useful. Most tools of perf are text based. So getting to the hot spots is not straight forward for my taste. However the pixel beat site names a few graphical data representations, and has a screenshot of kcachegrind. The last link under misc guides to flame graphs. The flame graphs are amazing representations of what happens inside Oyranos performance wise. They show in a very intuitive way, which code paths take most time. The graphs are zoom able SVG.

Here an example with expensive hash computation and without in oyranos-profiles:

Computation time has much reduced. An other bottleneck was expensive DB access. I talked with Markus about that already some time ago but forgot to implement. The according flame graph reminded me about that open issue. After some optimisation the DB bottleneck is much reduced.

The command to create the data is:

root$ perf record -g my-command

user& perf-flame-graph.sh my-command-graph-title

… with perf-flame-graph.sh somewhere in your path:

#!/bin/sh
path=/path/to/FlameGraph
output=”$1″
if [ "$output" = "" ]; then
output=”perf”
fi

 

perf script | $path/stackcollapse-perf.pl > $TMPDIR/$USER-out.perf-folded
$path/flamegraph.pl $TMPDIR/$USER-out.perf-folded > $TMPDIR/$USER-$output.svg
firefox $TMPDIR/$USER-$output.svg

One needs FlameGraph, a set of perl script, installed and perf. The above script is just a typing abbreviation.

In this article I would like to explain elementary way to create custom SecretAgent for NetworkManager. Program will communicate via DBus with NetworkManager. It would give password prompted by user, when NetworkManager asks for it. Once NetworkManager asks for password, my program will show dialog with name of wireless network and question about password. After giving password, program will send it to NetworkManager, so connection could be established.

Program will be very simple and don’t support all features of NetworkManager. Firstly, it don’t remember passwords prompted by user. Secondly, it don’t return error, when error occurring. It only supports one method of SecretAgent interface – GetSecrets.

Let’s start at beginning

What DBus is?

Dbus is service of modern GNU/Linux distribution. It allows processes to communicate. It supports sending messages process in the same session and registered as system service(or kernel service). We would like to use system service called NetworkManager.

DBus is object-oriented. It supports methods, signals, properties. All these thinks are assembled to interface, interfaces are assembled into paths and paths are grouped to objects(ex. services).

What NetworkManager is?

NetworkManager is system service, which storing connections settings and supports connecting to networks.

For purpose of this article, we will use org.freedekstop.NetworkManager(at this name NetworkManager is spoken), /org/freedesktop/NetworkManager/AgentManager paths and org.freedesktop.NetworkManager.AgentManager. We will use these thinks only for Register method. We will also implements method GetSecrets of org.freedesktop.NetworkManager.SecretAgent interface.

Which will be connected with our project?

Our program will use libgreattao. We will write one single application to rule all desktop environment, virtual console and shell.

Let’s go!

Firstly, we need to initialize libgreattao. To do this, we will call tao_initialize, giving program name(mandatory) as first argument, help text as second, pointer to argument’s count(mandatory) as third, as fourth pointer to array of char’s array(mandatory).

Next step is connecting to system bus of DBus. We will achieve this by step displayed below:


bus_connection = dbus_bus_get(DBUS_BUS_SYSTEM, &error);

But firstly, we need to declare two variables. First is called bus_session and it should been declared in global scope. Second is called error and it should been declared in main function scope.


DBusConnection *bus_connection;


and


DBusError error;


We must, also, register to AgentManager. We can done this by invoking Register method of org.freedesktop.NetworkManager.AgentManager, which can be found at path /org/freedekstop/NetworkManager/AgentManager, which is handled by object org.freedekstop.NetworkManager

  DBusMessage *msg;
  DBusError bus_error;
   
  msg = dbus_message_new_method_call("org.freedesktop.NetworkManager",
      "/org/freedesktop/NetworkManager/AgentManager", "org.freedesktop.NetworkManager.AgentManager",
      "Register"
    );

After creating a message, we can attach an arguments to it. Register catching one argument – agent’s identificator. It has string type and containing from 3 to 255 characters, but without colons. In our application it will looks like below:

const char *service_name = "org.taolib.nmpassword";

Below is displayed, how attach arguments to message:

dbus_message_append_args(msg, DBUS_TYPE_STRING, &service_name, DBUS_TYPE_INVALID); 

DBUS_TYPE_INVALID points, that there’s no more arguments. It’s obligatory!

At we face to face with most important part of DBus based programs – sending messages and waiting for replies:

dbus_connection_send_with_reply_and_block(bus_connection, msg, -1, &bus_error);
 
if (dbus_error_is_set(&bus_error)) {
   
  show_message_and_abort(bus_error.message);
}

I won’t introduce body of show_message_and_abort function. It doesn’t contain DBus related code. You can see, how it works, by looking at sources. Minus one meaning very long. I don’t know how order this function to wait infinity, so I give them maximum(for x86) value as unsigned int. Function dbus_connection_send_with_reply_and_block will waits for reply message omitting everything else(other messages will waits in poll).

Please, don’t forget about initializing error structure, called bus_error. At the end of our function, we will freeing error message:

dbus_error_free(&bus_error);

At now, we need add support for org.freedesktop.NetworkManager.SecretAgent interfacve. First step is give information, we were listening on this interface. Entire duty is closed in add_signal_support(I know name was misleading):

char *buffer;
int length;
DBusError error;
 
length = sizeof("interface=''")
            + strlen(interface);
buffer = (char *) malloc(length);
 
snprintf(buffer, length, "interface='%s'",      
     interface);
dbus_error_init(&error);
 
dbus_bus_add_match(bus_connection, buffer, &error);
 
if (dbus_error_is_set(&error))
{
     show_message(error.message);
}
 
dbus_error_free(&error);
 
free(buffer);

In first step we counting amount of required space for allocating buffer for character array for dbus_bus_add_match function. Sizeof will return size of character array(including character of code 0, so we don’t plus one). In second step we fill array of characters, using snprintg. In next steps we initializing error, invoking dbus_bus_add_match, checking for error occurrence.

In this moment we do most important thing – create a timer. This timer will be calling messages handling function with 100 ms interval.

timer = tao_add_timer(100, (void (*)(void *))nm_dbus_loop, (void*)bus_connection);

Timer like libgreattao windows are pointers of void, because they aren’t suspected to being used by application. Our message handling function is calling nm_dbus_loop. It looks like below:

DBusMessage* msg;
struct password_prompt *prompt;
void *window;
 
  dbus_connection_read_write(bus_connection, 0);
  msg = dbus_connection_pop_message(bus_connection);
   
   
  if (msg) {
    window = NULL;
     
    if (dbus_message_is_method_call(msg, "org.freedesktop.NetworkManager.SecretAgent", "GetSecrets")) {
     
  prepare_return_secret(msg, &window);
    }
     
    if (!window) {
     
  dbus_message_unref(msg);
    }
  }

As second argument of dbus_connection_read_write we give 0. What that meaning? It means that this function won’t block. This function are only decorator – you can remove it and I forget about this. This function can be used to detect bus connection broken, because in this case returns FALSE.

We retrieve message(NULL means no message in poll) to check this is not invocation of our DBus method. In next step we check password prompt is created – if not, we remove message. In other case, message are necessary to get network ssid and to create response message.

At now most hard thing. We must read ssid of network and question flags. NetworkManager are sending question flags, which in example inform that keyring can be interactive(communicate with user).

First argument of our DBus method is network settings, second is configuration path(not as a file – it points to path in NetworkManager). Third and fourth arguments are not known to me – I don’t use it. The last argument is flags.

At the beginning of our function we declare some variables:

DBusMessageIter container, item, a, character, b;
int buffer_position;
char buffer[1024];
char ok;
char *key;
struct nm_settings *prompt;
unsigned int flags;

DBusMessageIter are iterators. It remembers on which argument we do last action.

First, what we doing is setting first iterator to first argument. It hast array type, so we will checks elements of this array. We called dbus_message_iter_recurse(&container, &a); In next step we checks elements of current element. It was caused that this table are dictionary and dictionary contains elements of type DBUS_DICT_ENTRY. This kind of elements assembles two elements – key and value. We are searching string 802-11-wireless for assign dict-value to iterator called item. In next step, we are searching for string ssid for setting iterator to value of dictionary. The case is very complicated – ssid aren’t stored as string, but as variant of array of bytes. We need to call recurse twice.

if (strcmp(key, "ssid") == 0) {
     dbus_message_iter_next(&a);
     dbus_message_iter_recurse(&a, &b);
     dbus_message_iter_recurse(&b, &character);
      
     buffer_position = 0;
     do {
   dbus_message_iter_get_basic(&character, &buffer[buffer_position]);
   ++buffer_position;
     } while (dbus_message_iter_next(&character));
   }

Each retreived byte we add to our buffer. In next step (ssid) we checks that ssid was retreived correctyly. If not, we exits from function.

To obtain flags(the fifth argument), we need to call recurse two times. If first org second flag are set, the NetworkManager allowed to communicate with user. In other case, we exits from function.

At the end of function, we create new window and sets window variable to newly created window.

Most interesting thing is, what cause, when user type password. In this case return_secret will be called.

Return_secret function acts as mirror of previous function, because it create message, so it calls dbus_message_iter_init_append instead of dbus_message_iter_init. Both function’s signature’s are identical. Only difference is in behavior – dbus_message_iter_init_append will write arguments instead of reading them. We will also use dbus_message_iter_append_basic – we will use this function to writes strings. We need also dbus_message_iter_open_container, which are mirror function of dbus_message_iter_recurse. Signature in DBus are character’s array. We create signature by calling dbus_message_iter_open_container.

dbus_message_iter_open_container(&container1, DBUS_TYPE_ARRAY,
                     DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
                     DBUS_TYPE_STRING_AS_STRING
                     DBUS_TYPE_ARRAY_AS_STRING
                     DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
                     DBUS_TYPE_STRING_AS_STRING
                     DBUS_TYPE_VARIANT_AS_STRING
                     DBUS_DICT_ENTRY_END_CHAR_AS_STRING
                     DBUS_DICT_ENTRY_END_CHAR_AS_STRING, &container2);

Third argument is part of signature. Our function will return array of dictionaries, which key as string and value as dictionary. Inner dictionary are assembled with string as key and variant as value. We will set content of variant by string. In this way settings in NetworkManager are stored and our application must follow that way.

After filled of container, we must close it. Strings are not assembled type. We will use dbus_message_iter_close_container, which waiting for pointer to initialized iterator and pointer to iterator. First argument are parent iterator and second are child iterator.

As a result of calling our function, we will retrieve:

[{"802-11-wireless" => [{"security" => variant("802-11-wireless-security")}],  "802-11-wireless-security" => [{"key-mgmt" => variant("wpa-psk"), "psk" => variant(our_password)}]

I must mentoin, that variant are used to storing variables of different kind.

Please, remember about downloading latest version of libgreattao. Instructions about how do this, you can find on SourceForge.

Code of application you can download from:
My home site

In preparation are applet for connecting with networks. It also uses libgreattao. Currently libgreatao doesn’t support tray.