libratbag
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/47379 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2020225 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
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
03:26
Client (computing)Common Language InfrastructureClient (computing)Proper mapPlanningComputer animation
03:53
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
09:00
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
11:44
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
20:36
Image resolutionExecution unitMeta elementTournament (medieval)Library (computing)Metropolitan area networkDemonProjective planeMereologyDemo (music)Direction (geometry)Image resolutionSoftware developerComputer animation
23:11
Computer animation
23:36
Point cloudFacebookOpen source
Transcript: English(auto-generated)
00:09
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
00:24
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
00:46
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.
01:07
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
01:22
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
01:41
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
02:06
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
02:27
the same code work for different models. While other vendors like SteelSeries have like a different protocol for each hardware,
02:40
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
03:01
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
03:24
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
03:48
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
04:04
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
04:23
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.
04:42
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
05:06
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
05:23
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
05:42
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
06:07
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
06:22
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,
06:44
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,
07:04
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
07:25
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
07:46
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
08:09
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
08:24
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
08:48
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
09:04
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,
09:25
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,
09:52
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,
10:12
but the protocol is designed to work with all kinds of input devices, and
10:25
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
10:44
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
11:10
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
11:28
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,
11:48
but the protocol cannot really it's not broad enough to be able to define all of the things that you could be
12:04
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,
12:24
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,
12:42
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
13:03
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
13:22
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
13:49
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
14:05
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
14:33
to the, which is a file descriptor that only sends the raw data to the device, so in Libradpack
14:49
to write your own driver you basically create a new file and you define some functions, and then you define this structure,
15:02
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,
15:23
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,
15:47
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
16:01
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
16:30
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,
16:46
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
17:06
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,
17:21
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
17:47
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
18:02
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,
18:22
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?
18:45
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
19:07
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
19:24
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
19:45
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?
20:11
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
20:25
use the Ratbag D, which is the daemon, or can I just use Libradbag to do what I want?
20:50
Kind of deprecated, and we just merge the daemon and the library, and right now we only
21:00
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
21:27
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
21:47
connect it directly, so okay, my device shows up, then I have resolutions, I can
22:04
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,
22:21
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,
22:50
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,
23:12
now if I, let me show, if I click apply, it should go orange, okay, it went,
23:22
yeah, that's basically it.