• Mail chew, early call, sync with Dave.
• Published the next strip around how private initiative can smooth roads:
  
• More catch-up, sales team call.

First of all, what's outlined here should be available in libinput 1.29 but I'm not 100% certain on all the details yet so any feedback (in the libinput issue tracker) would be appreciated. Right now this is all still sitting in the libinput!1192 merge request. I'd specifically like to see some feedback from people familiar with Lua APIs. With this out of the way:

Come libinput 1.29, libinput will support plugins written in Lua. These plugins sit logically between the kernel and libinput and allow modifying the evdev device and its events before libinput gets to see them.

The motivation for this are a few unfixable issues - issues we knew how to fix but we cannot actually implement and/or ship the fixes without breaking other devices. One example for this is the inverted Logitech MX Master 3S horizontal wheel. libinput ships quirks for the USB/Bluetooth connection but not for the Bolt receiver. Unlike the Unifying Receiver the Bolt receiver doesn't give the kernel sufficient information to know which device is currently connected. Which means our quirks could only apply to the Bolt receiver (and thus any mouse connected to it) - that's a rather bad idea though, we'd break every other mouse using the same receiver. Another example is an issue with worn out mouse buttons - on that device the behavior was predictable enough but any heuristics would catch a lot of legitimate buttons. That's fine when you know your mouse is slightly broken and at least it works again. But it's not something we can ship as a general solution. There are plenty more examples like that - custom pointer deceleration, different disable-while-typing, etc.

libinput has quirks but they are internal API and subject to change without notice at any time. They're very definitely not for configuring a device and the local quirk file libinput parses is merely to bridge over the time until libinput ships the (hopefully upstreamed) quirk.

So the obvious solution is: let the users fix it themselves. And this is where the plugins come in. They are not full access into libinput, they are closer to a udev-hid-bpf in userspace. Logically they sit between the kernel event devices and libinput: input events are read from the kernel device, passed to the plugins, then passed to libinput. A plugin can look at and modify devices (add/remove buttons for example) and look at and modify the event stream as it comes from the kernel device. For this libinput changed internally to now process something called an "evdev frame" which is a struct that contains all struct input_events up to the terminating SYN_REPORT . This is the logical grouping of events anyway but so far we didn't explicitly carry those around as such. Now we do and we can pass them through to the plugin(s) to be modified.

The aforementioned Logitech MX master plugin would look like this: it registers itself with a version number, then sets a callback for the "new-evdev-device" notification and (where the device matches) we connect that device's "evdev-frame" notification to our actual code:

libinput:register(1) -- register plugin version 1
libinput:connect("new-evdev-device", function (_, device)
    if device:vid() == 0x046D and device:pid() == 0xC548 then
        device:connect("evdev-frame", function (_, frame)
            for _, event in ipairs(frame.events) do
                if event.type == evdev.EV_REL and 
                   (event.code == evdev.REL_HWHEEL or 
                    event.code == evdev.REL_HWHEEL_HI_RES) then
                    event.value = -event.value
                end
            end
            return frame
        end)
    end
end)

This file can be dropped into /etc/libinput/plugins/10-mx-master.lua and will be loaded on context creation. I'm hoping the approach using named signals (similar to e.g. GObject) makes it easy to add different calls in future versions. Plugins also have access to a timer so you can filter events and re-send them at a later point in time. This is useful for implementing something like disable-while-typing based on certain conditions.

So why Lua? Because it's very easy to sandbox. I very explicitly did not want the plugins to be a side-channel to get into the internals of libinput - specifically no IO access to anything. This ruled out using C (or anything that's a .so file, really) because those would run a) in the address space of the compositor and b) be unrestricted in what they can do. Lua solves this easily. And, as a nice side-effect, it's also very easy to write plugins in.[1]

Whether plugins are loaded or not will depend on the compositor: an explicit call to set up the paths to load from and to actually load the plugins is required. No run-time plugin changes at this point either, they're loaded on libinput context creation and that's it. Otherwise, all the usual implementation details apply: files are sorted and if there are files with identical names the one from the highest-precedence directory will be used. Plugins that are buggy will be unloaded immediately.

If all this sounds interesting, please have a try and report back any APIs that are broken, or missing, or generally ideas of the good or bad persuation. Ideally before we ship it and the API is stable forever :)

[1] Benjamin Tissoires actually had a go at WASM plugins (via rust). But ... a lot of effort for rather small gains over Lua

The past two weeks have gone by too quickly. I’ve had so many wonderful conversations with so many of our contributors and community friends at this point that I couldn’t be more confident that I’m in the right place. The next year is going to be a lot of fun and I’m looking forward to working with many more of you.

This next year will be fun. But it is also going to be a lot of work . I’d like to take a minute to talk about some of the work we need to do, and how you can help. Because the 2025 election cycle has begun .

## Governance

Being on the GNOME Foundation Board is, first and foremost, about governance. If you join the Board, you will probably do your onboarding with Rob. He’s good at it. He’ll walk you through a slide deck and the very first slide will contain this quote in 480pt font:

Governance is not management.

The full quote, from the second page of Kenneth Dayton’s book is:

Governance is not management. In my opinion, one of the worst sins of charitable organizations is that too often they do not distinguish between the two. Rather, they confuse the two responsibilities and in the process hamper the mission of the institution.

This is an important distinction. Joining the Board does not mean you’ll be managing staff. The Board exists to perform the functions you’ll see in the source material for the remaining 30 slides:

• Governance is Governance (Kenneth Dayton)
• Nonprofit Corporate Governance: The Board’s Role (Harvard)
• The Director’s Manual (Browning, Sparks)
• CharityLawyer: Nonprofit Law Simplified (Caritas Law Group)

These include (but are not limited to) responsibilities like:

• Oversight
• Making high-level decisions
• Long-term strategy
• Fiduciary responsibility
• Ensuring the right ED is in place
• Reviewing budgets
• Deciding policy
• Understanding the structure and duties of a 501(c)3 nonprofit

Riveting, I know. But! This isn’t everything. And if you’re still awake, I will tell you that we don’t just need policy wonks and 50-year strategists. There’s some hands-dirty work associated with the GNOME Foundation Board, too. Even though the Board is not designed to manage , it can help execute . Once upon a time, the Board member were the people who scrambled to arrange GUADEC every year. It helps to be a little scrappy and we could learn to reclaim a bit of that history.

## Finance

We could really use help with our finances. Our bookkeepers are absolutely metal and we’re very lucky to have them. Our Ops staff are super hard-working. But the Board rotates continuously. Not every Board will be able to read a balance sheet. We need to present the Board with a continuous view of finances — not just quarterly reports, but monthly reports which clearly describe our positions, our trajectory, and our best case / likely case / worst case. Financial clarity is paramount for an effective Board… but it’s also easier said than done.

If you love spelunking through spreadsheets, tying together multiple data sources, documentation, automation, or doing a wee bit of data science and visualization on Small Data, the Board might be for you! Know that this effort will take time and patience, though. You won’t find clarity overnight. Determination — to the point of stubbornness, perhaps — will be your best ally, here.

## Executive

In addition to finances, there are a number of committees in the Foundation . Some of these are Board committees and some are delegated committees. Committees, whether Board committees or not, all have some executive powers.

The most obvious of these is the aptly-name Executive Committee. A lot of work gets done here and it’s safe to say meaningful participation in the Exec Committee is almost a daily commitment in 2025. But there are other committees that could certainly use help (or even rebooting) and don’t require a daily commitment as a volunteer:

• Governance Committee (see Governance )
• Finance Committee (see Finance )
• Travel Committee
• Internship Committee
• etc.

Committee participation doesn’t specifically require that you join the Board. It’s also possible for the Board to appoint Officers … and we’ll do that! But if you really want to get stuck in, I strongly suggest standing for election. It doesn’t matter if you’re a lawyer, an accountant, a designer, or developer.

But beyond roles , who should stand for election? Let’s dig into that for a second.

## Representation

The GNOME community is massive. I still have so many people to meet. And there seem to be people from every walk of life, every community, every corner of the planet, every cultural background, every linguistic background. If you’re one of the unlucky people I’ve forced one of my excited 3-hour sermons upon, you probably know by now I’m a huge fan of Network Resilience . I gave a keynote once that talks about this (among many other things). The Foundation, and the Board in particular, is more resilient when it’s more diverse. If we all think the same way, all have the same upbringing, same background, same weaknesses in our thinking… this weakens the Foundation.

Someone recently told me they’ve thought about standing for elections for years but feel some Imposter Syndrome. I was shocked. This person has been contributing to GNOME for decades. They’re clearly very smart, hardworking, and talented. If such a strong candidate is just waiting there in the wings, I can’t help but believe there are other strong potential Board members just waiting for the right moment.

The right moment is now.

We have 2SLGBTQIA+ folks on the Board. We do have folks with disabilities, different language backgrounds, different continents. But we have only one woman (who also happens to be our only lawyer). We have no one from east of Europe. We can do better. I’m not worried any of you are going to apply to the Board because of your background. I worry that you, like my new friend mentioned above, might fight the temptation to stand for election because you think you don’t belong here.

You absolutely belong here. Bring your talent, your energy, your tenacity. Help us kick ass.

## No Nonsense

I’d like to take a minute to discuss some of the reasons not to join the Board.

First, we need Board members who will help paddle our wee canoe in the same direction. GNOME, both the Project and the Foundation, have experienced some real hardship in recent years. If it’s your intention to join the Board only so you can paddle sideways (or backwards), please put that thought on hold for a couple years. We just can’t support that level of disruption right now. We will have our disagreements but we all need to be on the same page.

Second, if everything above bores you but you have a single issue that you’re really dreaming of hammering home… that’s also a recipe for ineffective Board participation. If elected, you will be on the Board for TWO YEARS. That’s a long time. Make sure you want to be there to work with us for the entire two years. It will be hard work. And it will be worth it.

## Hard Work

While talking to Maria ( @marimaj ) today — one of my favourite contributor conversations so far — she said something that resonated with me: “Almost no one appreciates just how much work is required! The Foundation requires so, so much work to function properly.” She then proceeded to name a bunch of folks who contribute day and night. Her hard-won understanding is built upon experience. She’s been a part of the community for a long time, and she’s seen how hard staff and volunteers work to keep the Foundation moving.

If you want to know how much work the Foundation requires, ask her. Ask me. Ask any Board member.

If you want to put in the work, I want you to stand for election. I’m looking forward to seeing your nomination.

To announce your candidacy, read Andrea’s post and follow the instructions . (Thanks Andrea!)

With Foundry I want to make LSP management much easier than it currently is in Builder .

We have the foundry lsp run python3 command where python3 can be replaced with any language for which there is an installed LSP plugin. This will start an LSP using all the abstractions (including cross-container execution) and provide it via stdin / stdout .

But what happens when you have a half-dozen language servers for Python with new ones added every week? There is a simple builtin tool now.

Keep in mind the language identifiers should match GtkSourceView language identifiers.

# Make clangd the preferred LSP for C
foundry lsp prefer clangd c

# Make sourcekit-lsp preferred LSP for C++
foundry lsp prefer sourcekit-lsp cpp

# Make ruff the preferred LSP for Python3
foundry lsp prefer ruff python3

If there is a clear LSP that your project should be using by all contributors, add --project and it will update the value in the projects settings.