Update on what happened across the GNOME project in the week from October 25 to November 01.

Open source is more than just writing code; it's about people and the community. Right now, the world faces numerous crises, and this past week, another tragedy occurred - one that also affects members of the GNOME community.

Manu (he/they/she) says

The Valencian Country, among other Spanish autonomies has been hit by the worst natural disaster in its history. Entire villages have been completely flooded. There are more than 200 deaths so far that we know of, and more than 2000 people missing.

If you wish to help, Caritas is a trustful organization to donate to:

ES02 2100 8734 6113 0064 8236

Any donation Apostrophe receives the next two months will be also donated to one of the local Horta Sud associations that are working on the field. I will be also helping were help is needed.

GNOME Core Apps and Libraries

Libadwaita

Building blocks for modern GNOME apps using GTK4.

Alice (she/her) reports

Peter Eisenmann added the :visible-page-tag property to AdwNavigationView - a helper for checking the current page by its tag

Alice (she/her) reports

the style class .dim-label that has always had a misleading name has been soft deprecated in favor of .dimmed. The old style still works same as before

Third Party Projects

Jan-Willem announces

This week I released Java-GI version 0.11.0! Java-GI is a GObject-Introspection bindings generator for Java, using the brand new foreign function interface of OpenJDK 22. It can be used to develop GNOME apps in Java.

This release features a lot of fixes and improvements, so make sure to check out the release notes.

For more information about Java-GI, visit the website, where you will find code samples in both Java and Kotlin. Additionally, the Gtk "Getting started guide" has been ported to Java and is now available here, and a couple new examples were added to the java-gi-examples repository.

Gianni Rosato says

We've got a new Aviator release for you! It's packed with small bug fixes and an SVT-AV1-PSY update.

Bug Fixes:

• We fixed the hicolor icon that was mislabeled as scalable.
• We also fixed the audio bitrate resetting when you open a new file.

SVT-AV1-PSY v2.3.0 Improvements for Aviator:

• You can now encode with odd (non-mod2) dimensions.
• You can also encode at resolutions lower than 64x64, all the way down to 4x4.
• The color reproduction and overall picture quality will be better when you disable "Perceptual Tuning."
• The color reproduction and overall picture quality with "Perceptual Tuning." disabled has improved.
• There will be general perceptual fidelity improvements when you enable "Perceptual Tuning."
• There will be general performance improvements, especially on ARM platforms.

Other Changes:

• We removed the sharpness usage when "Perceptual Tuning" is enabled.
• We've updated FFmpeg to version 7.1.
• We've updated llvm to version 19 for project compilation.
• We've updated to GNOME SDK 47.

Enjoy the new Aviator release! ✈️

Parabolic

Download web video and audio.

Nick says

Parabolic V2024.10.3 is here! This update introduces some new features, including the ability to select a batch txt file with multiple URLs for validation, and fixes many bugs regarding website validation, localization of the app on Windows, and crashes on Linux.

Here's the full changelog:

• Added support for selecting a batch file with multiple URLs to validate instead of validating a single URL at a time
• Added a recovery mode where downloads that were running/queued will be restored when the application is restarted after a crash
• User entered file names will now be correctly normalized and validated in the Add Download dialog
• Fixed an issue where YouTube tabs were not correctly validated
• Fixed an issue where the app's documentation was not accessible
• Fixed an issue where UTF-8 characters were not displayed correctly on Windows
• Fixed an issue where playlist names were not normalized on Windows
• Fixed an issue where the row animations were choppy using aria2c on Linux
• Fixed an issue where the app would crash when stopping all downloads on Linux
• Updated yt-dlp to 2024.10.22

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

😱 What's that behind you⁉️ Oh, that's the new Fractal 9 release❣️ 😁 🎃

• We switched to the glycin library (the same one used by GNOME Image Viewer) to load images, allowing us to fix several issues, like supporting more animated formats and SVGs and respecting EXIF orientation.
• The annoying bug where some rooms would stay as unread even after opening them is now a distant memory.
• The media cache uses its own database that you can delete if you want to free some space on your system. It will also soon be able to clean up unused media files to prevent it from growing indefinitely.
• Sometimes the day separators would show up with the wrong date, not anymore!
• We migrated to the new GTK 4.16 and libadwaita 1.6 APIs, including CSS variables, AdwButtonRow and AdwSpinner.
• We used to only rely on the secrets provider to tell us which Matrix accounts are logged-in, which caused issues for people sharing their secrets between devices. Now we also make sure that there is a data folder for a given session before trying to restore it.
• Our notifications are categorized as coming from an instant messenger, so graphical shells that support it, such as Phosh, can play a sound for them.
• Some room settings are hidden for direct chats, because it does not make sense to change them in this type of room.
• The size of the headerbar would change depending on whether the room has a topic or not. This will not happen anymore.

As usual, this release includes other improvements and fixes thanks to all our contributors, and our upstream projects.

We want to address special thanks to the translators who worked on this version. We know this is a huge undertaking and have a deep appreciation for what you've done. If you want to help with this effort, head over to Damned Lies.

This version is available right now on Flathub.

We have a lot of improvements in mind for our next release, but if you want a particular feature to make it, the surest way is to implement it yourself! Start by looking at our issues or just come say hello in our Matrix room.

Dev Toolbox

Dev tools at your fingertips

Alessandro Iepure announces

After a long year of coding on and off (and balancing a lot of real life and university work!), I'm happy to finally share a new Dev Toolbox update! 🎉

This release packs a completely revamped UI for a smoother experience and new search functionality, making it even easier to find exactly the tool you need. You can also now mark your favorite tools to keep them in their own special menu, ready for quick access. And the fun doesn't stop there; let me introduce three new tools:

• JavaScript & CSS Minifiers to help you shrink those files down
• A handy Base64 Encoder (huge thanks to @amersaw for the contribution!)

Plus, a handful of smaller improvements and bug fixes are sprinkled in to make your experience even better.

A huge shoutout to the translators who helped make this app accessible to more people around the world! 🌍

Dev Toolbox is available right now on Flathub.

Events

devrtz reports

📢 🎉.This week the FOSS on mobile devices Call for Proposals has been opened for FOSDEM 2025 🎉. 📢

We are excited to have your presentations, demos and more! 📈 Showcase (and witness) the latest and greatest in Mobile Linux technologies ☎️ next year in Brussels 🚀

For more information, see this post on devrtz fosstodon post

\o/ We hope to see you there \o/

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!

01 Nov 2024 12:00am GMT

Approximately four years ago, I published the first release of ASHPD, one of my first Rust libraries, with the simple goal of making it easy to use XDG portals from Rust.

Since then, the library has grown to support all available portals and even includes a demo application showcasing some of these features.

Let's look at an example: the org.freedesktop.portal.Account portal. From the client side, an API end-user can request user information with the following code:

use ashpd::desktop::account::UserInformation;

async fn run() -> ashpd::Result<()> {
    let response = UserInformation::request()
        .reason("App would like to access user information")
        .send()
        .await?
        .response()?;

    println!("Name: {}", response.name());
    println!("ID: {}", response.id());

    Ok(())
}

This code calls the org.freedesktop.portal.Account.GetUserInformation D-Bus method, which xdg-desktop-portal will "redirect" to any portal frontend implementing the org.freedesktop.impl.portal.Account D-Bus interface.

So, how can you provide an implementation of org.freedesktop.impl.portal.Account in Rust? That's exactly what Maximiliano and I have been working on, building on the solid foundations we established earlier. I'm thrilled to announce that we finally shipped this functionality in the 0.10 release!

The first step is to implement the D-Bus interface, which we hide from the API's end-user using traits.

use ashpd::{
    async_trait,
    backend::{
        account::{AccountImpl, UserInformationOptions},
        request::RequestImpl,
        Result,
    },
    desktop::account::UserInformation,
    AppID, WindowIdentifierType,
};

pub struct Account;

#[async_trait]
impl RequestImpl for Account {
    async fn close(&self) {
        // Close the dialog
    }
}

#[async_trait]
impl AccountImpl for Account {
    async fn get_user_information(
        &self,
        _app_id: Option<AppID>,
        _window_identifier: Option<WindowIdentifierType>,
        _options: UserInformationOptions,
    ) -> Result<UserInformation> {
        Ok(UserInformation::new(
            "user",
            "User",
            url::Url::parse("file://user/icon").unwrap(),
        ))
    }
}

Pretty straightforward! With the D-Bus interface implemented using ASHPD wrapper types, the next step is to export it on the bus.

use futures_util::future::pending;

async fn main() -> ashpd::Result<()> {
    ashpd::backend::Builder::new("org.freedesktop.impl.portal.desktop.mycustomportal")?
        .account(Account)
        .build()
        .await?;

    loop {
        pending::<()>().await;
    }
}

And that's it-you've implemented your first portal frontend!

Currently, the backend feature doesn't yet support session-based portals, but we hope to add that functionality in the near future.

With over 1 million downloads, ASHPD has come a long way, and it wouldn't have been possible without the support and contributions from the community. A huge thank you to everyone who has helped make this library what it is today.

01 Nov 2024 12:00am GMT

The Bargain-Finder-inator 5000: One programmer's quest for a new flat

Or how I managed to get a reasonably priced apartment offer despite estate agencies

I think every one of us had to go through the hell that's searching for a new place to live. The reasons may be of all kinds, starting with moving between jobs or random life events, ending with your landlord wanting to raise your rent for fixing his couch despite your 3 years of begging for him to do so. You can guess my reasoning from that totally not suspiciously specific example, one thing's for certain - many of us, not lucky enough to be on their own yet, have to go through that not very delightful experience.

One major problem when scraping those online market websites, is that you're not the only one desperately doing so. And if it was only for the fellow lost souls who are trying to make ends meet, oh no - many real estate agencies say hello there as well. So when a very good offer finally comes up, one that you've been dreaming your whole life kind of one, you grab that phone and call them not maybe, but may they please-oh-lord pick up. Despite you wasting no breath, chances are that when you enthusiastically call them (after correcting the typos in the phone number you made out of excitement), you're already too late. Even though you ended up manually checking the damn website every 20 minutes (yup, I set an alarm), and you called after only a quarter, you were still not fast enough and there are already four people in line before you. Which in case of a good offer means it's as good as doughnuts at work you heard they were giving out to buy your sympathy for the corporate - gone even faster than they have probably arrived. Yup, that's basically the housing market situation in Poland, yay \o/

But do not abandon all hope ye who enter here - after having only a couple of mental break downs my friend sent me a link to a program on github, that was supposed to scrap our local market website and give instance notice about new offers. The web page did have a similar function, but it only worked in theory - the emails about the "latest" offers came only once a day, not to mention the fact that they were from the day before. Oh well, in that case saying goodbye to the 20 minute alarm sounded like a dream come true, so I tried to configure the program olx-scraper to my needs. However, it turned out to be pretty useless as well - it would repeatedly fetch a whole list of offers from only one page of search results, and compare its size between iterations. If the length of such list increased, it would theoretically mean that there are new offers, and the program would send a mail notification that contained the whole list. While this approach kinda worked for searches that returns only a few results, the whole idea fell apart when there were more than could fit in one page. In that case the number of offers would seem to remain constant, and new offers would be missed. Another room for improvement was in lack of ability to ignore certain kinds of offers, such as ads, and not so helpful emails, which could just give you what you're looking for - the newest offer, instead of the whole list.

Here comes the sun in the form of the Bargain-Finder-inator 5000 to the rescue! I quickly realized that a few patches was not enough to fix the old program for my (or frankly saying anyone's) use case and re-wrote the whole searching algorithm, eventually leading to a whole new program. The original name was "Wyszukiwator-Mieszkań 5000", inspired by Dr. Doofenschmirtz various schemes and inventions, and roughly translates to "Searcher-Of-Flats 5000". However, as the project grew beyond the real estate market, I needed a new name that would reflect that - it also needed to be slightly more accessible for foreigners than our oh how beautiful polish words. So I came up with the current one, with the best fitting abbreviation: bf5000. I think it's kind of neat :)

Totally accurate photograph of me giving birth to Bargain-Finder-inator 5000 circa 2024, colorized

What Bargain-Finder-inator 5000 dutifully does is monitor a link you serve to it, pointing to an online marketplace, be it for a real estate market or any other you can think of. The catch is that it needs to be supported, but writing a new backend shouldn't be too much of a hassle, and when it is you can simply copy paste the URL of your search with all the necessary filters specified, and give it to bf5000. You also need to specify the delay between each check for new offers, which consists of fetching only the latest offer, and comparing it with the previous "latest". If they don't match, then we are in for some goodies - an email notification with the link to the latest offer will be sent, so you need to specify the email title, addresses and the whole provider too. For more information, check out the repository on gitlab.

So, don't wait no more for better days, and be part of the change now! We can take back what's rightfully ours from those money-hungry real estate agencies! When I say Bargain, you say Finder-inator 5000! You get the idea.

31 Oct 2024 10:52am GMT

A few months ago this happened.

Which, for those of you not up to date on your 1960s British television, is to say that I've resigned. I'm currently enjoying the unemployed life style. No, that is not me being cheeky or ironic. I'm actually enjoying being able to focus on my own free time projects and sleeping late.

Since I'm not a millionaire at some point I'll probably have to get a job again. But not for at least six months. Maybe more, maybe less, we'll see what happens.

This should not affect Meson users in any significant way. I plan to spend some time to work on some fundamental issues in the code base to make things better all round. But the most important thing for now is to land the option refactor monster.

30 Oct 2024 9:25am GMT

GNOME Mobile

Making GNOME adapt to form factors beyond desktop and laptop computers is an ongoing trend that can be dated as early as the late 2000s, when Maemo provided a GNOME-based UI to phones like the Nokia N810 or the Nokia N900. Later, prototype versions of GNOME Shell had a netbook-friendly design that got course-corrected for its first release in 2011, keeping GNOME competent on larger screens.

GNOME 3 was designed with touchscreens in mind, especially touchscreen-equiped netbooks and laptops, with some foray into large touch-only devices like kiosks. With its touch-capabilities and minimalist touch-friendly design, GNOME 3 offered a good base to adapt to even smaller touch-only form factors like tablets and smartphones.

In the late 2010 two Linux smartphones got developed concurrently, Purism's Librem 5 and Pine64's PinePhone. Purism choose GNOME as the UI for its phone and invested in the development of the Phosh mobile-first shell for GNOME and into making GNOME apps adapt to smartphones. The GNOME community pretty widely embraced adaptiveness, which led to the creation of GNOME's platform library libadwaita. At the same time, community-driven projects like postmarketOS and Mobian offered support for these smartphones and contributed to the development of this mobile-friendly software stack, including contributions to GNOME.

While these devices' reception was polarizing, the Linux community was motivated enough to pursue what they initiated, leading to the birth of GNOME Shell Mobile and to the broadening of supported devices. While GNOME Shell got forked to make it fit smartphones, it is only to prototype this mobile support freely. Ultimately the goal is the this support into Shell, making it adapt from desktops to smartphones. This still overall prototypal support for modern smartphones from GNOME and the initiative that supports it are colloquially referred to as GNOME Mobile.

Testing GNOME Mobile

The GNOME release team defines what constitues the canonical core GNOME stack, and describes it in the gnome-build-meta repository. GNOME OS is built based on this description and is used to test GNOME, ensuring its components are correctly integrated and interact well together. openQA is a high-level and automated OS testing tool, and in 2021, Codethink brought GNOME an openQA instance that is used to test GNOME OS automatically rather than manually. The tests are ran in virtual machines thanks to QEMU.

Testing GNOME on smartphones implies testing its mobile-specific stack on smartphone-like devices the same way we test the rest of GNOME. Hardware requirements for GNOME are pretty loosely defined, and the only real requirement for smartphones is that apps designed for them should fit in a 360 × 294px window, so they can fit a 360px wide screen in portrait mode and a 360px tall screen in landscape mode, minus the space reserved for Shell. To that we can safely assume that a smartphone reports having a handset chassis type, that it has a touchscreen as its main input method, that it should work without a keyboard and a pointing device, that its screen is 9:16 or taller, and that the its has a high pixel density and should be used with an matching integer scaling factor. For reference, here is the pixel density of some de-facto reference GNOME smartphones.

Building an automated test suite for GNOME Mobile in openQA has already been attempted earlier this year by Dorothy Kabarozi and Tanju Acheleke, and they built the gnome_mobile test suite. Last month I got offered by Codethink the opportunity to continue that effort, thanks to them for sponsoring that work.

I've learned Dorothy and Tanju encountered various issues that prevented them from doing proper mobile tests, and the produced suite tests apps on a regular desktop but with their windows resized to smartphone-like sizes. The goal of my project was to make the test VM provide a smartphone-like screen size and chassis type.

Pixel Density

I've first tweaked the VM's screen to be 360 × 720, but such a small resolution isn't supported and the tests automatically fail. No big deal, smartphones run on high density devices and we want to test UI scaling, so I decided to switch to 720 × 1440 with 200% scaling… except of course the tests weren't scaled, why would they be?

To set the scaling factor, we first have to complete the system's initial setup unscaled, and then once finally logged into GNOME Shell, we discover Settings doesn't let us change it. This happens because Mutter enables changing the scaling factor only on arbitrarily large-enough resolutions, and 720 × 1440@2 is below the required threshold. At this point, I faced the same issues as Dorothy and Tanju and didn't go any further, but let's dig a bit more.

Besides Mutter's arbitrary limitation, we are facing the need to set the display's physical size or pixel density so the OS can adapt to it from the very beginning. The best way to do this it is to have an EDID declaring our display's resolution and physical size, we just need to find the best way to generate it and to use it. We could use a tool like qemu-edid to generate the EDID we want, inject it into the OS, and override the one from the virtual machine, but it would be a messy and dirty workaround.

Our test suite uses QEMU with virtio-vga which offers the following properties:

#define VIRTIO_GPU_BASE_PROPERTIES(_state, _conf)                       \
    DEFINE_PROP_UINT32("max_outputs", _state, _conf.max_outputs, 1),    \
    DEFINE_PROP_BIT("edid", _state, _conf.flags, \
                    VIRTIO_GPU_FLAG_EDID_ENABLED, true), \
    DEFINE_PROP_UINT32("xres", _state, _conf.xres, 1280), \
    DEFINE_PROP_UINT32("yres", _state, _conf.yres, 800)

We already use xres and yres to set the display's resolution, but there also is the edid property, that openQA toggles on to make QEMU generate an EDID describing the virtual machine's screen. QEMU has all that's needed to generate and expose an EDID with the right pixel density, except for a way to let the user override the pixel density that QEMU defaults to 100 DPI.

We could imagine exposing the dpi parameter as a virtio-vga property, making QEMU able to emulate devices with a high density screen, and helping us run mobile tests.

Chassis Type

Then I've looked at giving the VM a smartphone's chassis type. The chassis type is defined in the SMBIOS, let's read about it in the reference specification:

7.4 System Enclosure or Chassis (Type 3)

The information in this structure (see Table 16) defines attributes of the system's mechanical enclosure(s). For example, if a system included a separate enclosure for its peripheral devices, two structures would be returned: one for the main system enclosure and the second for the peripheral device enclosure. The additions to this structure in version 2.1 of this specification support the population of the CIM_Chassis class.

Offset	Name	Length	Value	Description
05h	Type	BYTE	Varies	Bit 7 Chassis lock is present if 1. Otherwise, either a lock is not resent or it is unknown if the enclosure has a lock. Bits 6:0 Enumeration value; see below.

7.4.1 System Enclosure or Chassis Types

Table 17 shows the byte values for the System Enclosure or Chassis Types field. NOTE Refer to 6.3 for the CIM properties associated with this enumerated value.

Byte Value	Meaning
01h	Other
0Bh	Hand Held

For our QEMU VM to declare being a handheld device, we need to set the SMBIOS structure type 3's Type field to 0x0B.

According to its documentation, QEMU lets us set some of the SMBIOS fields conveniently via the -smbios parameter. For type 3 we are allowed -smbios type=3[,manufacturer=str][,version=str][,serial=str][,asset=str][,sku=str], so unfortunately it doesn't let us set the chassis type. QEMU also let's us set the whole SMBIOS via -smbios file=binary, so we could write the SMBIOS ourselves and feed it to QEMU, but it would be a dirty workaround to an issue that can be fixed. QEMU has all that's needed to generate an SMBIOS with the right chassis type, except for a way to let the user override the chassis type that QEMU defaults to 0x01 meaning other.

We could imagine adding a chassis=… parameter to -smbios type=3, making QEMU able to fake devices types, and helping us run mobile tests.

Clearing The Way

Adding the dpi and chassis parameters to QEMU's CLI shouldn't be too hard, the internals are there, it's just a matter of exposing these variables. The important part is of course to work with the QEMU project, making sure they are happy with the proposed modifications. If you want to work on that, please let me know! And if you want to contribute to GNOME Mobile's automated test suite, feel free to do so on the related issue on GNOME's GitLab instance.

Thanks again to Codethink for sponsoring that work.

27 Oct 2024 11:00pm GMT

• Call with Dave, partner call, lunch with E. and J. Chased people's annual reviews. Sync with Sven & Caolan.
• Impressed to read about the expulsion of Russian maintainers from the Linux Kernel by gregkh, with rationale from James. Raising awareness of the origin of critical software used in your supply-chain is important, even if FLOSS - sad as it may be for various blameless individuals.
• Tea with J. and E. - who left to the StAG Travs weekend. Poke at some code.

25 Oct 2024 9:00pm GMT

Update on what happened across the GNOME project in the week from October 18 to October 25.

GNOME Core Apps and Libraries

Maps

Maps gives you quick access to maps all across the world.

mlundblad says

Maps now has a redesigned UI for editing points-of-interests in OpenStreetMap, using libadwaita widgets, and AdwDialog.

GLib

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

Philip Withnall announces

Jialu Zhou has renamed the methods in GUnixMountEntry in GLib so they can be introspected properly (previously they couldn't be used easily from introspected languages); see https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4337

GNOME Incubating Apps

Pablo Correa Gomez announces

Qiu Wenbo implemented using colors for highlight annotations in Papers! This was an often requested feature made possible due to the new mockups, and lots of refactoring under-the-hood

Pablo Correa Gomez reports

@omthorat implemented the new annotation window mockups in Papers, giving annotated documents a great new appearance! You can get the latest development snapshot in gnome-nightly

GNOME Circle Apps and Libraries

Warp

Fast and secure file transfer.

Fina says

Warp 0.8 was released today. Warp allows you to securely send files to each other via the internet or local network by exchanging a word-based code, or scanning a QR code.

This release features quite a few stability improvements for QR code scanning, and lots of translation updates! The flatpak release was updated to the latest runtime and now supports accent colors.

Biblioteca

Read GNOME documentation offline

Akshay Warrier reports

Biblioteca 1.5 is now available on Flathub!

The notable changes in this release are:

• Updated Flatpak runtime to GNOME 47
• Added gom documentation
• Updated various library docs (libportal 0.8.1, vte 0.78, libshumate 1.3.0, libspelling 0.4.2)
• Added support to persist window size across sessions
• Removed irrelevant context menu entries in the webview

Amberol

Plays music, and nothing else.

Emmanuele Bassi announces

Amberol 2024.2 is now available on Flathub! Amberol is a small music player with no delusions of grandeur, focused on the task of playing your local music in the simplest way possible. In this new release you'll find:

• support for external album cover images named folder (in both PNG and JPEG image file formats) in the same directory as the songs
• the file selection dialogs used to add songs and folders will start from the XDG Music directory, if one is set
• an updated MPRIS implementation, dropping the unmaintained mpris-player crate in favour of the mpris-server one
• an updated playback implementation, using the GstPlay API instead of the deprecated GstPlayer
• various style updates to reflect the changes in libadwaita UI elements
• lots of localisation updates

As usual, you can install Amberol from Flathub.

Third Party Projects

Konstantin Tutsch says

Lock is now available on Flathub! Lock is a graphical front-end for GnuPG (GPG) making use of a beautiful LibAdwaita GUI.

Process text and files:

• Encryption
• Decryption
• Signing
• Verification

Manage your GnuPG keyring:

• Generate new keypairs
• Import keys
• Export public keys
• View expiry dates
• Remove keys

Download on Flathub.

Hari Rana | TheEvilSkeleton says

Upscaler 1.4.0 was just released! Upscaler is an app that allows you to upscale and enhance images, be it your photos, digital art, and more.

This release introduces scaling factors, allowing you to upscale between a factor of 2 and 4. The image loading system has been reworked to decrease overall memory consumption. The preview image now has a drop shadow to better make the image distinguishable. Lastly, it fixes a bug where small window sizes made the preview image disappear.

Miscellaneous

Alice (she/her) announces

I blogged about implementing Steam Deck gamepad support in libmanette: https://blogs.gnome.org/alicem/2024/10/24/steam-deck-hid-and-libmanette-adventures/

GNOME Websites

Allan Day reports

GNOME's wiki was officially retired this week. Its functions have already been replaced by other sites and, if you do need information from the old wiki, a static archive of the site is still available at wiki.gnome.org.

For more information, see the wiki the migration guide.

Events

Kristi Progri announces

We're excited to announce that registration for GNOME ASIA 2024 is now open! For more details, feel free to check out our blogpost: https://foundation.gnome.org/2024/10/23/registration-now-open-for-gnome-asia-2024/

GNOME Foundation

Allan Day reports

The GNOME Foundation Board is looking for input on the future of GUADEC. Please comment on the Discourse thread with your opinions on where GUADEC should be located, and what its focus should be.

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!

25 Oct 2024 12:00am GMT

• Tech planning call, prep. call with sr. tech. & mgmt team. Mail chew left & right. Call with potential partner.
• J. out to see B&A for much of the day; struck by the nice WiFi network name: TellMyWifiLoverHer. Somehow managed to recover my thunderbird calendar tab: somehow I close it and don't easily find it again - each time a search; perhaps if the left-hand-side-bar buttons were to the right of the tabs there would be less wasted h-space, and more find-ability.
• Cyrille & Alex over for home-group, short study on Revelation 10.

24 Oct 2024 9:00pm GMT

Recently, I got a Steam Deck OLED. Obviously, one of the main reasons for that is to run a certain yet to be announced here emulation app on it, so I installed Bazzite instead of SteamOS, cleaned up the preinstalled junk and got a clean desktop along with the Steam session/gaming mode.

For the most part, it just works (in desktop mode, at least), but there was one problematic area: input.

Gamepad input

Gamepads in general are difficult. While you can write generic evdev code dealing with, say, keyboard input and be reasonably sure it will work with at least the majority of keyboards, that's not the case for gamepads. Buttons will use random input codes. Gamepads will assign different input types for the same control. (for example, D-pad can be presented as 4 buttons, 2 hat axes or 2 absolute axes). Linux kernel includes specialized hid drivers for some gamepads which will work reasonably well out of the box, but in general all bets are off.

Projects like SDL have gamepad mapping databases - normalizing input for all gamepads into a standardized list of inputs.

However, even that doesn't guarantee they will work. Gamepads will pretend to be other gamepads (for example, it's very common to emulate an Xbox gamepad) and will use incorrect mapping as a result. Some gamepads will even use identical IDs and provide physically different sets of buttons, meaning there's no way to map both at the same time.

As such, apps have to expect that gamepad may or may not work correctly and user may or may not need to remap their gamepad.

Steam controllers

Both the standalone Steam Controller and Steam Deck's internal gamepad pose a unique challenge: in addition to being gamepads with every problem mentioned above, they also emulate keyboard and pointer input. To make things more complicated, Steam has a built-in userspace HID driver for these controllers, with subtly different behavior between it and the Linux kernel driver. SteamOS and Bazzite both autostart Steam in background in desktop mode.

If one tries to use evdev in a generic way, same as for other gamepads, the results will not be pretty:

In desktop mode Steam emulates a virtual XInput (Xbox) gamepad. This gamepad works fine, except it lacks access to Steam and QAM buttons, as well as the 4 back buttons (L4, L5, R4, R5). This works perfectly fine for most games, but fails for emulators where in addition to the in-game controls you need a button to exit the game/open menu.

It also provides 2 action sets: Desktop and Gamepad. In desktop action set none of the gamepad buttons will even act like gamepad buttons, and instead will emulate keyboard and mouse. D-pad will act as arrow keys, A button will be Enter, B button will be Esc and so on. This is called "lizard mode" for some reason, and on Steam Deck is toggled by holding the Menu (Start) button. Once you switch to gamepad action set, gamepad buttons will act as a gamepad, with the caveat mentioned above.

Gamepad action set also makes the left touchpad behave differently: instead of scrolling and performing a middle click on press, it does a right click on press while moving finger on it does nothing.

hid-steam

Linux kernel includes a driver for these controllers, called hid-steam, so you don't have to be running Steam for it to work. While it does most of the same things Steam's userspace driver does, it's not identical.

Lizard mode is similar, the only difference is that haptic feedback on the right touchpad stops right after lifting finger instead of after the cursor stops, while left touchpad scrolls with a different speed and does nothing on press.

The gamepad device is different tho - it's now called "Steam Deck" instead of "Microsoft X-Box 360 pad 0" and this time every button is available, in addition to touchpads - presented as a hat and a button each (tho there's no feedback when pressing).

The catch? It disables touchpads' pointer input.

The driver was based on Steam Deck HID code from SDL, and in SDL it made sense - it's made for (usually fullscreen) games, if you're playing it with a gamepad, you don't need a pointer anyway. It makes less sense in emulators or otherwise desktop apps tho. It would be really nice if we could have gamepad input AND touchpads. Ideally automatically, without needing to toggle modes manually.

libmanette

libmanette is the GNOME gamepad library, originally split from gnome-games. It's very simple and basically acts as a wrapper around evdev and SDL mappings database, and has API for mapping gamepads from apps.

So, I decided to add support for Steam deck properly. This essentially means writing our own HID driver.

Steam udev rules

First, hidraw access is currently blocked by default and you need an udev rule to allow it. This is what the well known Steam udev rules do for Valve devices as well as a bunch of other well known gamepads.

There are a few interesting developments in kernel, logind and xdg-desktop-portal, so we may have easier access to these devices in future, but for now we need udev rules. That said, it's pretty safe to assume that if you have a Steam Controller or Steam Deck, you already have those rules installed.

Writing a HID driver

Finally, we get to the main part of the article, everything before this was introduction.

We need to do a few things:

1. Disable lizard mode on startup
2. Keep disabling it every now and then, so that it doesn't get reenabled (this is unfortunately necessary and SDL does the same thing)
3. Handle input ourselves
4. Handle rumble

Both SDL and hid-steam will be excellent references for most of this, and we'll be referring to them a lot.

For the actual HID calls, we'll be using hidapi.

Before that, we need to find the device itself. Raw HID devices are exposed differently from evdev ones, as /dev/hidraw* instead of /dev/input/event*, so first libmanette needs to search for those (either using gudev, or monitoring /dev when in flatpak).

Since we're doing this for a very specific gamepad, we don't need to worry about filtering out other input devices - this is an allowlist, so we just don't include those. So we just match by vendor ID and product ID. Steam Deck is 28DE:1205 (at least OLED, but as far as I can tell the PID is the same for LCD).

However, there are 3 devices like that: the gamepad itself, but also its emulated mouse and keyboard. Well, sort of. Only hid-steam uses those devices, Steam instead sends them via XTEST. Since that obviously doesn't work on Wayland, there's instead a uinput device provided by extest.

SDL code tells us that only the gamepad device can actually receive HID reports, so the right device is the one that allows to read from it.

Disabling lizard mode

Next, we need to disable lizard mode. SDL sends an ID_CLEAR_DIGITAL_MAPPINGS report to disable keyboard/mouse emulation, then changes a few settings: namely, disables touchpads. As mentioned above, hid-steam does the same thing - it was based on this code.

However, we don't want to disable touchpads here.

What we want to do instead is to send a ID_LOAD_DEFAULT_SETTINGS feature report to reset settings changed by hid-steam, and then only disable scrolling for the left touchpad. We'll make it right click instead, like Steam does.

This will keep the right touchpad moving pointer, but the previous ID_CLEAR_DIGITAL_MAPPINGS report had disabled touchpad clicking, so we also need to restore it. For that, we need to use the ID_SET_DIGITAL_MAPPINGS report. SDL does not have an existing struct for its payload (likely because of struct padding issues), so I had to figure it out myself. The structure is as follows, after the standard zero byte and the header:

• 8 bytes: buttons bitmask
• 1 byte: emulated device type
• 1 byte: a mouse button for DEVICE_MOUSE, a keyboard key for DEVICE_KEYBOARD, etc. Note that the SDL MouseButtons struct starts from 0 while the IDs Steam Deck accepts start from 1, so MOUSE_BTN_LEFT should be 1, MOUSE_BTN_RIGHT should be 2 and so on.

Then the structure repeats, up to 6 times in the same report.

ID_GET_DIGITAL_MAPPINGS returns the same structure.

So, setting digital mappings for:

• STEAM_DECK_LBUTTON_LEFT_PAD, DEVICE_MOUSE, MOUSE_BTN_RIGHT
• STEAM_DECK_LBUTTON_RIGHT_PAD, DEVICE_MOUSE, MOUSE_BTN_LEFT

(with the mouse button enum fixed to start from 1 instead of 0)

reenables clicking. Now we have working touchpads even without Steam running, with the rest of gamepad working as a gamepad, automatically.

Keeping it disabled

We also need to periodically do this again to prevent hid-steam from reenabling it. SDL does it every 200 updates, so about every 800 ms (update rate is 4 ms), and the same rate works fine here. Note that SDL doesn't reset the same settings as initially, but only SETTING_RIGHT_TRACKPAD_MODE. I don't know why, and doing the same thing did not work for me, so I just use the same code as detailed above instead and it works fine. It does mean that clicks from touchpad presses are ended and immediately restarted every 800 ms, but it doesn't seem to cause any issues in practice, even with e.g. drag-n-drop)

Handling gamepad input

This part was straightforward. Every 4 ms we poll the gamepad and receive the entire state in a single struct: buttons as a bitmask, stick coordinates, trigger values, but also touchpad coordinates, touchpad pressure, accelerometer and gyro.

Right now we only expose a subset of buttons, as well as stick coordinates. There are some very interesting values in the button mask though - for example whether sticks are currently being touched, and whether touchpads are currently being touched and/or pressed. We may expose that in future, e.g. having API to disable touchpads like SDL does and instead offer the raw coordinates and pressure. Or do things on touch and/or click. Or send haptic feedback. We'll see.

libmanette event API is pretty clunky, but it wasn't very difficult to wrap these values and send them out.

Rumble

For rumble we're doing the same thing as SDL: sending an ID_TRIGGER_RUMBLE_CMD report. There are a few magic numbers involved, e.g. for the left and right gain values - originated presumably in SDL, copied into hid-steam and now into libmanette as well ^^

Skipping duplicate devices

The evdev device for Steam Deck is still there, as is the virtual gamepad if Steam is running. We want to skip both of them. Thankfully, that's easily done via checking VID/PID: Steam virtual gamepad is 28DE:11FF, while the evdev device has the same PID as the hidraw one. So, now we only have the HID device.

Behavior

So, how does all of this work now?

When Steam is not running, libmanette will automatically switch to gamepad mode, and enable touchpads. Once the app exits, it will revert to how it was before.

When Steam is running, libmanette apps will see exactly the same gamepad instead of the emulated one. However, we cannot disable lizard mode automatically in this state, so you'll have to hold Menu button, or you'll get input from both the gamepad and keyboard. Since Steam doesn't disable touchpads in gamepad mode, they will still work as expected, so the only caveat is needing to hold Menu button.

So, it's not perfect, but it's a big improvement from how it was before.

Mappings

Now that libmanette has bespoke code specifically for Steam Deck, there are a few more questions. This gamepad doesn't use mappings, and apps can safely assume it has all the advertised controls and nothing else. They can also know exactly what it looks like. So, libmanette now has ManetteDeviceType enum, currently with 2 values: MANETTE_DEVICE_GENERIC for evdev devices, and MANETTE_DEVICE_STEAM_DECK, for Steam Deck. In future we'll likely have more dedicated HID drivers and as such more device types. For now though, that's it.

The code is here, though it's not merged yet.

Big thanks to people who wrote SDL and the hid-steam driver - I would definitely not be able to do this without being able to reference them. ^^

23 Oct 2024 10:44pm GMT

(I worked on this feature last year, before being moved off desktop related projects, but I never saw it documented anywhere other than in the original commit messages, so here's the opportunity to shine a little light on a feature that could probably see more use)

The new usb_set_wireless_status() driver API function can be used by drivers of USB devices to export whether the wireless device associated with that USB dongle is turned on or not.

To quote the commit message:

This will be used by user-space OS components to determine whether the
battery-powered part of the device is wirelessly connected or not,
allowing, for example:
- upower to hide the battery for devices where the device is turned off
  but the receiver plugged in, rather than showing 0%, or other values
  that could be confusing to users
- Pipewire to hide a headset from the list of possible inputs or outputs
  or route audio appropriately if the headset is suddenly turned off, or
  turned on
- libinput to determine whether a keyboard or mouse is present when its
  receiver is plugged in.

This is not an attribute that is meant to replace protocol specific
APIs [...] but solely for wireless devices with
an ad-hoc "lose it and your device is e-waste" receiver dongle.
 

Currently, the only 2 drivers to use this are the ones for the Logitech G935 headset, and the Steelseries Arctis 1 headset. Adding support for other Logitech headsets would be possible if they export battery information (the protocols are usually well documented), support for more Steelseries headsets should be feasible if the protocol has already been reverse-engineered.

As far as consumers for this sysfs attribute, I filed a bug against Pipewire (link) to use it to not consider the receiver dongle as good as unplugged if the headset is turned off, which would avoid audio being sent to headsets that won't hear it.

UPower supports this feature since version 1.90.1 (although it had a bug that makes 1.90.2 the first viable release to include it), and batteries will appear and disappear when the device is turned on/off.

A turned-on headset

23 Oct 2024 12:06pm GMT

Registration for GNOME Asia 2024 is now open! This year's summit will be held from December 6-8, 2024, in the dynamic city of Bangalore, India, with both in-person and remote participation options.

GNOME Asia 2024 will feature a fantastic lineup of presentations and workshops centered around the latest innovations in the GNOME ecosystem and its community. Whether you're attending on-site in Bangalore or joining online from anywhere in the world, there's something for everyone.

The full conference schedule, including session and speaker details, will soon be available on the event website.

Registration is open to everyone-whether you're an experienced developer, new to the open-source world, or simply curious about what's happening in GNOME. We look forward to welcoming you, both in person and online, from December 6-8!

Become a GNOME Asia 2024 Sponsor!

We're still looking for sponsors for this year's summit. If you or your company are interested in sponsoring GNOME Asia 2024, please find more details and our sponsorship brochure on the event website or reach out to asia@gnome.org.

23 Oct 2024 8:12am GMT

22 Oct 2024 7:59pm GMT

It was long overdue, but better late than never! Shortwave 4.0 is now available on Flathub:

General

• New MPRIS media controls implementation with improved CPU usage
• Song notifications are disabled by default now
• No more loading on startup, stations now get directly retrieved from cached data
• Fixed issue which sometimes prevented loading more than 8 stations from library
• Refreshed user interface by making use of new Libadwaita widgets
• Large parts of the app were reworked, providing a solid foundation for the next upcoming features

Playback

• Last station now gets restored on app launch
• Redesigned player sidebar, allowing to control volume more easily
• New recording indicator showing whether the current playback is being recorded
• Fixed buffering issue which prevented playing new stations, especially after switching stations too fast
• Fixed issues which sometimes prevented that a song gets recorded
• Fixed issue that volume remains muted after unmuting

Station Covers

• More supported image file format for station covers
• Enhanced security by loading station covers using sandboxed Glycin image library
• Non square covers automatically get a blurred background
• New generated fallback for stations without any cover image
• Improved disk usage by automatically purging no longer needed cached data

Browse / Search

• More useful station suggestions by respecting configured system language / region
• Suggestions now get updated with every start, no longer always showing the same stations
• More accessible search feature, no longer hidden in a subpage
• Search results are no longer limited at 250 stations
• Faster and more efficient search by using new grid widgets

Chromecast

• Shortwave is now a registered Google Cast app, no longer relying on the generic media player
• New backend which greatly improves communication stability with cast devices
• Improved discovery of cast devices with lower CPU and memory usage
• Now possible to change the volume of a connected cast device

Enjoy!

18 Oct 2024 3:50pm GMT

1. Some historical background

The GNOME Infrastructure has been hosted as part of one of Red Hat's datacenters for over 15 years now. The "community cage", which is how we usually define the hosting platform that backs up multiple Open Source projects including OSCI, is made of a set of racks living within the RAL3 (located in Raleigh) datacenter. Red Hat has not only been contributing to GNOME by maintaining the Red Hat's Desktop Team operational, sponsoring events (such as GUADEC) but has also been supporting the project with hosting, internet connectivity, machines, RHEL (and many other RH products subscriptions). When the infrastructure was originally stood up it was primarily composed of a set of bare metal machines, workloads were not yet virtualized at the time and many services were running directly on top of the physical nodes. The advent of virtual machines and later containers reshaped how we managed and operated every component. What however remained the same over time was the networking layout of these services: a single L2 and a shared (with other tenants) public internet L3 domains (with both IPv4 and IPv6).

Recent challenges

When GNOME's Openshift 4 environment was built back in 2020 we had to make specific calls:

1. We'd have ran an Openshift Hyperconverged setup (with storage (Ceph), control plane, workloads running on top of the same subset of nodes)
2. The total amount of nodes we received budget for was 3, this meant running with masters.schedulable=true
3. We'd have kept using our former Ceph cluster (as it had slower disks, a good combination for certain workloads we run), this is however not supported by ODF (Openshift Data Foundation) and would have required some glue to make it completely functional
4. Migrating GNOME's private L2 network to L3 would have required an effort from Red Hat's IT Network Team who generally contributes outside of their working hours, no changes were planned in this regard
5. No changes were planned on the networking equipment side to make links redundant, that means a code upgrade on switches would have required a full services downtime

Over time and with GNOME's users and contributors base growing (46k users registered in GitLab, 7.44B requests and 50T of traffic per month on services we host on Openshift and kindly served by Fastly's load balancers) we started noticing some of our original architecture decisions weren't positively contributing to platform's availability, specifically:

1. Every time an Openshift upgrade was applied, it resulted in a cluster downtime due to the unsupported double ODF cluster layout (one internal and one external to the cluster). The behavior was stuck block devices preventing the machines to reboot with associated high IO (and general SELinux labeling mismatches), with the same nodes also hosting OCP's control plane it was resulting in API and other OCP components becoming unavailable
2. With no L3 network, we had to create a next-hop on our own to effectively give internet access through NAT to machines without a public internet IP address, this was resulting in connectivity outages whenever the target VM would go down for a quick maintenance

Migration to AWS

With budgets season for FY25 approaching we struggled finding the necessary funds in order to finally optimize and fill the gaps of our previous architecture. With this in mind we reached out to AWS Open Source Program and received a substantial amount for us to be able to fully transition GNOME's Infrastructure to the public cloud.

What we achieved so far:

1. Deployed and configured VPC related resources, this step will help us resolve the need to have a next-hop device we have to maintain
2. Deployed an Openshift 4.17 cluster (which uses a combination of network and classic load balancers, x86 control plane and arm64 workers)
3. Deployed IDM nodes that are using a Wireguard tunnel between AWS and RAL3 to remain in sync
4. Migrated several applications including SSO, Discourse, Hedgedoc

What's upcoming:

1. Migrating away from Splunk and use a combination of rsyslog/promtail/loki
2. Keep migrating further applications, the idea is to fully decommission the former cluster and GNOME's presence within Red Hat's community cage during Q1FY25
3. Introduce a replacement for master.gnome.org and GNOME tarballs installation
4. Migrate applications to GNOME's SSO
5. Retire services such as GNOME's wiki (MoinMoin, a static copy will instead be made available), NSD (authoritative DNS servers were outsourced and replaced with ClouDNS and GitHub's pipelines for DNS RRs updates), Nagios, Prometheus Blackbox (replaced by ClouDNS endpoints monitoring service), Ceph (replaced by EBS, EFS, S3)
6. Migrate smtp.gnome.org to OSCI in order to maintain current public IP's reputation

And benefits of running GNOME's services in AWS:

1. Scalability, we can easily scale up our worker nodes pool
2. We run our services on top of AWS SDN and can easily create networks, routing tables, benefit from faster connectivity options, redundant networking infrastructure
3. Use EBS/EFS, don't have to maintain a self-managed Ceph cluster, easily scale volumes IOPS
4. Use a local to-the-VPC load balancer, less latency for traffic to flow between the frontend and our VPC
5. Have access to AWS services such as AWS Shield for advanced DDOS protection (with one bringing down GNOME's GitLab just a week ago)

I'd like to thank AWS (Tom "spot" Callaway, Mila Zhou) for their sponsorship and the massive opportunity they are giving to the GNOME's Infrastructure to improve and provide resilient, stable and highly available workloads to GNOME's users and contributors base. And a big thank you to Red Hat for the continued sponsorship over more than 15 years on making the GNOME's Infrastructure run smoothly and efficiently, it's crucial for me to emphatise how critical Red Hat's long term support has been.

17 Oct 2024 12:25am GMT

I've participated in two internships this year, and interns - who are usually busy full-time students - often ask "How do you get time to contribute to open source?".

And the truth is that there's no secret formula. It's tricky to get paid to work on something that you give away for free, isn't it? Mostly I contribute to open source in free time, either after work hours, or occasionally during periods of downtime.

To my complete surprise I managed to buy a house this year and so I suddenly don't have any time after work. During the day most of my time is spent on proprietary customer-specific work, and after work I go to look at the house and try to figure out where to start with the whole thing. (By the way, does anyone around Santiago need a load of 1980s-style furniture made from chipboard?).

I'll still be participating in GNOME around desktop search and the openQA tests, answering questions and triaging bug reports, but I won't be driving any new stuff forwards.

Anyway, why is it interesting to blog about things I'm not doing?

I read this quote in LWN the other day:

Make it easy to quit - Actively celebrate people who step back from maintainer positions. Celebrate what they accomplished and what they are moving on to. Don't punish or otherwise shame quitting. This also incentivizes other people to step up, knowing that they don't necessarily have to do it forever.

- Rich Bowen, "Open Source Summit Vienna 2024"

At least in GNOME, we often don't do this. We don't celebrate what people *have achieved*, with I think one exception (the legendary "Pants of Thanks" ceremony).

We should do better at this. It's not that we don't appreciate each others work. But mostly we require the person doing the work to also be the one shouting loudly about it, before we notice. Is there a better way?

Another thing we don't do, by the way, is celebrate corporate participation. The great exception to this is the STF grant, and everyone involved in that did an excellent job of highlighting work which the STF grant enabled. We're less good at crediting all the work that happens thanks to paid engineers from Red Hat, Endless, Canonical, SUSE, and so on.

Another quote from this article:

Each generation of a project (ie open source but not only open source) is responsible for mentoring the next generation. When you mentor someone, spend time emphasizing that it's their job to mentor the next person, otherwise they will assume that it's your job. A failure to commuincate this will result in the eventual attrition and death of the community.

- Rich Bowen, "Open Source Summit Vienna 2024"

I quite like giving conference talks and I've been wondering what I could speak about, if I'm not driving any new development myself.

We now have 25 years of history in GNOME and it would be nice to give some talks about "How $thing works." Desktop search comes to mind here, of course. I also learned (against my will) a lot about initial-setup this year. So I might propose some talks along these lines. It seems like also a nice way to look back at work that's been done over the years, and give credit the people who have worked on these things over time, doing stuff that's often invisible.

On that topic, I want to highlight the excellent work done over the summer by our two GSoC interns Divyansh Jain and Rachel Tam, adding a web-based IDE to TinySPARQL that can run queries against the GNOME search database. You can read more about that both on Rachel's blog and on Demigod's blog. The idea behind this was making it easier to visualize how the LocalSearch index actually works, what is stored there, and what you can do with it. Hopefully this can lead into some interesting talks about search!

If you like this post, please leave a comment! You use the form below, or reply on the Fediverse to @samthursfield.wordpress.com@samthursfield.wordpress.com. I'm also on LinkedIn.

16 Oct 2024 11:00am GMT

Last weekend I went to Prague to represent Fedora at LinuxDays 2024. It's the biggest Linux event in the country with more than a thousand attendees and the Fedora booth is busy there every year.

Like last year the Fedora booth was colocated with the Red Hat booth. It made sense not only because there is a relationship between the two, but it had very practical reasons: I was the only person representing and staffing the Fedora booth and I appreciated help from my colleagues who watch over the Fedora booth when I took a break to have a meal or give a talk.

Post by @fedoracz@floss.social

View on Mastodon

The biggest magnet at our booth was again a macbook running Fedora Asahi Remix. I gave a talk about it which was only 20 minutes long and was intended as a teaser: here is an overview of the project and if you'd like to know and see more, come to your booth.

Fortunately just two days before the conference, the Asahi Linux project announced support for Steam via the Fex/muvm emulation, so I could utilize a large library of games I own have a license for on Steam. During the talk someone asked if it could run the Factorio game and it could, indeed.

Post by @fedoracz@floss.social

View on Mastodon

We also had a Fedora conference box which includes a Fedora Slimbook laptop. It was a nice contrast to the Macbook because Slimbook focuses on Linux whereas Apple doesn't care about Linux at all.

The booth was so busy that I was making a post about our presence for 2 hours because I couldn't find even a few minutes to finish it.

I also did a bit of user support. An older gentleman approached our booth stating that he had traveled 100km to get help. He had a dual boot of Fedora and Ubuntu and an Ubuntu update had broken the bootloader. Regenerating the GRUB resolved the issue.

Pavel Píša, a doctor from Czech University of Technology, invited me to their booth to check out Fedora Linux running on a Milk-V box with a RISC-V CPU. I left a flyer regarding an open Fedora QA position for RISC-V because Red Hat is currently looking for someone to test Fedora Linux on RISC-V.

Overall, the conference was a great experience, albeit tiring. I hope to attend next year again.

15 Oct 2024 3:44pm GMT