 Good morning, thanks for coming. My name is Timo. I'm working for the mobile device team at Susan. And I'm going to talk a little bit about the kernel, UDF, DivaSpawn, network manager and how everything is connected. So, as it works and what I'm talking about. First of all, I will give a short overview about the events which are passing through all steps. So, I'm basically focusing on events, not about interfaces. And I will give a small example on the event flow through the whole step. And afterwards, I will give a short introduction on how to analyze and solve problems within the stack. And for that, I have a small application, the event monitor, which gives you a tool to gather all the events from the different sources. So, today we are talking about the events, not about the interfaces, like the SysFS or ProcFS interfaces. We are just focusing on the events from the different sources and maybe signals, which are basically the same. Whenever you are loading a perm module, you will get a lot of events. You don't see them, but they are there and they are helpful if you want to debug something. So, typically, we have several components in our stack. It's the Neon Scarlet at first. A sub-component of the Scarlet is UDef, which is basically the device manager, which creates the device nodes in slash depth. But it also reports a lot of events, so it's a very interesting and very big event source. Then, if we are focusing on the user space side of things, we have the transition from the UDef events, which are passed to the hoarded demon. This is using gbust. Also, the rest of the user space is shifting towards using gbust. They don't use any special software anymore, so it's almost everything about the events, which are interesting. It's now using gbust, like network manager or other system teams. Also, within the desktop, we have a lot of events. I'm not sure whether you have watched gbust traffic on the session bus, for example, if you're running an instant messenger. There are a lot of messages going across the bus. So, for example, the event flow, whenever you are loading a perm module, it issues a lot of chaotic UDef event calls, which result in a new event, which is passed from UDef to the UDef demon. So, that's the transition from color space to user space using an abstract socket. Those events will then be transferred into new signals issued by Horde, and those events are then being emitted on the eBus system bus, which will end up in applications, which has really registered them. And a handler for the device added methods, for example. Here we have a picture on the whole stack of the drawn one. We have the hardware on the bottom, which is controlled by the corner. I will talk about that later. So, we have the kernel, which talks to the hardware. Then we have the user space stack, and the active components are the blue ones. The eBus is a huge part of it, but it's just a passive component because it's just an inter-process communication primitive used by all of those components. So, the first part I'm describing is if you plug in the USB stick, for example, it gets loaded the module for the USB drive, for example. You get the UDef event, which passed the UDef demon, and then are transmitted to Horde. For example, the device you just plugged in was an Ethernet or wireless card. We will then receive more events because one of the events will pass all and then go to the desktop environment and applications, and some events will first pass to network manager and then to applications because some applications might just be interested in the network manager signals and not the Horde signals, so they just receive those events and not those from Horde. So, that's a big picture. That's not the only event path. For example, if you have input events, they don't get through the stick because it's a device driver sitting in the kernel, and you read from the device interface, so it's passing to the regular stack I'm showing here. It's just an example for a very common way the event passes through the whole stack. Now, we have a lot of different components. Debunking is quite difficult because you have a huge stack with, I don't know, five, six components and you are not getting a feeling for how the events are going through the stack, so you need some money toss to get the events out of the components and analyze them. So, a common use case where things might go wrong is the odd keys for changing brightness. To analyze something like that, you can simply divide into three steps. First of all, you have to make sure that your hardware is supported by some driver of the kernel. So, this is the first question. If you can answer this question with, yes, I've got a drive from the system, you then have to look whether the interfaces of the driver are working when you control them manually. So, if the odd keys are not working, that's probably just an issue about the events because they don't end up in the right components of the stack, but the actually support from the trial is working because if you just echo something in sys-class, backlight, it works. So, if you make sure that the trial is there and the trial is working, then you have the problem, okay, some events might be stuck somewhere within the stack and you have to track it down. So, for my computer, I've got the Sony laptop which is supported by Sony laptop driver. I'm pretty sure that it is supported. So, I check whether the interfaces are working and those are working as well. But, for example, if I'm pressing the odd keys for changing the brightness, it doesn't work. So, there's no edge and I can see. So, that must be something in the whole stack which goes wrong. And, yeah. So, to solve the issue, I have to identify the event sources, first of all, which are connected to the problem. So, for this problem, it might be interesting to receive events from UDF, but that's basically only interesting if the trial is not working correctly, but it is, so that's not that interesting. It's interesting to watch the messages which are going across the system bus because it's being used by all, for example. And, it's also interesting for the odd keys at least to check whether the events are going through the input layer. So, that's the things I will have to debug to get it working. Because it might be a pain to run several applications, there are event monitors for each source, like the UDF monitor for UDF events. You can run LS Hall in the monitor mode to get the Hall event. And, you can also run D-Bus monitor on the system bus and session bus to get the events. So, we end up like having five or six terminals. And, you see about events, you don't see the sequence of the events, it's just a little difficult to analyze. So, I will be in the program just for today, a little demo application. Just a few lines, of course. It's using Python, Python, D-Bus and GDK for a Graphical Use interface. I've created several monitors for each of the events source, like UDF Hall, Network Manager and the Interplayer. And, those modules just read, they're pretty dumb, they just read the events. And, once there's an event on one of the event sources, they just send out a notification to the desktop. So, it's just very convenient to have a look whether there's any activity. It looks like that. It's very, very small. I already put the source online. You can have a look at it, even if you don't do anything with Python, you will understand the code because ten lines for the UDF monitor, they are just pretty straightforward. Also, for Hall, it's just 15 lines of code. I use subclassing to implement the monitors. So, whenever somebody says, okay, it's got another event source, I want to integrate it, you will also only need a few lines of code to get it working. Let's have a look at the application. It's one tool for all events. It's very easy to use, you just have it and have a look whether there's an event. And, it's not intended to be a drop-in replacement for the other utilities, which are used for monitoring the event sources. That doesn't make sense. I just wanted to give a technical user who might be interested in solving issues by himself a little tool for investigating without reading too much stuff. So, the application looks like that. We have, that's just a little menu here in the bottom panel. We have the four modules I previously told you about. So, whenever the UDef listener receives an event, which sends out the UDef event with the Penguin as an icon, the Hall events can be identified by the 3Def support icon and the input layer gives just a keyboard as a notification. Yeah, so, I can show you the results in life. So, I've prepared a little demo. My problem is now that actually the display is off. And I can switch it off. So, I have to prove you that the brightness is not working by pressing the keys. You can just have a look at it. So, it's flash, backlight, Sony, cut, brightness. So, it's at 7 now. And, if we echo like 3 into brightness, it's working if I don't use the email. But, if I press the brightness keys, there's nothing happening. So, I'm pressing now brightness up two times. And we have a look at brightness. It's still at level 3. Nothing has changed. So, let's investigate. This is the demo application. Look, we have monitors. We can enable and disable them. So, we don't need the network manager module for now. So, I'm now pressing the brightness up button. And, okay, we get an event. Let's have a look at the brightness. It's still at level 3. So, we get an event, but the event doesn't trigger anything. But, the event itself, it has no reaction in the screen. What I'm knowing now is that I've got an instance of no power manager running. And I'm just knowing that no power manager adjusts the brightness whenever it receives the brightness up or down event from all. So, the whole monitor is active, but I don't see any whole event. So, there might be something wrong with all. We can check that. For example, running an S5 is a lot of system information. And, if an input device has some strange input events like the one from the Sony laptop driver, you need a key map to define the matches for the key codes. And, I think that we have no key map loaded. We don't. So, let's see what's happening if we have a fixed one. Looks like something like that. So, that's already the fixed version. We have some system definitions over here. And, my system is the last one. So, the definition was missing. Because of that, we didn't get the key map data into all. So, if I copy this over to the FDI first, I'll have more FDI information. Ten, three, four, five, six, seven, eight. So, I'm not used to it. So, we're happy. And now we're starting more. It reloads the FDI data. And, we can check whether now we have a key map loaded. Oh, there is some. So, we see that we have key map up for the Sony network loaded. And, we are now monitoring the... So, we are still at level three. Now I'm pressing God keys and have a look for the notification we are getting. So, now we are getting two events. We get one event from the input layer, and we also get another event from Hall. So, the event was only transmitted to the input layer, but also to Hall. And, for that, also to Non-Power Manager. So, we now look at the display parameters, we see that it has changed. So, it's working now. So, that's pretty nice to debug. But you pressed twice. How many? You pressed twice. Did I? Yeah. How come the messages come up out of order? How many? How come the messages come up out of order? You get the Hall event and then the key press. No, I don't think so. It's the first one that's the second one. It's the second one. I can assure you that it's not the other way around. Put the magic. So, yeah, that's pretty much everything I wanted to show. Thanks for coming. Any questions? Yes, please. What is also the case for... I have a mouse that's not working. I see the events in that input, but I don't see the mouse movements. What is also related to this? The mouse movements... I don't know. I've connected the telephone before as an input device, and you see the mouse presses. So, yes, if you are debugging the mouse buttons, you will see whether those are reported by the input layer. Let's trust him whether the buttons are supported or not. But that's pretty much all you can do. So, there's nothing more you can do to get the button supported. Second question. If you have a network card and it has some megabits, and it changes, how do you trigger that the network card gets remapped? For instance, if you run Susie on the Xenon, you have some network megabits, and now you've changed it, and you get that ETH, how do you get ETH 0 and then ETH 2, and you want to read... That's not UDAP. It's UDAP. We have to fix UDAP rules for that. And how do you trigger that again, that it remaps it? You probably just echo 1 to the UDAP in the device part in the Susie pass to remap the UDAP. Echo 1, 2, 3, 4. Two questions. First, will your monitoring tool be able to print to a log file? Do you want to debug the very early boot sequence? No, I don't think so. What I was thinking about was having a system monitor with a regular user interface so that you can sort of lock the events with the sequence, but starting it early, monitoring the events, it would be possible. It would be hard, yes. I can think about it. If it was hard... The boot system, it would be a lot easier to put it in the front of the boot. Yes, it would be easier. Another question. It seems to be a GNOME applet. Can it also work in KDE? If you just drop the file and go back to the GTK code and replace it with a QT code, it won't work. Thanks a lot.