 Hello. I'm going to talk about LibratBug, which is a demand to configure input devices. So, my name is Philippe Lange. I like beer. I'm a student. I'm one of the maintenance of LibratBug, and I package some stuff for Arch Linux. So, the table of content, I'm going to explain a bit better what is LibratBug, then I'm going to talk about the current status, what we have planned for the future, and a really, really quick overview of the IT protocol, then how you can define your own LibratBug driver, then some questions. So, what is LibratBug? LibratBug is a debossed demand to configure the order of input devices. So, for example, some iron devices like this one, you can change the sensibility and other aspects of the order. But they often, the manufacturer often only provides official drivers for Windows, and sometimes maybe Mac, but never Linux, really. So, if you buy an expensive mice like this one, you want to be able to change the settings, and that's what LibratBug allows you to do. We are vendor agnostic, so our API is not tied to any particular vendor, so you can define your own driver for any mouse, or any other input device, and have it work. So, right now, we mainly support Logitech, because they actually use a standard protocol between all of their devices, so it's really easy to not necessarily maintain, but to have the same code work for different models, while other vendors like SealSeries have a different protocol for each hardware, so it's a bit of a mess. And LibratBug was created in 2015 by Benjamin Tissouar, who is one of the maintainers of the ETH sub-tree of the kernel, and Peter Atherer, who is the maintainer of LiveInput, and most of the Linux input stack. So, what can you configure with LibratBug? So, you can change the resolutions, so the DPI settings, you can change the report rate, you can remap buttons, you can do hardware macros, and you can change the effects of the LEDs. So, for clients, we currently have RadBug CTL, which is a CLI client, but it's mostly intended for debug, and we have Piper, which is a GTK client, which is intended to be a proper client for end users. So, the status of LibratBug, it works, you can change all of the settings for the supported devices, but we don't have a stable client API yet. So, because of several issues, like we have limited time, we don't want to define a stable API yet, because if we do it, we will have to maintain it, and we hope to be able to do it soon, but it's not there yet. So, the issues that we currently have with LibratBug, like I said, we have limited time, we don't have that many maintainers or that many contributors. Most of the people that contribute to LibratBug mostly make their device work and don't really contribute to the rest of the code, so you can have some part of the code for some device that works perfectly fine, but for other hardware, it can be a little bit buggy because the people that contribute to that code are not that active. So, one of the issues is it can be automated. So, some of the code, if you don't have some previous knowledge of the IT protocol, which is the protocol used by input devices, it can be a little bit complex in some parts, but you usually have to delete it. We, me and the other maintainers have to delete it, and I think the most important thing is that we have limited access to hardware. So, I do not own all of the hardware that we support and neither do the other maintainers. We have, between all of us, I think we have a good portion of the hardware, but we don't have all of it and that can really prevent us from fixing stuff because we don't have the hardware. So, about the future, we want to set up a CI, but to test the hardware drivers, because they communicate with hardware, we need the only way for us to test them is actually emulate the hardware. Otherwise, we don't have any way to, we will have to have like a physical CI, which is not great because, like I said, we don't have all of the devices and it's hard to maintain. So, what we want to do is to have device simulation. So, this summer, Logitech was kind enough to give me an internship where during the summer I worked on open source software and one of the main projects of the internship was to create a device simulator. So, right now, we have a device simulator that works. We have a prototype and we have a prototype CI for the bad boy, but it's only prototype. I am rewriting the device simulator. It should be ready soon. So, hopefully soon we will have like a proper CI that can emulate all of the hardware, even if we don't have it and can actually make proper regression testing, make sure that new changes don't break existing code and things like that. One other thing I wanted to play around with is color synchronization. So, for example, if you have a device like a mouse and a keyboard, you could actually have the light effects sync up between them or if you have like other kind of devices that we could support, you could have everything nice and synced up, have the same color effects between everything. So, I'm going to talk just a little bit about it protocol. The protocol is by input devices. This is supposed to be like just an entry point for people that want to understand how these input devices interact with the computer and how they operate and on top of that, how the protocol to configure these devices relates to that. So, you have advice. This is one of the most common examples. For example, you have a mouse and every time the hardware changes, the hardware state changes, you send a report to the host telling, okay, so I moved X dots in the X axis. So, but the it protocol is designed to work with all kinds of input devices and they have different hardware properties. So, we cannot have like a standardized report structure. So, the package that the device sends to the computer to tell it what changed in the, sorry, to tell it what changed, it cannot be standardized. Otherwise, we will have like a really, really big packet because we need to send everything that is possible. So, to prevent this, it's a protocol defined report descriptors which are basically structures that describe how the packet is structured. So, for example, in this simple example, you have a mouse and every time the hardware state changes, it will send three bytes to the host updating the state of the button. For example, in this case, the button's byte is just a bit mask. Every bit represents one button and then you have your two axis. But the protocol cannot really be, it's not broad enough to be able to define all of the things that you could be able to configure in your device. For example, the sensibility or some other crazy things that the vendors might want to do. So, they allow you to define a certain part of the packet as just vendor data. So, in a more complex event, you could have a report descriptor that says that the packets start with one, send the basic mouse hardware updates and the reports start with two, just send vendor data. And at this point, the eDriver, the generic eDriver will just ignore this data. It knows what to do with that one, but it will ignore the vendor data. And then you can have a vendor driver to deal with that data. And that is what Librat Pack does. We interact with the vendor data. So, every vendor will have a protocol inside this vendor data, a way for us to configure the devices and talk with the devices using this vendor data. In Linux, you have two ways to interact with the vendor data. You can have like a kernel driver, but that's not really a great solution. You really only want to do it if you need access to that data somewhere inside the kernel. The most common example is the battery reporting. So, you can have the battery reporting show up in CZFS and then if you power, pick it up and report it natively. And for that, you could do a kernel driver. But for all of the other things, like configuring the LEDs and things like that, you don't really want to do a kernel driver. You can do it in the user space. So, the kernel will export a Dev, eDraw device, which is a device that just sends the raw data to the, which is a file descriptor that only sends the raw data to the device. So, in Libre back, to write your own driver, you basically create a new file and you define some functions and then you define this structure. The structure can vary a bit, but for most cases, you want to define a probe method, which is every time you update something, some setting, it will be called, sorry, no. The probe method is the first time that you connect a device, then you have a remove method that is, when you remove the device, then you have the commit method that is, every time you update some setting, it will call that method and usually what you do is just to take that, to send, to tell the device to be configured in that way. So, if anyone has questions, I can answer. Otherwise, I can show you a demo. I don't know if, you know. With the current status of programming the internal memories of some devices? OK, the status of programming the memory of the some devices. So, most of the devices don't really allow you to interact with that because they just, the firmware only, the thing is that, sorry. So, you have the device that is connected via USB or something and you have the IP protocol on top of it. It doesn't, most of us don't really have a way for you to interact with the memory. For example, Logitech devices, Logitech devices particularly with onboard profiles actually export like emulated memory where you can store stuff. It is used to store like macros in more recent devices like some custom led effects. In those devices, you can actually, using the vendor protocol, you can write to some part of the memory and you can do some stuff with that. But most of us don't really allow you to interact with the memory. It's basically you just, most of us only have like really simple comments that you say, OK, set the led to the color red. And then the firmware receives that message and interprets it and there's that, the led to red. I don't know if I answered your question properly because most of us don't really allow you, there's no interface to write directly to the memory because after all, this is just an MCU where I'm running some firmware that will just get the updates from the sensor and then create some it packets with the updated state and send it. So you can only do what the firmware allows it to do. I mean, in some devices, you can actually open them up and reprogram it, but that's a bit out of the scope. I mean, anyone else? Is the broadband only supporting HID devices? Like, if I, well, I do have a mouse where I reverse engineer the protocol, but it's not long, it isn't HID. So should I write a kernel driver to evaluate an HID device? I mean, I don't think you should, sorry. OK, you are asking if you have a mouse that allows you to configure it but doesn't export an HID device. So in that case, I don't think you should write a kernel driver. Right now, all of the devices that we support are HID devices. But I don't think that we need to do that necessarily. I mean, we have to talk with the other maintainers, but we might want to have that in LibreDbac because after all, it's just a demon that takes your device and exports some settings, so resolutions, some part rates, lead effects, things like that. And your device matches that profile. Anyone has any questions? Do you have to use RatBagD to get stuff done, or can you just write something using LibreDbac to go and configure devices correctly via HID? OK, so do we need to use the RatBagD, which is the demon, or can I just use LibreDbac to do what I want? It's kind of deprecated. And we just merged the demon and the library. And right now, we only publicly support the demon because I was not involved with the project when that happened, but I think it was because it was hard to maintain a public API for the library because it was in constant development, so they didn't really want to maintain a public binary API. So I think that's what happened, but I'm not entirely sure. Anyone, any questions? I can show you a demo. So I'm going to connect this mouse. I forgot the receiver, but I can connect it directly. So, OK, my device shows up. Then I have resolutions. I can change that. I can run up buttons. For example, I think one of the most important things is, for example, if you are left-handed, so you want to switch the two main buttons, if your mouse is part of the remote bag, you can just go here. But it will just probably this interface where you can just do it. Then it's run up. Then you click Apply. And now the buttons are mapped. I need to use the other button. Yeah, OK. So then we have the LEDs. So I can just put this orange. Now let me show, if I click Apply, it will go orange. OK, it went. Yeah, that's basically it.