Hardware support
What drivers exist, what has been run on real machines, and what is still only proven in emulation.
AnotherOS runs on real machines, not only in emulation. This page is stated from what has actually been observed on them, and it says plainly where something is proven under emulation and not yet on metal.
The driver model
Drivers are native where the hardware is simple enough to be worth writing from scratch, and ported through a Linux compatibility layer where the hardware is not — graphics and Wi-Fi above all. That layer implements the kernel interfaces a Linux driver expects, so the driver itself is upstream code rather than a re-implementation of it.
This is the same trade the ports system makes for userland: write the parts that define the system, port the parts where a rewrite would be a worse version of something that already works.
Storage
- AHCI / SATA, including on real laptop hardware.
- IDE, with a PIO fallback where a controller reports no bus-master DMA.
- NVMe.
- USB mass storage.
Filesystems: ext2, ext3 and ext4, SquashFS, OverlayFS, ISO 9660, FAT, and network shares over SMB2 and NFS.
Graphics
Every machine gets a framebuffer from the bootloader, and the desktop runs on that alone — so a machine with no supported GPU still has a working desktop.
Beyond that, Intel graphics are driven through the Linux compatibility layer with Mesa on top, which gives OpenGL, hardware-accelerated compositing, and hardware video decode on the chips that support it. Zero-copy buffer sharing between the compositor and clients works there through the same interface Linux uses.
On machines with no accelerated driver, Mesa's software rasteriser provides OpenGL and everything continues to work, more slowly.
USB
xHCI, EHCI, OHCI and UHCI are all implemented. Keyboards, mice, mass storage and hubs enumerate.
Getting all four matters more than it sounds: machines routinely put their internal devices behind an older controller, so an xHCI-only kernel silently misses hardware that is physically present.
Networking
Wired: Realtek r8169, Atheros atl1c, and the usual emulated adapters.
Wi-Fi is 802.11 with WPA2-PSK, including the full association and handshake path, driven through the Linux compatibility layer. See Networking for how it is configured and for the one thing that reliably misleads people — a software radio that looks exactly like a real one unless the interface says otherwise.
Wi-Fi is the least uniform area of hardware support. Some cards come up and associate; some enumerate and have no driver written for their PHY. The status is reported honestly per machine rather than as a single claim.
Audio
HDA is the main driver, with AC'97, ES1370 and SB16 also present. Codec quirk matching follows the upstream Linux tables rather than inventing its own keys.
Audible sound from real hardware is proven. Fidelity is not measured — nothing has yet compared what leaves the speaker against what was written to the device, and this page will not claim it until something does.
Two practical notes. Some boards boot muted, and say so in the log rather than leaving you to guess. And there is no resampler in the HDA path, so a program that writes a rate the device does not support gets the nearest one it does — which is why every audio tool here negotiates the format and uses what the device answers. A program that writes blind plays at the wrong pitch, and that reads as a driver fault when it is not one.
See Audio for the client side.
Power and firmware
ACPI with a real interpreter, covering batteries, the AC adapter, the lid, the power button and screen brightness. Suspend to RAM exists; UEFI runtime variable services allow an installed system to be made the firmware's default boot.
Apple machines additionally have their system management controller read for the keyboard backlight, the lid, fans and temperatures.
The clock
Some firmware — Apple's, on at least one model — leaves the legacy timer chip present and answering but never ticking, so an operating system that waits on it waits forever.
AnotherOS keeps time the way modern systems do, from the processor's own high-precision clock, and does not depend on the old chip at all. That applies to every machine, not only the ones that need it.
The machines it is tested on
| Machine | Silicon | State |
|---|---|---|
| Dell (Lynx Point) | Intel, i915 graphics, r8169, Intel Wi-Fi | Boots, SMP, desktop, audio, accelerated graphics. Wi-Fi radio comes up and scans real airspace. |
| Acer AO722 | AMD C-60, Radeon, Atheros wired, Broadcom Wi-Fi | Boots, SMP, desktop, Wi-Fi radio brought up. |
| MacBookPro8,3 | Intel, HD 3000 | Boots, desktop, accelerated OpenGL through Mesa. Netboots over Apple's own protocol. |
| MacBook (12-inch, 2017) | Intel Kaby Lake | Boots from internal storage alongside macOS, desktop on the GPU, over Wi-Fi. |
| Panasonic CF-H2 | Sandy Bridge, touchscreen, no keyboard | In the lab; bring-up in progress. |
The 12-inch MacBook is the machine that dual-boots: hold Option at power-on and the firmware offers both systems. Choosing macOS gives a Mac that has no idea anything happened.
What this page will not do
It will not list hardware as supported because a driver exists for it. Where something is proven only under emulation, it says so; where a claim was once made and later withdrawn, it stays withdrawn. A hardware support list that overstates is worse than a short one, because the person reading it is deciding whether to put their afternoon into a machine.
More documentation
- Booting the live image
- Installing to disk
- Packages and the filesystem
- How it boots
- The syscall ABI
- ACPI
- UEFI boot entries
- NetBooting a Mac
- The AO toolkit
- Grafika — the graphics API
- The display protocol
- Desktop effects
- The level bezel
- Notifications
- Rastinis — the file manager
- File operations
- Audio — Garsas
- Hardware video decode
- Networking — Tinklas
- Network shares — SMB and NFS
- Remote control
- The Win32 subsystem
- DirectX and OpenGL for Win32 programs
- Ports and packaging