Hardware/Workarounds
Many ARM-based machines, such as popular single-board computers, have features missing when using a fully free operating system. In particular, radios like Wi-Fi typically require proprietary firmware; additionally, graphics processing units (GPUs) and video processing units (VPUs) often require invasive “blobs”, proprietary drivers that mistreat the user. Not all hope is lost! The missing components can be worked around to enable a fully free operating system with minimal compromises on usability for many people.
GPU
Graphics processing units are ubiquitous today with a multitude of capabilities. In practice, they accelerate 3D applications and, to a lesser extent, accelerate graphically-intensive 2D applications.
When there is no alternative, these tasks can be done in software on the CPU with “software rasterisation”. On GNU/Linux, the llvmpipe module of the Mesa library is responsible for this task. However, software rasterisation is slow compared to dedicated hardware.
As a rule, without a GPU or powerful CPU, all 3D applications should be avoided. 3D games and applications like Blender will not be usable.
A more subtle issue is GPU-requirements in the desktop environment. Although they are not 3D, modern desktop environments like GNOME 3 are resource intensive, making particular use of the GPU. Without a GPU, these desktops are sluggish at best, and unusable at worst. Instead, use a lightweight desktop, like MATE or XFCE, or even a barebones window manager, like i3 or Openbox.
Within the desktop environment, one component is “compositing”. Compositing window managers are typical in modern desktop environments, used for visual effects like window drop shadows. While aesthetically pleasing, compositing usually requires GPU acceleration.
To compound the issue, modern desktops typically feature resource-hungry animations, which should be disabled as well.
For MATE, navigate to System->Preferences->Look and Feel->Windows->General and untick “Enable software compositing window manager” https://wiki.archlinux.org/index.php/MATE#Enabling_compositing. Then, execute dconf-editor and click the search icon in the top right corner (the magnifying glass). Search for “animation” and disable each option: /org/gnome/desktop/interface/enable-animations, /org/mate/panel/general/enable-animations, /org/mate/desktop/interface/enable-animations, /org/mate/desktop/interface/gtk-enable-animations, /org/mate/panel/toplevels/top/enable-animations.
For XFCE, execute xfwm4-tweaks-settings and disable the compositor https://wiki.archlinux.org/index.php/Xfwm#Composite_manager. ???animation
For bare window mangers like i3 and Openbox, there is no compositing by default; compositing is handled by a separate “compositor” program, like compton. Simply don’t setup a compositor, and no compositing will be used. Similarly, there are no animations included by default.
Although the VPU is specifically for video, GPUs often play a role in video playback. However, if there is no GPU available (software rasterisation is used as a fallback), modern video players may have a heavy performance hit from attempting to use this “optimised” path.
One video player which can avoid this issue is mpv. By default, mpv usually requires a GPU or software rasterisation (through OpenGL). However, if it is passed with the --vo x11 option, OpenGL will be avoided for significantly improved performance. For example, instead of:
$ mpv <https://static.fsf.org/nosvn/FSF30-video/FSF_30_720p.webm>
Use:
$ mpv --vo x11 <https://static.fsf.org/nosvn/FSF30-video/FSF_30_720p.webm>
mpv will print a warning that “this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the x11 VO.”. Ignore the message; counter-intuitively, in the absence of the GPU, this will usually improve performance.
Depending on the type of video, certain software scaling algorithms may be better. For instance, on cartoon-like videos which are predominantly flat-shaded except for edges, the area algorithm may provide a considerable performance boost with minimal loss of quality from the default algorithm. Invoke it by passing the --sws-scaler=area flag, e.g.:
$ mpv --vo x11 --sws-scaler=area <https://static.fsf.org/nosvn/FSF30-video/FSF_30_720p.webm>
You may prefer the even-faster fast-bilinear algorithm:
$ mpv --vo x11 --sws-scaler=fast-bilinear <https://static.fsf.org/nosvn/FSF30-video/FSF_30_720p.webm>
For VLC, GPU acceleration can be disabled by navigating to “Tools->Preferences->Video” and setting “Output” to “X11 video output (XCB)”, assuming X11 is in use on your system. VLC may need to be restarted before this settings are enabled. However, with both configured optimally, mpv may still be faster than VLC.
Many graphically intensive applications support optional “hardware acceleration”, typically referring to GPU acceleration. Disabling this setting can sometimes improve performance on machines without a GPU:
For Krita, navigate to Settings->Configure Krita->Display and untick “Canvas Graphics Acceleration”.
For Firefox, click the three bars in the top right, navigate to Preferences->Advanced, and untick “Use autoscrolling”, “Use smooth scrolling”. and “Use hardware acceleration when available”.
You may also consider lightweight alternatives to applications you use, which typically also have lighter GPU requirements. For instance, instead of viewing PDFs in Firefox or evince, try mupdf.
VPU
Video processing units are prevalent on modern system-on-chips. Capabilities vary; in general, VPUs accelerate decoding (and in some cases, encoding) of video in select codecs.
Particularly on mobile devices like phones, VPUs minimise power consumption when watching videos, extending battery life. Nevertheless, modern CPUs are usually fast enough to decode videos in software in real-time.
In some cases, even when supported with free software, the VPU does not implement codecs of interest, such as VP9. In these cases, software decoding will be used anyway.
Video players on GNU/Linux use software decoding if hardware support is not available. No specific workaround is necessary by the user.
Wi-Fi
Internal Wi-Fi cards almost always require proprietary software, typically firmware or sometimes entire drivers. A small number of PCIe cards are compatible with a fully free software stack, such as those supported by the ath9k driver. SDIO cards, such as those found in many laptops, generally require proprietary software for normal operation.
Many USB Wi-Fi adaptors, however, work well with free software. The gold standard here are those using the ath9k_htc Linux driver. This driver is free software; while the cards do require firmware, the firmware is also free software!
Other USB adaptors have proprietary firmware burned into the adapter’s ROM. While free firmware would be preferable, this can be considered to be part of the hardware; adaptors in this category, like those based on the RTL8192CU chipset, can work. This may be necessary on boards with buggy USB drivers, such as the RK3288 with the dwc2 stack.
Check https://h-node.org for more information about compatibility.
While replacing the internal Wi-Fi is generally not practical for end-users, particularly on modern laptops where the Wi-Fi is soldered on to the motherboard, a compatible USB Wi-Fi adaptor is a great choice for connectivity.
Alternatively, if wireless functionality is not essential, a USB-Ethernet adaptor can be used instead. These typically work out of the box on free GNU/Linux systems, although it impedes portability.
While cellphones are not ideal due to grave freedom issues, in a pinch, tethering over USB to a phone running Replicant or Android can also enable Internet connectivity.
