We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback
00:00

Formal Metadata

Title
libratbag
Subtitle
A way to configure your input devices
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This talk will give an update on the progress being done in libratbag as well as present the new projects we have planned. If there's time I will also show how you should be able to write your own driver and debug existing drivers. This is a talk about libratbag updates, planned projects and a code demo.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
outputConfiguration spaceFingerprintStudent's t-testSoftware maintenanceData structureDevice driverCommunications protocolTable (information)Content (media)DemonComputer hardwareKernel (computing)Series (mathematics)Image resolutionExplosionBit rateMacro (computer science)Event horizonLogicGoodness of fitDifferent (Kate Ryan album)Student's t-testEndliche ModelltheorieState of matterRight angleLine (geometry)Order (biology)WindowSet (mathematics)outputTraffic reportingDevice driverStack (abstract data type)Software maintenanceBitSound effectCodeCommunications protocolTable (information)Device driverComputer hardwareComputer animation
Client (computing)Common Language InfrastructureClient (computing)Proper mapPlanningComputer animation
Client (computing)Complex (psychology)Computer hardwareContinuous integrationSynchronizationEmulatorDemonPrototypeSoftware maintenanceComputer simulationProper mapLinear regressionoutputComplex (psychology)MathematicsComputer hardwareProjective planePrototypeCodeGraph coloringOpen sourceSet (mathematics)Stability theoryMereologyBitControl flowSound effectClient (computing)SynchronizationCommunications protocolPoint (geometry)FamilyLevel (video gaming)Principal idealCategory of beingCoefficient of determinationMultiplication signSoftware testingKeyboard shortcutComputer animation
Interface (computing)outputCommunications protocolExplosionFile formatTraffic reportingCommunications protocolData structureMultiplication signState of matterComputer hardwarePoint (geometry)CASE <Informatik>BitDot productDifferent (Kate Ryan album)Standard deviationoutputNeuroinformatikInteractive televisionFamilyNumberCategory of beingEvent horizonMathematicsRight anglePhase transitionComputer animation
Message passingExplosionCartesian coordinate systemCommunications protocolStrutDevice driverDevice driverFunctional (mathematics)Sheaf (mathematics)CASE <Informatik>Moment (mathematics)Computer programmingSemiconductor memoryBit rateRight angleBucklingNeuroinformatikMultiplication signGradientImage resolutionTraffic reportingPower (physics)Device driverSpacetimeSinePersonal area networkLogic gateMereologyBitAnalogyParticle systemExpert systemCAN busSpecial unitary groupDemonSet (mathematics)Data structurePoisson-KlammerEvent horizonPoint (geometry)Graph coloringSound effectOrder (biology)MeasurementMessage passingFirmwareCommunications protocolComputer fileInfinityComputer hardwareKernel (computing)WritingInternetworkingProfil (magazine)Interface (computing)Computer animation
Image resolutionExecution unitMeta elementTournament (medieval)Library (computing)Metropolitan area networkDemonProjective planeMereologyDemo (music)Direction (geometry)Image resolutionSoftware developerComputer animation
Computer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
Hello, I'm going to talk about libratvibes, which is a demand to configure input devices. So who am I? My name is Filip Leinsch, I like beer, I'm a student, I'm one of the maintainers
of libratvibes and I package some stuff for Arch Linux. So, the table of contents, I'm going to explain a bit better what is libratbag, then I'm going to talk about the current status, what we have planned for the future, and a really
quick overview of the it protocol, then how you can define your own libratbag driver, then some questions. So, what is libratbag? Libratbag is a D-Bus demand to configure the hardware of input devices.
So for example, some IAM devices like this one, you can change the sensibility and other aspects of the hardware, but they often, the manufacturer often only provides
official drivers for like 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 libratbag 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 kind of 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 SteelSeries have like a different protocol for each hardware,
so it's a bit of a mess. And libratbag was created in 2015 by Benjamin Tisvach, who is one of the maintainers of the EID sub-tree of the kernel, and Peter Atterer, who is the maintainer of libinput
and most of the Linux input stack. So what can you configure with libratbag? So you can change the resolutions, so the DPI settings, you can change the report rate, you can remap buttons, you can do other macros, and you can change the effects of
the LEDs. For clients, we currently have ratbagctl, which is a CLI client, 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 like a proper client for end users. So the status of libratbag, so it works, you can change all of settings for the support
of devices, but we don't have any, we don't have a stable client API yet. So because of several issues, like we have limited time, we are not, we don't want to
define a stable API yet, because we will have to, if we do it, we will have to maintain it, and we want, we hope to be able to do it soon, but it's not there yet.
So the issues that we currently have with libratbag, like I said, we have limited time, we don't have that many maintainers, that many contributors, the people that contribute to libratbag 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 devices 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 it's, one of the issues is, it can be hard to maintain, so some of the code, if you don't have some previous knowledge of
the Git protocol, which is the protocol used by input devices, it can be a little bit complex in some parts, but you usually have to deal with it, we, me and other maintainers have to deal with 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, that can really prevent us from fixing stuff, because we don't have the hardware, so 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 which is not great, because like I said, we don't have a lot of devices, and it's hard to maintain, so what we want to do is to have a 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 most, one of the main projects of the internship was to
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, 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 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, you have the same color effects between everything, so I'm going to talk just a little bit about
each protocol, which is the protocol used 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,
but the 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 packet that the device sends to the computer 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 the protocol defines 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 axes,
but the protocol cannot really 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 vendors might want to do, so they define, 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 packages start with one, send the basic mouse hardware updates, and the reports start with two,
just send vendor data, and at this point the driver, the generic driver 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 Libradpack 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
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 CFS and then 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 def 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 Libradpack
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 operate something, some setting, it will be called, sorry, no,
the probe method is the first time that you connect the 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 tell 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 I can, if anyone has questions, I can answer, otherwise I can show you a demo, I mean, I don't know if, you know, yeah, with the current status of programming the
internal memories of some of the mices, okay, the status of programming the memory of some mices, so most 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 internet on top of it, it doesn't, most devices 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, you can, in those devices you can actually, using the vendor protocol, you can write to that, 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 commands that you say, okay, set the led to the color red, and then the firmware receives that message and interprets it, and
there's that, that's the led to red, I don't know if I answered your question properly, because just 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 when running some firmware that will just get updates from the sensor, and then report, create some packets with the updated state and send it,
so it's, you can only do what the firmware allows you 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, anyone else?
Is the runpad only supporting HID devices, like if I, well I do have a mouse where I reverse infinity protocol, but it's not, well it isn't HID, so should I write a kernel driver to emulate an HID device? I mean, I don't think you should, sorry, okay, you are asking if
you are telling that 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 Librad back, because after all it's just a daemon that takes your device and exports some settings, so resolutions, support rates, LED effects, things like that, and your device matches that profile, so anyone has any questions?
Do you have to use Ratbag D to get stuff done, or can you just write something, use Librad, libratbag to go and configure devices directly via HID? Okay, so do I, do we need to
use the Ratbag D, which is the daemon, or can I just use Libradbag to do what I want?
Kind of deprecated, and we just merge the daemon and the library, and right now we only
public support the daemon, 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, so 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 okay, my device shows up, then I have resolutions, I can
change that, can remap 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,
you, if your mouse is part of the Libradbag, you can just go here, and, but it will just copy this interface, where you can just do it, and then it's remapped, then you click apply, and then, and now the buttons are, let me see if I can, yeah, I need to do this,
the buttons are remapped, I need to use the other button, yeah, okay, so then we have the LEDs, so I can just put like this orange, if I do this,
now if I, let me show, if I click apply, it should go orange, okay, it went,
yeah, that's basically it.