fidzu : GNOME

• J. unwell in the night, feeling groggy. Sync with Dave, important partner call.
• Really excited to announce the merger of Collabora Productivity and allotropia! and really looking forward to properly welcoming and unifying the teams after COOL days
  
• Published the next strip around whether you focus on the process, or getting results:
  
• Call with Till & Thorsten, caught the end of our sales team call. Sync with Philippe. What a day!

28 May 2025 9:00pm GMT

As you may be aware, the entire GNOME community has been on the receiving end of a coordinated harassment campaign for the past year. All GNOME users and contributors with a public profile, and those active on Matrix, are being harassed.

I want to share my personal perspective on this, as the GNOME Foundation Executive Director. There are some things that need to be said about these events, and I want to provide some reassurance for community members.

People At Risk

It is important for us to recognize that there are members of our community who are particularly at risk from the recent harassment campaign. Here, I am specifically referring to those people for whom this kind of harassment poses a genuine physical threat. The harassment frequently takes the form of anti-LGBTQIA+ (most frequently anti-trans), racist, misogynist, anti-semitic, and anti-muslim messages.

Individual targets of the harassment have included Staff members, Board members, Foundation members, and users. Our community includes people living under oppressive, authoritarian regimes. It includes people in war zones. It includes refugees. These people are all acutely at risk.

Please know that if you belong to one of these groups, you are always welcome in the GNOME community. We will do everything we can to ensure your safety in our community. We will not tolerate threats to your safety.

Psychological Harm

In addition to risk of physical harm, one component of this coordinated harassment campaign is the use of disturbing images, intending to cause psychological harm. The attackers' very possession of these images is an international crime.

These attacks have been stopped on Discourse, our forum tool. The GNOME moderation team is actively engaged with the Matrix moderation team to reduce (and ultimately eliminate) users' exposure to these images on the Matrix protocol.

If you have received one of these images, your best course of action is to email abuse@matrix.org. Specific, actionable advice is provided in The GNOME Handbook's Matrix: Staying Safe section.

My Personal Experience

I was quite surprised to witness - and then find myself on the receiving end of - this harassment campaign when I began my new role with the GNOME Foundation. Because I'm a relatively new community member, I want to discuss my experience in case it is helpful to anyone else.

The first time I was on the receiving end of one of these images, my response was to go to my partner and say, "I'm feeling sick and anxious. I really need a hug." This was also my response to the first few harassment messages I received. I was advised by other staff members not to respond to the people sending these messages of harassment. I'm glad I took their advice. Engaging will not help.

I have tried on many occasions to have compassion for those instigating and carrying out the harassment. They are clearly misguided - and not well. I have spent many years cultivating compassion but I still find myself struggling with this. Often thinking of the attackers leaves me feeling angry instead of compassionate.

If I catch myself directing angry thoughts toward those people carrying out the harassment campaign, I instead try my best to direct compassion toward those who are suffering because of it: the community. It is easy to feel compassion for the victim and if I focus my attention on the people who continue to work tirelessly on GNOME in spite of these attacks, I always end up with a smile on my face.

If you are feeling angry or frustrated, perhaps this approach will help you, too.

Commitment

Not every safety violation is created equal. Trolling and flame wars require a stern conversation - and perhaps moderation. A Code of Conduct violation necessitates the involvement of the Code of Conduct Committee - and perhaps the Board. Crimes demand the engagement of lawyers and law enforcement.

Of the harassment campaign I have heard the following euphemisms:

• "The spam."
• "They are bullies."
• "These people trolling us."
• "These people seem like jerks."
• "An annoying technical issue with federated protocols."

They are not simply "bullies". Their actions do not constitute "trolling". These are crimes.

It is my commitment to you as members of this community that the Foundation will pursue the most appropriate course of action whenever your safety is violated, to the degree it is violated. This is part of why the Foundation exists: an incorporated entity can engage other organizations in more significant ways than any one person can.

The Foundation stands with you.

28 May 2025 2:44pm GMT

• Early customer call, planning call. Intermittent catch ups with Margaret, 1:1 with Lily, partner call, sync with Andras.
• Up late working on slides, starting to feel somewhat unwell.

27 May 2025 9:00pm GMT

Previously it was mentioned that Python and C++ do iteration quite differently. Python has "statefull" objects that have a .next() method that returns a new object or throws a StopIteration exception. Incidentally Rust does exactly the same thing, except that it uses an optional type rather than an exception. C++ does not work like this, instead it has a concept of a "start" and "end" of a sequence and the machinery keeps incrementing the start until it reaches the end.

At the end of last post it was said that it is difficult to integrate an object of the former type with C++'s native language facilities, at least without macros.

Now we'll look how to integrate an object of the former type with C++'s native language facilities without any macros.

In fact, it only took fewer than 30 lines of code to do. The caveat being that it is probably fairly easy to break it. But it works for me.

Here it is being used.

There is also a second, similar helper class that takes ownership of the object being iterated over.

25 May 2025 9:50pm GMT

Hi, we've started a new project: a Farsi-language podcast version of This Week in GNOME.

Each week, we read and summarise the latest TWIG post in Farsi, covering updates from GNOME Core, GNOME Circle apps, and other community-related news. Our goal is to help Persian-speaking users and contributors stay connected with the GNOME ecosystem.

The podcast is hosted by me (Revisto), along with Mirsobhan and Hadi. We release one short episode per week.

Since I also make music, I created a short theme for the podcast to give it more identity and consistency across episodes. It's simple, but it adds a nice touch of production value that we hope makes the podcast feel more polished.

We're also keeping a GitHub repository in which I'm uploading each of my episode scripts (in Farsi) in Markdown + audio files. The logo and banner assets have been uploaded in SVG as well for transparency.

You can listen to the podcast on:

• Spotify
• Castbox
• Podcast Index
• Telegram: @gnome_fa
• Or via RSS feed

Let us know what you think, and feel free to share it with Farsi-speaking friends or communities interested in GNOME.

25 May 2025 1:03pm GMT

Welcome to the third instalment of the Foundation Report! Instalment? Installment? English is dumb. Okay, here goes!

## Opaque Stuff

• 3rd party consultation on safety issue continues
• researching some software choices for process automation
• asking individuals about their goals - no name-dropping because I'm not sure everyone would be comfortable
• international finance is the worst but the problem is fixed now

## Meeting People

I'm meeting fewer people and getting more grunt work accomplished but I still met plenty of lovely folks this week. I also met some people after last week's report: Jef Spaleta is the Fedora Project's new Lead. He and I agreed all new business deals will be done in the curling rink instead of the golf course. Matthias Clausen gave me a bit of a history lesson and also convinced me I need to talk to more old-timers: the sense of perspective decades of involvement brings is valuable.

I met Tobias and chatted about how the Foundation can increase support to contributors. Rosanna introduced me to our bookkeeper and her advisor so I could get an intro to our bookkeeping process and a walk-through of our last CPA review. Maria and I had a lovely chat about her 20+ years as a GNOME user/contributor and the value of logistics, communications, and admin folks in a very tech-heavy organization… I found myself nodding along with so much she had to say.

I got a chance to meet Aaditya from GNOME Nepal! What he and his team are doing there is after my own heart: getting GNOME, Linux, and other freie software into the hands of aspiring hackers and students. He's essentially already running the style of repair cafe that the endof10.org campaign will teach people to run and I sincerely hope he'll have time to help with End Of 10 (but he's a busy guy!) as I think he has so much to offer. I was shocked to learn that GNOME Nepal is only one year old. They've already accomplished so much.

Rosanna and I met the CommitChange team, who help us with gnome.org/donate. They have some neat stuff going on and they explained where they can help us with tweaks to their software and API, analytics, and campaign management. We're hoping to do something with CommitChange very soon but I won't say what until it's baked because it's not my baby.

Last, we met a couple great folks who are interested in helping out in the Treasurer role at the Foundation. If you know anyone who's a spreadsheet powerhouse, the Tufte of Reporting, or obsessed with carefully-balanced budgets, please encourage them to email me or Rob!

## Ideas, Docs, Walls, Files

I've started to corral my scatterbrained ideas into some homes. They're still spread out between paper notebooks, Markdown files, voicenotes, and my extremely frazzled family members. I'll probably stop telling them about all the cool people I'm meeting and all the ideas I have by … GUADEC? Maybe.

We've started an internal "Foundation Handbook" to match handbook.gnome.org. This is only visible to Staff and Board members, as it contains a great deal of PII and other private information. It has a loooong way to go, but the goal is for it to provide the same beautiful, central documentation location (for banking, staff tools, ops, and so on) that the Project Handbook does. Public information about the Foundation won't go in here, of course, as it still belongs on foundation.html. If you join the Board, you're welcome to help us keep it clean and organized so we easily know where everything is and so it's easy to onboard future Boards, EDs, and other Staff. (No, I'm not planning to leave anytime soon.)

We've rebooted the Staff project wall. We don't keep track of Ops tasks in here (since they're recurring) but, rather, anything Executive: Follow up with so-and-so, document XYZ process, make a one-time social media post for an organizational partner, etc. We're also making heavier use of the Board wall, bit by bit.

Nextcloud! We're… trying to use it. Collecting all our files into Nextcloud will take some time, but we've started to push toward using it with some boring old policy junk. We just have to keep up the gardening and it will become a thing of beauty, eventually.

## Fundraising

We've talked a little about fundraising with the Board (I'm still relatively new) but as the smaller fires are each extinguished, fundraising is taking up more headspace. This is a major concern for me. Perhaps the major concern. The conversation with CommitChange yesterday was one small step toward this. We've also started some "market research." (I'm not sure what else to call it.) When it comes to individuals and organizations that have never donated to GNOME before, I want to know:

• Do they understand how important GNOME is, as infrastructure?
• Where do we find them to ask them to donate? (If not within GNOME itself.)
• Do they want anything for their donation? Or do we just need to reach them?

## GUADEC

Kristi and I sat and had a long look through the GUADEC budget and our current expenses. She also very patiently explained to me the event expectations of Europeans as they differ from Americans. Still plenty for me to learn about how our events are planned, but Kristi's got me off to a great start.

## End of 10

Joseph from endof10.org and KDE Eco fame has been in touch continuously. Sri posted a call for a GNOME endof10.org Promo Team on the Engagement blog. It's going to be here before you know it! If you want to get involved, ping us in #engagement:gnome.org or #endof10-en:kde.org.

If you don't know what I'm talking about, go watch Joseph's Linux App Summit talk! It's great and he does a fantastic job of explaining the importance of this effort.

## "Wow, yay, transparency"

I'm very grateful to everyone who has thanked me for these little Foundation Reports. I'm glad I'm not just screaming into the void with these and that a few people are getting value out of them. However, I do have one request.

On occasion (though rarely), these compliments have come paired with (or couched in) a complaint about previous EDs, other folks on staff, or the Board. I would encourage folks who are framing things this way to stop, as it's a very unhelpful way to communicate. We need to remember that everyone works differently. I'm a loudmouth, so I'm loud. Most people on staff and on the Board are not. Instead, they have their nose to the grindstone. I think most of them struggle to find the time to talk about their work at the end of the workweek. Most of them work late into the night. Most of them work weekends. It's been a long year (or…five?) for the Foundation and most of them are very tired.

Because I am loud, I will do my best to be loud for them. Week after week, I'll talk more about what "we" are doing - please understand that "we" is mostly them. If I tell you about work that's happening at the Foundation, that work didn't magically start when I joined in May. It's been happening for years and I'm just doing my best to make it a little more visible.

Instead of thanking me for my ridiculous infoblog, please redirect your thanks to someone on staff. Thank someone on the Board for their tireless service. Thank a contributor whose work comes pouring in, year after year. Send a box of chocolates in a DM. Drop them a little thank-you email. Give them a high-five at GUADEC. (Virtual or otherwise.)

And if you're feeling very energetic, run for the Board so you can help out.

24 May 2025 2:49am GMT

Learn more about this blog, my GSoC 2025 project with GNOME, and my background in open source development.

24 May 2025 12:00am GMT

Hello everyone! 👋

I'm Ahmed, a senior Computer Science student at Helwan University. I'm thrilled to be part of Google Summer of Code 2025 with GNOME! This blog post is the first in a series I'll write throughout the summer to share my journey. I'll start with how I got into open source, why I chose GNOME, and what my project is all about.

---

🌐 Why Open Source?

My interest in open source began out of frustration, other platforms were too heavy, resource-consuming, or simply didn't respect user privacy. Open source software offered me freedom: to learn, to understand, and to use tools that align with my values.

23 May 2025 4:52pm GMT

Thanks to the work of Christian Gmeiner, support for annotating time regions using Sysprof marks has landed in Mesa.

That means you'll be able to open captures with Sysprof and see the data along other useful information including callgraphs and flamegraphs.

I do think there is a lot more we can do around better visualizations in Sysprof. If that is something you're interested in working on please stop by #gnome-hackers on Libera.chat or drop me an email and I can find things for you to work on.

See the merge request here.

23 May 2025 4:51pm GMT

I'm happy to share that 3 major IPU6 camera related kernel changes from linux-next have been backported to Fedora and have been available for about a week now the Fedora kernel-6.14.6-300.fc42 (or later) package:

1. Support for the OV02C10 camera sensor, this should e.g. enable the camera to work out of the box on all Dell XPS 9x40 models.
2. Support for the OV02E10 camera sensor, this should e.g. enable the camera to work out of the box on Dell Precision 5690 laptops. When combined with item 3. below and the USBIO drivers from rpmfusion this should also e.g. enable the camera on other laptop models like e.g. the Dell Latitude 7450.
3. Support for the special handshake GPIO used to turn on the sensor and allow sensor i2c-access on various new laptop models using the Lattice MIPI aggregator FPGA / USBIO chip.

If you want to give this a test using the libcamera-softwareISP FOSS stack, run the following commands:

sudo rm -f /etc/modprobe.d/ipu6-driver-select.conf
sudo dnf update 'kernel*'
sudo dnf install libcamera-qcam
reboot
qcam

Note the colors being washed out and/or the image possibly being a bit over or under exposed is expected behavior ATM, this is due to the software ISP needing more work to improve the image quality. If your camera still does not work after these changes and you've not filed a bug for this camera already please file a bug following these instructions.

See my previous blogpost on how to also test Intel's proprietary stack from rpmfusion if you also have that installed.

comments

23 May 2025 4:09pm GMT

Since the set of rpmfusion intel-ipu6-kmod + ipu6-camera-* package updates from last February the FOSS libcamera-softwareISP and Intel's proprietary stack using the Intel hardware ISP can now co-exist on Fedora systems, sharing the mainline IPU6-CSI2 receiver driver.

Because of this it is no longer necessary to blacklist the kernel-modules from the other stack. Unfortunately when the rpmfusion packages first generated "/etc/modprobe.d/ipu6-driver-select.conf" for blacklisting this file was not marked as "%ghost" in the specfile and now with the February ipu6-camera-hal the file has been removed from the package. This means that if you've jumped from an old ipu6-camera-hal where the file was not marked as "%ghost directly to the latest you may still have the modprobe.d conf file around causing issues. To fix this run:

sudo rm -f /etc/modprobe.d/ipu6-driver-select.conf

and then reboot. I'll also add this as post-install script to the ipu6-camera-hal packages, to fix systems being broken because of this.

If you want the rpmfusion packages because your system needs the USBIO drivers, but you do not want the proprietary stack, you can run the following command to disable the proprietary stack:

sudo ipu6-driver-select foss

Or if you have disabled the prorietary stack in the past and want to give it a try, run:

sudo ipu6-driver-select proprietary

To test switching between the 2 stacks in Firefox go to Mozilla's webrtc test page and click on the "Camera" button, you should now get a camera permisson dialog with 2 cameras: "Built in Front Camera" and "Intel MIPI Camera (V4L2)" the "Built in Front Camera" is the FOSS stack and the "Intel MIPI Camera (V4L2)" is the proprietary stack. Note the FOSS stack will show a strongly zoomed in (cropped) image, this is caused by the GUM test-page, in e.g. google-meet this will not be the case.

Unfortunately switching between the 2 cameras in jitsi does not work well. The jitsi camera selector tries to show a preview of both cameras at the same time and while one stack is streaming the other stack cannot access the camera. You should be able to switch by: 1. Selecting the camera you want 2. Closing the jitsi tab 3. wait a few seconds for the camera to stop streaming 4. open jitsi in a new tab.

Note I already mentioned most of this in my previous blog post but it was a bit buried there.

comments

23 May 2025 3:42pm GMT

Update on what happened across the GNOME project in the week from May 16 to May 23.

GNOME Core Apps and Libraries

GLib ↗

The low-level core library that forms the basis for projects such as GTK and GNOME.

Philip Withnall reports

Axel Karjalainen has added SYSLOG_IDENTIFIER to journald log messages outputted by GLib's default log handler, which should make journal messages from your app easier to find (see https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4589)

Web ↗

Web browser for the GNOME desktop.

adrian reports

Web has gained a preferences page that allows toggling WebKit features at run-time. Tech Preview builds of the browser will show the settings page by default, while in regular releases it is hidden and may be enabled with the following command:

gsettings set org.gnome.Epiphany.ui webkit-features-page true

This should allow frontend developers to test upcoming features more easily. Note that the settings for WebKit features are not persistent, and they will be reset to their default state on every launch.

GNOME Circle Apps and Libraries

Déjà Dup Backups ↗

A simple backup tool.

Michael Terry announces

Déjà Dup Backups has landed support for restic mount which lets you restore files using your native file manager (instead of the previous in-app file browser)

Third Party Projects

tfuxu announces

Halftone 0.7.0 introduces a long-awaited feature: support for image zooming! From now on, you can easily check even the smallest details simply by using the scroll wheel or gestures on your touchpad/touchscreen.

This release also improves stability and user experience by properly handling and informing the user about errors occurring during image loading. No more endless loading screens!

As always, you can download it from Flathub.

Semen Fomchenkov announces

Hello everyone This week, at ALT Gnome and ALT Linux Team, we released the settings center we developed with support for libpeas-based plugins. I have prepared a short text with its description, I hope it will help to better understand the essence of the idea. And some app UI screenshots: https://altlinux.space/alt-gnome/Tuner/src/branch/main/data/screenshots

Tuner is an extensible settings management center for GNOME, featuring a modern graphical interface built with Libadwaita. Designed with a focus on flexibility and user convenience, Tuner allows every GNOME user to assemble a personalized control center tailored to their system configuration needs.

Key Features:

• Plugin-Based Architecture: Tuner leverages libpeas to provide a dynamic and modular ecosystem. This means any developer can contribute their own functionality in the form of a plugin, offering unlimited opportunities for expansion and customization.

• Simplified GSettings Integration: Inspired by the GNOME Refine project, Tuner implements a mechanism for creating widgets using .blp (Blueprint) files. This simplifies the binding of GSettings keys to interface elements and significantly reduces boilerplate code for developers.

• Modern Libadwaita Interface: The user interface follows GNOME HIG guidelines, ensuring a clean, adaptive, and touch-friendly experience.

• Distribution-Specific Modules: GNOME-based distributions can use Tuner as a hub for distribution-specific settings. For example, a TunerPanel module for managing panel mode, integrated into the "Appearance" section(Created by TunerTweaks module) for ALT Linux, has already been implemented.

Getting Started with Plugin Development:

Developers interested in extending Tuner can refer to the quick guide on plugin creation. The guide includes an example of writing a plugin in Vala and integrating it with Tuner's architecture. Additionally, template repositories are available for creating plugins in both Vala and Python, along with documentation in Valadoc format.

Phosh ↗

A pure wayland shell for mobile devices.

Guido says

Phosh 0.47.0 is out:

phosh's Feedback Quick Setting now has a status page featuring a "Do not disturb" toggle (that sets the profile to "silent" and disables notification banners) and a button for quick access to the Feedback settings (to e.g. tweak Feedback for individual apps or tune ring tones).

The on screen keyboard makes better use available space when showing auto completions, adds Emojis to the auto completions and can show a popover for the currently typed character.

There's more, see the full details at here

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

23 May 2025 12:00am GMT

Hello. It is May, my favourite month. I'm in Manchester, mainly as I'm moving projects at work, and its useful to do that face-to-face.

For the last 2 and a half years, my job has mostly involved a huge, old application inside a big company, which I can't tell you anything about. I learned a lot about how to tackle really, really big software problems where nobody can tell you how the system works and nobody can clearly describe the problem they want you to solve. It was the first time in a long time that I worked on production infrastructure, in that, we could have caused major outages if we rolled out bad changes. Our team didn't cause any major outages in all that time. I will take that as a sign of success. (There's still plenty of legacy application to decommission, but it's no longer my problem).

During that project I tried to make time to work on end to end testing of GNOME using openQA as well… with some success, in the sense that GNOME OS still has working openQA tests, but I didn't do very well at making improvements, and I still don't know if or when I'll ever have time to look further at end-to-end testing for graphical desktops. We did a great Outreachy internship at least with Tanju and Dorothy adding quite a few new tests.

Several distros test GNOME downstream, but we still don't have much of a story of how they could collaborate upstream. We do still have the monthly Linux QA call so we have a space to coordinate work in that area… but we need people who can do the work.

My job now, for the moment, involves a Linux-based operating system that is intended to be used in safety-critical contexts. I know a bit about operating systems and not much about functional safety. I have seen enough to know there is nothing magic about a "safety certificate" - it represents some thinking about risks and how to detect and mitigate them. I know Codethink is doing some original thinking in this area. It's interesting to join in and learn about what we did so far and where it's all going.

Giving credit to people

The new GNOME website, which I really like, describes the project as "An independent computing platform for everyone".

There is something political about that statement: it's implying that we should work towards equal access to computer technology. Something which is not currently very equal. Writing software isn't going to solve that on its own, but it feels like a necessary part of the puzzle.

If I was writing a more literal tagline for the GNOME project, I might write: "A largely anarchic group maintaining complex software used by millions of people, often for little or no money." I suppose that describes many open source projects.

Something that always bugs me is how a lot of this work is invisible. That's a problem everywhere: from big companies and governments, down to families and local community groups, there's usually somebody who does more work than they get credit for.

But we can work to give credit where credit is due. And recently several people have done that!

Outgoing ED Richard Littauer in "So Long and Thanks For All the Fish" shouted out a load of people who work hard in the GNOME Foundation to make stuff work.

Then incoming GNOME ED, Steven Deobald wrote a very detailed "2025-05-09 Foundation Report" (well done for using the correct date format, as well), giving you some idea about how much time it takes to onboard a new director, and how many people are involved.

And then Georges wrote about some people working hard on accessibility in "In celebration of accessibility".

Giving credit is important and helpful. In fact, that's just given me an idea, but explaining that will have to wait til next month.

22 May 2025 10:23pm GMT

22 May 2025 10:05am GMT

I savored every episode, knowing this was going to be one of those rare shows, like Severance season one, that you only get to experience for the first time once. It pulls you into a vivid, immersive world that's equal parts mesmerizing and unsettling. A place you're fascinated by, but would never want to be put in. The atmosphere seeps into you - the sound design, the environments, the way it all just lingers under your skin. You can't shake it off.

And now I've watched the final 12. episode and I already miss it. So I need to say: watch it. It's something special.

The series is a full-length expansion of the short Scavengers by Joseph Bennett and Charles Huettner (With visible improvements across the board). They've cited Nausicaä as a major influence, but if you're into Akira, you'll catch a few visual nods there too. It's brutal. It's gorgeous. And honestly, I haven't been this excited about an animated series in a long time.

Neither Netflix nor HBO wanted to greenlight the second season. But the show has come to a very satisfying closure, so I'm not complaining.

★★★★★

22 May 2025 12:00am GMT

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

21 May 2025 2:09pm GMT