Linux, Drivers & Mesa

Linux Tux penguin wearing the Mesa 3D logo

Linux runs on nearly everything we touch, from a postage-stamp embedded board to a render cluster, and we work at the level most shops would rather avoid: the kernel, the device drivers, and the graphics stack underneath the application. When the bug is not in your code but in the layer below it, that is where we are comfortable.

Drivers, down to the graphics stack

We write, modify, and maintain device drivers and kernel modules, and we work inside Mesa, the open-source graphics stack, at the driver level: DRI, DRM and KMS, and the OpenGL and Vulkan userspace drivers that decide whether your 3D makes pretty pixels. Getting accelerated graphics onto hardware the vendor never fully supported is a specific skill, and it is one we and our associates have.

Across all the hardware

The same expertise runs from low-end single-board computers and embedded targets up through ARM, our RISC-V soft cores, x86 workstations, and clusters. Board bring-up, Yocto, BSPs, cross-compilation, and the unglamorous work of getting a kernel to boot and a display to light up on hardware that has never run it before. We've helped port embedded navinfotainment from Windows to Linux on diverse hardware.

Real-time and reliability

Some systems cannot wait. We work with real-time Linux, including PREEMPT_RT and RTLinux, where a late frame or a missed deadline is a failure and not just a slowdown. That ties directly into our safety-critical and embedded work.

Kernel and the long tail

Kernel patches, drivers ported forward across versions, and the maintenance nobody advertises: keeping a system building and running years after its original toolchain went stale. We have rescued more than one graphics stack that quit working when the rest of the world moved on.

How it connects

Linux is the floor under much of our other work. The 3D graphics, the geospatial pipelines, the embedded and safety-critical displays, and the RISC-V cores all run on an operating system that someone has to make behave. Often that someone is us. Let us help you make it all behave.

Who works on it

AlphaPixel is a US-owned small business, founded in 2004, with senior developers who work from the kernel and the driver up through the application. DLA DD2345 / ITAR registered. We take closed-source defense work and open-source alike.

Frequently asked questions

What kind of Linux work do you do?

We work at the level most shops would rather avoid: the kernel, the device drivers, and the graphics stack underneath the application. Linux runs on nearly everything we touch, from a postage-stamp embedded board to a render cluster, and when the bug is not in your code but in the layer below it, that is where we are comfortable.

Can you get accelerated graphics working on hardware the vendor never fully supported?

Yes. We work inside Mesa, the open-source graphics stack, at the driver level: DRI, DRM and KMS, and the OpenGL and Vulkan userspace drivers that decide whether your 3D makes pretty pixels. Getting accelerated graphics onto hardware the vendor left half-supported is a specific skill, and it is one we have.

Do you do board bring-up, Yocto, and BSP work?

Yes. That includes board bring-up, Yocto, BSPs, cross-compilation, and the unglamorous work of getting a kernel to boot and a display to light up on hardware that has never run it before. It runs from low-end single-board computers and embedded targets up through ARM, our RISC-V soft cores, x86 workstations, and clusters.

Do you work with real-time Linux?

Yes. Some systems cannot wait, so we work with real-time Linux, including PREEMPT_RT and RTLinux, where a late frame or a missed deadline is a failure and not just a slowdown. That ties directly into our safety-critical and embedded work.

Can you port an embedded system from Windows to Linux?

Yes. We have ported embedded navigation and infotainment from Windows to Linux across diverse hardware. That kind of move usually touches the driver and graphics stack, which is exactly where we work.

Can you rescue or maintain an old graphics stack or kernel?

Yes. Kernel patches, drivers ported forward across versions, and the maintenance nobody advertises: keeping a system building and running years after its original toolchain went stale. We have rescued more than one graphics stack that quit working when the rest of the world moved on.

What hardware do you cover?

The same expertise runs from low-end single-board computers and embedded targets, through ARM and our own RISC-V soft cores, up to x86 workstations and clusters. Linux is the floor under much of our other work in 3D graphics, geospatial, embedded, and safety-critical displays.

How do we engage AlphaPixel for driver or kernel work?

Tell us the hardware, the kernel or Mesa version, and what is broken or missing. We are a US-owned small business, DD2345 and ITAR registered, and we take closed-source defense work and open source alike. Contact us to scope it.

Talk to us

Tell us what you’re building and where it’s stuck. We’ll tell you straight whether it’s something we can help with, and how we’d approach it.

Or see how we run consulting and software development engagements.

Scroll to top

connect

Have a difficult problem that needs solving? Talk to us! Fill out the information below and we'll call you as soon as possible.

Diagram of satellite communications around the Earth
Skip to content