Hell yeah!! So many needed fixes that have been bugging me for a while are finally fixed!!

_{Anti Commercial-AI license (CC BY-NC-SA 4.0)}

Why should we have the same standard for two fundamentally different languages with distinct design philosophies and features?
Even if the C coding standard was used, it fundamentally will not make Rust more legible to C-only kernel devs. Imposing the C coding standard on Rust would be fundamentally counterproductive, as it would undermine Rust’s safety and productivity features. Rust’s coding guidelines align with its design principles, promoting idiomatic Rust code that leverages language features like ownership, borrowing, and lifetimes.
This ensures that Rust code in the kernel is safe, concurrent, and maintainable, while adhering to the language’s best practices. While the C coding standard served its purpose well for the procedural C language, it is ill-suited for a modern language like Rust, which has different priorities and language constructs. Having separate coding standards allows each language to shine in its respective domain within the kernel, leveraging their strengths while adhering to their respective design philosophies. Having separate coding standards for C and Rust within the kernel codebase is the sensible approach.

In any case, it’s the temporary file directory so it should be fine to delete them manually.
Just make sure that podman isn’t running while you’re deleting them, assuming it is podman.

This error is caused by a compatibility issue between Wine’s RandR (X11 display extension) implementation and the NVIDIA proprietary drivers.

a. Install winetricks and run winetricks orm=backbuffer glsl=disable This will configure Wine to use a different rendering method that is compatible with the NVIDIA drivers.

&/Or

b. Use a tool like Q4Wine to configure the Wine prefix and set the “UseRandR” option to “N” This will disable Wine’s use of the RandR extension and use a fallback method instead.

That should fix it.

https://wiki.archlinux.org/title/font_configuration#Hinting

What’s the WINE error message you get with the proprietary driver?

Font rendering is complex and depends on several settings and features lining up perfectly. Anti-aliasing, DPI, fractional scaling, hinting, and subpixel rendering are all important factors that contribute to the quality and appearance of text on a digital display.

On KDE plasma the fractional scaling also plays a role in text rendering. Then there’s also the “Legacy Application Scaling” for X11 apps on the Wayland session.

Magic Wormhole
Wormhole File Transfer (companion app)
iyox Wormhole (fork app)

OnionShare
OnionShare (companion app)

Check your install paths when you uninstall them. Do the files from the packages still exist?

Are you perhaps accidentally booting from a system snapshot?

BTRFS &/OR EXT4

It’s complicated.

sudo su; passwd

Super User Do Super User

It’s should definitely work then. MTP usually doesn’t leverage USB Gadget, but this one seems to.

Not sure if that’ll work for SteamDeck-to-LinuxPC connection, but I’m certain that works for SteamDeck-to-Android.
It is using USB gadgets, so it’s worth a shot at least.

I found some directions that might help.

Enabling USB-C OTG Device Mode :
Ensure the Linux device has a USB-C port that supports OTG functionality.
In the device tree, set the dr_mode property of the USB OTG controller to “peripheral” or “otg” to enable device mode.
Configure the TUSB320 USB-C controller (or equivalent) to operate in UFP (Upstream Facing Port) mode, which allows the device to act as a USB peripheral.
Configuring USB Gadget Drivers :
Load the appropriate Linux USB gadget driver for the desired functionality, such as g_ether for Ethernet over USB, g_serial for a serial device, etc.
Manually configure the USB network interface, such as assigning an IP address to usb0.
Connecting to a Host :
Use a USB-C to USB-C or USB-C to USB-A cable to connect the Linux device in OTG device mode to a host PC.
The host PC should then detect the Linux device as a USB peripheral, allowing file transfer, network connectivity, or other functionality depending on the configured gadget driver.

Gateworks.com Wiki Linux OTG
Kernel.org Driver-API USB Gadget
Collabora Blog Modern Linux USB Gadget integration with Systemd Part1

A tool : gt
Rust library : usb-gadget
C Library : libusbgx

Possibly. But from my research it seems to really depend.

the USB-C ports on the two PCs need to support USB OTG (On-The-Go) functionality, which allows the ports to dynamically switch between host and device modes. This is what enables the direct PC-to-PC communication over the USB-C connection.

cat works as well.

Idk about OP, but for me the entire widget menu position saving seems to be completely broken not just for the kickoff application launcher widget’s menu. The position saving feature is a relatively new thing anyway so I’m not too worried about it. I didn’t even notice it until OP’s post, lol.