Linux Fu: Fake Webcams, GUI Edition

Previously, I looked at using the Linux video loopback system from the command line. The basic trick was simple enough: capture video from a real camera, process it with something like ffmpeg, and write the result to a fake camera device via the v4l2loopback device. Then a browser, or any camera-enabled software, sees the fake camera as if it were real. This allows you to manipulate video before sending it to the rest of the world.

That works, and for those of us who like command lines, it’s easy enough to execute. But not everyone loves the command line. In the comments, there was another obvious answer: use OBS Studio.

While OBS is excellent, it is also a bit like using a laser to chop a carrot. If you already use OBS, fine. If you only want to crop a webcam, add an effect, mirror an image, or feed a virtual camera, it can feel like a lot. If you must have a GUI, you can try Webcamoid, which sits somewhere between a simple webcam viewer and a full video production system.

Webcamoid gives you a GUI for selecting a camera, applying effects, and sending the result to a virtual camera. Conceptually, it is much closer to the command-line loopback setup from the previous post than to OBS. You are still building a pipeline from input camera to output camera, but now you can do much of it with buttons and menus instead of shell commands.

That’s in theory, of course. Implementing Webcamoid turned out to be quite the exercise. Granted, this probably varies depending on where you install software. If your distro has a clean working copy of Webcamoid and its dependencies, good for you. For everyone else, keep reading.

Continue reading “Linux Fu: Fake Webcams, GUI Edition”

Linux Fu: Taming Strace

While many operating systems seem to try to prevent you from peeking under the hood, Unix and Linux positively encourage it. One great tool that we’ve looked at before is strace. Using this tool, you can see details about every system call a program makes. As you might imagine, for any significant program, the output from strace can be huge.

While I’m not always a fan of GUIs, this is one of those cases where making the data easier to browse is a great idea. Enter strace-tui, a text-based GUI for strace from [Rodrigodd]. The program can parse output from strace or manage the strace execution itself, and either way, display the data in a useful way.

I started out looking at [janestreet’s] strace_ui, but the OCaml setup was throwing errors for me, so I just gave up. The strace-tui installs like many Rust programs, using cargo, and it went smoothly.

Continue reading “Linux Fu: Taming Strace”

Linux Fu: Fake Webcams Have Many Uses

Dealing with text streams is a fundamental skill for the Linux power user. You can sort, merge, and search text files easily from the command line. What if you could do the same thing with video? Well, you can. Maybe you want to add a logo to a webcam feed before sending it to a conference app. Maybe you want to blur, color-correct, or annotate video in real time. Or perhaps you want to inject prerecorded video into Zoom while pretending it is a live camera. Linux can do all of this, and the key ingredient is usually the same: a loopback video device.

The basic idea is simple. Instead of an application reading directly from /dev/video0, you create a fake camera device using the v4l2loopback kernel module. Your software pipeline writes processed video into the fake camera, and applications read from it as if it were a normal webcam. The result is surprisingly powerful.

Continue reading “Linux Fu: Fake Webcams Have Many Uses”

Linux Distributions And Who Is Responsible For The Software

The topic of downstream and upstream is an important one in the Linux ecosystem, where from one base distribution you can go many layers of distros deep before even looking at all the other base distributions. Within that veritable jungle you get questions about who is responsible for packaging software, where to report bugs found with a specific application, as well as what ‘LTS’ truly means in a consumer context. These and other points are raised in a recent video by [Brodie Robertson], with many examples of things going tragically wrong.

There’s a good argument to be made that ultimately it is the distro that is responsible for the software that they provide via their repositories. As [Brodie] shows in the video, there are a few cases where an ‘LTS’ distro uses an old version of some software that contains a bug that has been fixed a while ago, so reporting it to the developer is rather pointless, while the distro maintainers should fix it with backporting of patches or updating the version.

From an end user experience this also makes the most sense, as in the end they just want to have the Windows experience of downloading a proverbial installer, clicking through whatever dialogs pop and have working software. If the software is provided via the distro, it is their responsibility, the same way that you contact the developer if you get a DEB or RPM from a GitHub project page and it doesn’t work.

This current Linux Chaos Vortex can be called a major issue when e.g. FreeBSD has no such upstream/downstream issues, with cross-platform installers being basically impossible on Linux ever since the Linux Standard Base effort died.

Perhaps Linux will get a distroless future, however, which may finally herald that Year of the Linux Desktop.

Continue reading “Linux Distributions And Who Is Responsible For The Software”

A phone running the XFCE desktop environment is placed on a desk, with a wireless keyboard in front of it.

Linux On Android Provides Inexpensive, Powerful Computing

In some parts of the world it’s common for cell service providers to sell new phones at a price significantly below market value, with the caveat that these phones are locked to that service provider alone. It’s questionable whether this practice is good for consumers, but as [Gabriel Broussard Korr] notes, it’s an opportunity for hackers: since it’s possible to run a Linux environment on these phones, they make an inexpensive source of quite powerful computing hardware.

In this case, [Gabriel] was using the Moto G Power 2024, which has 128 GB of storage, 12 GB of RAM, and costs less than $50 when carrier-locked. Rather than trying to install a mobile-oriented Linux distribution (such as postmarketOS), [Gabriel] installed Termux, a terminal emulator which provides a Linux environment within Android. Before doing this, he set up the phone and configured a number of settings for a better Linux experience. Since automatic updates can interfere with these settings, and since none of the provided settings effectively disable these, he used NetGuard to block Internet access from the updater app and from Google Play services.

The next step was to actually install Termux, as well as an X11 extension and an app which exposes an API for Termux. The desktop environment (XFCE in this case) was installed through Termux, and [Gabriel] wrote a shell script to go through the steps of starting it. XFCE worked well on mobile devices because of its full-desktop zoom capability. Even running Linux indirectly, the experience was smooth; [Gabriel] found that GIMP, Shotcut, and VS Code all performed well.

It’s not quite the same set of software, but we’ve previously featured a guide to setting up a similar Linux environment using Termux and AnLinux. Lindroid provides a similar containerized Linux environment; on the other hand, you can also use postmarketOS to make a server from an old phone.

Linux Fu: The Bluetooth Regression

There’s a line in a [Weird Al] (no relation) song that says, “I upgrade my system at least twice a day…” I know how that is. I primarily use a rolling distro, OpenSuse Tumbleweed, and if I’m having a problem that I’m too lazy to run down, it is extremely tempting to do an upgrade and see if it just happens to fix the problem.

Of course, the problem is often caused by a previous upgrade. Recently, I’ve been having a lot of trouble with the NVIDIA proprietary drivers, so I updated them yet again. After a huge amount of effort to sort out the video problems, I found that the latest kernel didn’t like my MediaTek Bluetooth adapter, which is built into the motherboard’s WiFi chipset.

This post isn’t about how to fix your Bluetooth problem. You probably don’t have the same setup I do, and even if you do, it will be sorted out in a week or two anyway. But how I temporarily fixed this issue is worth documenting. The details are going to apply to Tumbleweed and this particular adapter, but the general approach should work anywhere with any sort of kernel module problem.

My Own Fault

Part of my problem is my own fault, of course. I have a complex disk setup and do not use the recommended btrfs root file system. That means I can’t do the snapshot thing where I can just undo a bad upgrade. If I did, then sure, I should just roll back and wait for an upstream fix.

I do have “normal” backups, but they are not always totally up to date. Worse, I have found that for things like NVIDIA, the user stuff and the kernel module stuff have to match up. That makes it very hard to roll back a kernel with older modules. The modules themselves live with the kernel, but the user space stuff gets pushed out. Or, if you uninstall things, it uninstalls it for all kernels.

Truthfully, NVIDIA and others like that should keep all the user space stuff in a kernel-specific place, and then symlink it at boot to /usr/bin or wherever. But they don’t. In the end, I didn’t want to go through the trouble of rolling things back and decided to push ahead.

Continue reading “Linux Fu: The Bluetooth Regression”

The Team Behind The Flipper One Needs Your Help

You’ve probably heard of the Flipper Zero, a pocket-sized device that packs in lots of great hacking potential. The team behind it has now turned their efforts towards developing the Flipper One, and they’re calling out for help from the broader community. 

The Flipper One is not intended to be a replacement or sequel for the Flipper Zero. Instead, it’s designed to exist as a entirely new device in its own segment. The team is hoping to build “the most open and best-documented ARM computer in the world,” as they attempt to create a Linux cyberdeck of grand capability. Where the Flipper Zero has found great use for interrogating and investigating low level communications, like IR and NFC, the Flipper One is intended to go to a higher level, working with protocols like Wi-Fi, 5G, and Ethernet in the networked world.

The new device will be based around a co-processor architecture, where a microcontroller is paired with a capable CPU for great flexibility. It will also feature all the high-speed interfaces you’d expect, like PCI Express, USB 3.0, SATA, and Gigabit Ethernet. It’s a proper, capital-C Computer in that regard. The intention of the team is also to redefine some of the typical Linux experience, by creating GUI wrappers around certain traditional CLI utilities. It should go a long way to giving the software the same cyberdeck feel that the current prototypes embody in their hardware design.

If you want to learn more and get involved, head over to the Flipper One Development Portal and dive in. Alternatively, you might like to get up to speed with some of our prior reporting on the Flipper Zero. Happy hacking!

[Thanks to Andrew for the tip!]