fidzu : freedesktop

At the Linux App Summit (LAS) in Albania three months ago, I gave a talk about testing in the xdg-desktop-portal project. There is a recording of the presentation, and the slides are available as well.

To give a quick summary of the work I did:

• Revamped the CI
• Reworked and improved the pytest based integration test harness
• Added integration tests for new portals
• Ported over all the existing GLib/C based integration tests
• Support ASAN for detecting memory leaks in the tests
• Made tests pretend to be either a host, Flatpak or Snap app

The hope I had is that this will result in:

• Fewer regressions
• Tests for new features and bug fixes
• More confidence in refactoring
• More activity in the project

While it's hard to get definite data on those points, at least some of it seems to have become reality. I have seen an increase in activity (there are other factors to this for sure), and a lot of PRs already come with tests without me even having to ask for it. Canonical is involved again, taking care of the Snap side of things. So far it seems like we didn't introduce any new regressions, but this usually shows after a new release. The experience of refactoring portals also became a lot better because there is a baseline level of confidence when the tests pass, as well as the possibility to easily bisect issues. Overall I'm already quite happy with the results.

Two weeks ago, Georges merged the last piece of what I talked about in the LAS presentation, so we're finally testing the code paths that are specific to host, Flatpak and Snap applications! I also continued a bit with improving the tests, and now they can be run with Valgrind, which is super slow and that's why we're not doing it in the CI, but it tends to find memory leaks which ASAN does not. With the existing tests, it found 9 small memory leaks.

If you want to improve the Flatpak story, come and contribute to xdg-desktop-portal. It's now easier than ever!

21 Aug 2025 9:00pm GMT

If you have spent any time around HID devices under Linux (for example if you are an avid mouse, touchpad or keyboard user) then you may have noticed that your single physical device actually shows up as multiple device nodes (for free! and nothing happens for free these days!). If you haven't noticed this, run libinput record and you may be part of the lucky roughly 50% who get free extra event nodes.

The pattern is always the same. Assuming you have a device named FooBar ExceptionalDog 2000 AI[1] what you will see are multiple devices

/dev/input/event0: FooBar ExceptionalDog 2000 AI Mouse
/dev/input/event1: FooBar ExceptionalDog 2000 AI Keybard 
/dev/input/event2: FooBar ExceptionalDog 2000 AI Consumer Control 

The Mouse/Keyboard/Consumer Control/... suffixes are a quirk of the kernel's HID implementation which splits out a device based on the Application Collection. [2]

A HID report descriptor may use collections to group things together. A "Physical Collection" indicates "these things are (on) the same physical thingy". A "Logical Collection" indicates "these things belong together". And you can of course nest these things near-indefinitely so e.g. a logical collection inside a physical collection is a common thing.

An "Application Collection" is a high-level abstractions to group something together so it can be detected by software. The "something" is defined by the HID usage for this collection. For example, you'll never guess what this device might be based on the hid-recorder output:

# 0x05, 0x01,                    // Usage Page (Generic Desktop)              0
# 0x09, 0x06,                    // Usage (Keyboard)                          2
# 0xa1, 0x01,                    // Collection (Application)                  4
...
# 0xc0,                          // End Collection                            74

Yep, it's a keyboard. Pop the champagne[3] and hooray, you deserve it.

The kernel, ever eager to help, takes top-level application collections (i.e. those not inside another collection) and applies a usage-specific suffix to the device. For the above Generic Desktop/Keyboard usage you get "Keyboard", the other ones currently supported are "Keypad" and "Mouse" as well as the slightly more niche "System Control", "Consumer Control" and "Wireless Radio Control" and "System Multi Axis". In the Digitizer usage page we have "Stylus", "Pen", "Touchscreen" and "Touchpad". Any other Application Collection is currently unsuffixed (though see [2] again, e.g. the hid-uclogic driver uses "Touch Strip" and other suffixes).

This suffix is necessary because the kernel also splits out the data sent within each collection as separate evdev event node. Since HID is (mostly) hidden from userspace this makes it much easier for userspace to identify different devices because you can look at a event node and say "well, it has buttons and x/y, so must be a mouse" (this is exactly what udev does when applying the various ID_INPUT properties, with varying levels of success).

The side effect of this however is that your device may show up as multiple devices and most of those extra devices will never send events. Sometimes that is due to the device supporting multiple modes (e.g. a touchpad may by default emulate a mouse for backwards compatibility but once the kernel toggles it to touchpad mode the mouse feature is mute). Sometimes it's just laziness when vendors re-use the same firmware and leave unused bits in place.

It's largely a cosmetic problem only, e.g. libinput treats every event node as individual device and if there is a device that never sends events it won't affect the other event nodes. It can cause user confusion though: "why does my laptop say there's a mouse?" and in some cases it can cause functional degradation - the two I can immediately recall are udev detecting the mouse node of a touchpad as pointing stick (because i2c mice aren't a thing), hence the pointing stick configuration may show up in unexpected places. And fake mouse devices prevent features like "disable touchpad if a mouse is plugged in" from working correctly. At the moment we don't have a good solution for detecting these fake devices - short of shipping giant databases with product-specific entries we cannot easily detect which device is fake. After all, a Keyboard node on a gaming mouse may only send events if the user configured the firmware to send keyboard events, and the same is true for a Mouse node on a gaming keyboard.

So for now, the only solution to those is a per-user udev rule to ignore a device. If we ever figure out a better fix, expect to find a gloating blog post in this very space.

[1] input device naming is typically bonkers, so I'm just sticking with precedence here
[2] if there's a custom kernel driver this may not apply and there are quirks to change this so this isn't true for all devices
[3] or sparkling wine, let's not be regionist here

20 Aug 2025 1:12am GMT

Hi!

This month I've spent quite some time working on vali, a C library and code generator for the Varlink IPC protocol. It was formerly named "varlinkgen", but the new name is shorter and more accurate (the library can be used without the code generator). I've fixed a bunch of bugs, updated the service implementation to use non-blocking IO, added some tests and support for continued calls (which are Varlink's way to emit events from a service). I've also written a patch to port the kanshi output configuration tool to vali.

Speaking of kanshi, I've released version 1.8. A new kanshictl status command shows the current mode, and wildcard patterns are now supported to match outputs. I want to finish up relative output positioning for the next release, but some tricky usability issues need to be sorted out first.

Support for toplevel capture in xdg-desktop-portal-wlr has been merged. This was the last missing piece to be able to share an individual window from Web browsers. libdisplay-info v0.3 has been released with support for many new CTA data blocks and groundwork for DisplayID v2. José Expósito has sent libdrm and drm_info patches to add user-space support for the special "faux" bus used in cases where a device isn't backed by hardware (up until now, the platform bus was abused).

The Goguma mobile IRC client now displays a small bubble when someone else mentions you, making these easier to spot at a glance:

Jean THOMAS has added a new option to choose between the in-app Web view and an external browser when opening links. Hubert Hirtz has tweaked the login forms to play better with the autofill feature some password managers provide.

I've released go-imap v2 beta 6, with support for SPECIAL-USE and CHILDREN thanks to Dejan Štrbac and legacy RECENT thanks to fox.cpp. I'd like to eventually ship v2, but there are still some rough edges that I'd like to smooth out. I now realize it's been more than 2 years since the first v2 alpha release, maybe I should listen a bit more to my bio teacher who used to repeat "perfect is the enemy of good".

Anyways, that's all for now, see you next month!

16 Aug 2025 10:00pm GMT