Hey everyone, we are back with the past month’s updates. It has been an overloaded month for the entire team, and though everyday is a constant fight in pushing through barriers while dealing with setbacks - we couldn’t be more excited on how things are shaping up in our final laps to production.

Let’s get you all synched up. As usual the update is going to be a long read :)

TL;DR

• Hardware: I.MX95 testing is largely complete. DDR speed issue diagnosed to PCB design issue, fix has been validated and the next revision will incorporate the changes. Pre-production PCBs are targeted for manufacturing release by 14 November.
• Production design: Comet’s housing and extension assemblies have been validated, with fixes completed for failed areas.
• Extensions: QMK and Vial are running successfully on the keyboard extension. The gamepad firmware runs on Zephyr and maps as a standard USB HID making it platform independent.
• Software: The I.MX8M Plus Etnaviv driver achieved OpenGL ES 3.0 conformance. The Mechanix launcher and keyboard are running on the team’s Wayland compositor, with further polish and native app development underway.
• Supply chain and delivery: Most long-lead ICs have arrived. Tooling is now expected to take six weeks and certification between 4-5 weeks both can run in parallel; we remains optimistic about production in January and shipping shortly after.

------------------------------------------------------------------------------------------

Hardware

I.MX95 Hardware Testing (✅ completed)

In the last update, I had mentioned that the I.MX95 variant testing is a critical blocker for us, happy to share that we’ve pushed through on its testing and validation. Below is the overall status on an interface and peripheral-level.

You can see that almost everything worked and we only had failures in reaching higher-speeds for interfaces - USB, PCIe and LVDS (for display) which after debugging we are confident that the DDR’s instability beings its root cause. Here are some quick snaps of the board’s functions.

Fixing the issues with DDR at high-speed interfaces

We shared earlier that we couldn’t get the DDR to work beyond 1866 MT/s (short of its max speed of 4266 MT/s) and this has kept me awake for a number of nights this past month. For debugging, first we eliminated any possibility of a driver or firmware issue, we couldn’t find anything - later we shifted to the physical layout (how things are connected) of the PCB. After some reviews we identified a gap in our PCB stack-up and layout that could explain the issue.

What was the issue?

The first thing to understand here is DDR operates at insane speeds, 4266 MT/s translates to 4.266 billion transfers per second and 234.4 picoseconds (0.0000000002344 seconds) to finish one data transfer. At such small margins, a minor issue in the physical layout could translate to a significant timing loss. On detailed analysis of the PCB design, we could see a stack-up issue that resulted in low margins failing to complete the data transfer under 234 ps.

I will attempt to explain the issue in simpler terms. A PCB is made of multiple layers comprising of copper and the dielectric stacked together. Each copper layer acts either as a signal, ground or power layer. Now data travels through signals, and every signal is like a loop. For DDR signals within these layers, you not only need a super-fast forward path which we had but an equivalently fast return path to ground too. This is where our design failed, 12-layers in 1.2 mm forced the di-electric to be too small to cause part of this return signal to flow into an unintended copper layer, skewing up the DDR timings and we didn’t have enough provisions to prevent that from happening.

How do we fix it?

First we tested this on our existing test boards by forcing the unintended layer to also act as GND which resulted in training and testing to work at 4266 MT/s 🎉, we couldn’t test the rest of the high-speed interfaces because it was very hard to keep the board stable with the hacky changes we made.

For the pre-production revision, we are patching this issue by moving to a 14-layer stack-up for I.MX95 with an increased PCB thickness to 1.4 mm with a more stable and safer stack-up to ensure we don’t have this issue. We are also running extensive design reviews and simulations to confirm performance and stability for DDR and other high-speed interfaces.

Pre-Production PCB design close to completion

While the hardware and mechanical validation & testing has been going on, our team’s PCB designers have actively been working on the pre-production revision for both the I.MX8M Plus and I.MX95 designs. This revision doesn’t implement any new feature or has a major design change but incorporates every little change that surfaced from hardware and mechanical validation and for pre-emptive provisions for clearing certification testing and requirements.

We are working on releasing them to manufacturing by 14th November. Below is a summary of all major changes introduced apart from the fixes.

Updating the PCB thickness to 1.4 mm

As mentioned above to overcome the DDR issues, we are moving to a 14-layer stackup on the I.MX95 with a 1.4 mm thickness. This change even though is only 0.2 mm, requires shake-up on the PCB’s stackup for both the I.MX8M Plus and I.MX95. We have adjusted the stackup with this updated thickness and are working with our PCB Fabrication houses for their manufacturability.

Note, this increased thickness has resulted in a 0.2 mm increase in overall thickness of the Comet, that is close to ~1.4% thickness increase.

Adding a capacitive sensor to limit SAR

One of the critical changes added to this revision is a capacitive sensor near the LTE primary antenna system to detect human touch or grip to reduce antenna power dynamically. This is part of the strict Specific-Absorption-Rate requirements as part of EU, CA and US (FCC) compliance.

This sensor converts the primary antenna itself (shown below) to a capacitive sensor and when it detects human body near the antenna it can signal the modem to lower its power limiting the electromagnetic energy absorbed by the body. When the hand moves away it can restore to its original power.

Changes to the Wi-Fi and Mic kill switch

The Wi-Fi kill switch in our prior design was implemented by cutting-off power to the Wi-Fi/BT chip. Our updated mechanicals with the LTE antenna left no space for a switch that could withstand the Wi-Fi/BT chip’s power rating, so we were forced to remove it. For the revision 9 we have instead used the PDN signal as the kill switch, we hold it down when the switch is ON, and the processor can no longer control it. We’ve also added a sensing signal to know the kill switch’s state so we can ensure the firmware loads or unloads cleanly.

The updated position of the Mic and Wi-Fi kill switch is under the M.2 card area. We agree it is not the best if you have the LTE modem or SSD installed but we couldn’t find any other place for it. No changes to the Camera kill switch, it is near the camera as it was before.

Alternative battery connector provisions

Due to mechanical and electrical constraints, the Comet’s battery connector uses a standard board-to-board connector similar to the ones found in the mobile phones. Because longevity has been important we had populated an alternate 3-pin JST wire to board connector that is widely available especially on DIY electronic websites so that you could bring an alternate battery in if we stop producing or you want a bigger one. Due to the updates in the design, we will not be mounting the connector by default instead leave the footprint for you to solder (3 points) it in if you need it.

Alternatively, we can provide a Flexible PCB design that mounts our connector on one end, and you can solder it to your battery on its other end.

Housing parts and overall assembly are now validated

Late September, we had already released our designs for prototyping and were waiting for the samples to get ready. Once they were ready, to accelerate validations we set up physical review meetings for in China between our mechanical engineers and our parts manufacturer.

Over a course of a week, we spent hours assembling everything together and then tearing it apart part-by-part to analyse its fitting, assembly process and overall suitability. This exercise let us validate the entire design physically, find problems and brainstorm solutions right there and there and resolve them.

Let's run you through what the assembled Comet looked like with the parts prototyped. Most things worked, some things didn’t and that is what the validation is about. These parts are not post-processed or painted because our focus was on functional validation rather than aesthetics.

Fun fact: These parts could not be made using 3D printed due to our low tolerances, instead they are made using the vacuum casting process. This is a nice video that explains this process - https://www.youtube.com/watch?v=gZnQu3N5SEg

Issues with the back cover snaps

One of the glaring issue we observed is the back cover snaps, they were not nice to pull off and broke easily. Our manufacturer also highlighted risk. We want to ensure easy access to the insides for all the tinkerers, as part of the fixes we have updated to a better mechanism.

New snap design with easier and a more satisfying opening-closing

We have altered the design to use the periphery of the back cover and the middle frame for snaps, this maintains a uniform force overall and makes it easy to remove the back cover by just pulling it out from one edge. These are better from manufacturing perspective too.

Additional heatsink for better thermals

We are testing thermals further with I.MX95 and as a way to improve the overall heat dissipation, we have added provisions for an additional heatsink that can be mounted. Once we test things a bit more we are going to decide to mount this heatsink before hand or leave it as a provision.

Production tooling for housing parts

The housing for the Comet and its extensions is made from multiple parts made from different materials, primarily - plastics, metals and rubber. Each of these parts can be mass-manufactured using different processes as listed below -

Injection moulding is the industry standard for building the plastic parts. To explain injection moulding in simple terms, you take plastic granules melt them into liquid and then at high pressure ‘inject’ it inside a mold cavity and let it take shape and cool down. In our case the process is a bit more complicated because depending on the part additional complexity for insert moulding and overmoulding are also added.

Here is a quick video of injection moulding in action, shot at our manufacturer’s site during our visit last month.

Unlike 3D printing, this process has certain designs constraints that have to be accounted for to ensure suitability. Our mechanical engineers are experienced in designing injection moulded parts that has helped ensured we don’t miss any of them from the start.

Now that our validation and its subsequent changes are completed, our manufacturer has shared a formal DFM (design-for-manufacturing) report demonstrating feasibility and suggestions for changes in the parts for them to design its mould cavity and assembly. Once the changes are completed we will sign-off for die making.

Above is a small glimpse from the DFM report, that identifies partition line, analyses thickness and sets gate position and ejector layouts required for injection moulding.

Extensions

Extensions mechanicals are now validated

Like the main housing parts, we spent significant time last month in validating the two extensions where usability is critical - the Gamepad and Keyboard. The IO extension is something we aren’t too worried about because it doesn’t have moving parts.

Keyboard assembly

On the keyboard, the most important part to get right is the layering of the plastic keys with silicone and the underlying dome switch. We experimented multiple times and have found a right balance for good tactile feeling and adequate trip force.

You can check the keyboard tactility in action below, 🔉 watch with audio. The sound and the feedback will improve further.

Gamepad Assembly

You can check the video below for its tactile feedback, 🔉 watch with audio on

The ABXY, D-Pad and both sticks (analog and pointing) have come out well, they just need some refinements. The shoulder buttons let us down; we were quite unhappy with how its mechanism worked - we originally thought vertical movement would give maximum travel but it just didn’t give a good feedback.

We are currently working on a new pivot-based mechanism for the shoulder buttons, making it a better natural experience for your fingers.

Keyboard firmware with QMK

We started on ZMK, as we announced in May. As we built it up, we found that ZMK Studio is still limited compared to Vial. For example, it can’t create macros, tap dances or combos, or control underglow lighting. Vial can do all of that, live from a GUI, with no recompiling and no flashing. So we pivoted to instead focusing on enabling QMK for the Comet, QMK is way more stable and Vial is just way too powerful in its current version.

Luckily for us, the NXP MCXC243 MCU is actually a more modernized Kinetis MCU that is already supported by QMK so we don’t have to build the support from scratch. The porting is still in progress, but QMK and Vial already run on the keyboard, you can check it out in action below.

Gamepad firmware ready-to-deploy 🚀

In the August update we showed the Gamepad PCB fully working, playing games over the external USB-C. That was about validating the hardware. Now the Gamepad Extension is running on Zephyr RTOS, it shows up as a standard USB HID gamepad works across Linux, Mac, Windows and Android without drivers or a companion app.

For games that only support Xbox-style (XInput) controllers, like Rocket League, you can use Steam Input to make it work. You can check the below demo for SuperTuxKart, the cart is steered with the Pointing Stick as the right analog stick.

We will be pushing the firmware to GitHub soon enough 😬

Introducing the Mecha Pivot Pip

You’ve followed this one as the 'pointing stick' since the May update, where we first showed its early designs. It now has a name: the Mecha Pivot Pip.

Pivot Pip senses pressure rather than movement, which keeps your thumb in place and gets the cursor across the screen without repeated swipes. It re-centers itself when idle, so there’s nothing to calibrate. It’s used on both extensions: as the pointer on the keyboard and as the right stick on the gamepad. Watch the Pivot Pip in action below.

The Zephyr module for the Pivot Pip is now on GitHub and integrated as part of the Gamepad firmware you can check it out.

Software

OpenGL ES 3.0 Conformance for Etnaviv Driver (I.MX8MP)

Earlier this year when the campaign was still active, we had promised for OpenGL ES 3.0 support for the Etnaviv driver on I.MX8M Plus variants for the Mecha Comet. I am happy to share that after more than 4 months of our on-going collaboration, Christian Gmeiner from Igalia, has pushed the final commits last month for OpenGL ES 3.0 conformance to mesa.

To learn more about this gigantic effort in reverse engineering the Vivante GPUs you can read the official announcement from Igalia on this https://www.igalia.com/2026/etnaviv-is-now-OpenGL-ES-3.0-conformant.html.

You can also watch his lightning talk at XDC 2026 last month for more details.

Getting OpenGL ES 3.0 enables modern applications to run on the I.MX8M Plus variant that require ES 3.0 as a minimum, making it at par with the I.MX95 on application support. This included GTK4 applications, Rust applications powered by WGPU and WebGL 2 support in browsers. This also means that our compositor and launcher can leverage more advanced features that OpenGL ES 3.0 supports over 2.0.

Here is a demo of Three.js demos using WebGL 2 on the I.MX8M Plus leveraging the ES 3.0 conformance. This wouldn’t have worked earlier on ES 2.0.

Now that we are conformant , we are now focusing more towards performance and compatibility with applications like browsers and frameworks such as GTK4, Rust-based UI frameworks that use WGPU, Game engines like Bevy that required OpenGL ES 3.0.

On a side note, the I.MX95 variant uses the Mali GPU powered by the Panfrost driver that is already on OpenGL ES 3.2 and PanVK driver that is on Vulkan 1.4. It is also switching to the new Kraid compiler that promises faster instruction generation. 

Mechanix GUI shaping up

Earlier in January when we showed some software demos people raised concerns on performance, we acknowledged them and clarified that they didn’t meet the standards we’ve set for ourselves. Since probably March or April we have been talking about building our own IO runtime and UI stack for our core GUI components - the launcher, keyboard and the compositor (Wayland), showcasing our architecture and the core engine, but now I am happy to share that our Launcher and Keyboard are finally now in action running on our own Wayland compositor.

Building this complete stack from ground-up has given us the room to optimize at multiple levels and build a more cohesive experience. Of course there are a lot of 🐞 bugs to squash and usability improvements like animations to be added, but it is now very much usable and performant to our expectations.

Here are some demos of the Launcher and Keyboard in-use, this is running on the I.MX8M Plus variant.

The Mecha team uses Zulip for online team chat and collaboration, @indegrowl from our Launcher team ported its Flutter-based Android App to Linux with flutter-elinux backend. You can check the Zulip app in action on our new launcher and the keyboard.

Here are the list of features and improvements that have gone into them or are in progress over the last 4 weeks.

UI Engine & IO Runtime (mecha-wayland)

• Native D-Bus support integrated into the IO runtime. This is how the shell talks to NetworkManager, UPower, logind and notifications.
• Theme system and the mechanix-widgets library: themed Button, Text and Slider.
• Timers, plus support for watching file descriptors. This makes PulseAudio integration possible.
• Smooth touch scrolling: iOS-style drag, fling and spring physics in progress. When you scroll, it reuses the previous frame and only draws the newly visible strip to optimize for the GPU.
• Advanced windowing features for building shell-like features -
  • Panels and overlays can change layer, input area, reserved screen space and keyboard focus while running.
  • Windows can have transparent backgrounds.

Launcher (mechanix-launcher)

• Gesture navigation: edge swipes and a navigation dock in the bottom. You can swipe to home from anywhere.
• Status bar: battery level from uPower, Wi-Fi status from NetworkManager and Bluetooth from Bluez
• Quick settings, redesigned with more features
  • Wi-Fi Integration: SSID, signal strength and toggle, updating live.
  • Bluetooth: state and the name of the connected device.
  • Display controls.
  • Power off and restart through logind.
  • Volume slider driven by PulseAudio, and hardware volume keys (in progress).
• Notifications: a full freedesktop spec compliant notification server
  • Live cards, close, timed expiry, dismiss and snooze.
  • Support for formatted (markup) text.
• App drawer:
  • Lists installed apps with their proper icons.
  • Fuzzy search (fzf-style) over a scrolling list.
  • If an app is already open, it switches to existing instance instead of opening a second copy.
• Running apps: shows live previews of apps as scrollable cards, implements swipe up to close.

On-screen Keyboard (mechanix-keyboard)

• Moved into the launcher binary for better usability and transitions.
• Haptic Feedback: integrates audio and vibration using feedbackd
• Easy access: It opens with a swipe from a bottom corner and closes with a swipe down.
• Predictive touch: Bundles an English word list to predict the next letter, help. Tuned by simulating noisy typing.
• In Progress items
  • AOSP-style English layout in the Mecha theme.
  • Pop-up of the pressed key for visual feedback
  • Show alternate characters (accented) on long press.
  • One-shot Shift and Caps Lock.
  • Support for additional layouts: number, phone, email, URL, password and terminal.

Mechanix Compositor

Our compositor has seen a lot more improvements since we announced it earlier in September. Here is a list of its recent changelog over the past 4 weeks.

• Added screen and window capture (ext-image-copy-capture)
• Added the security context protocol, which hides privileged protocols from sandboxed apps
• Added a systemd user session
• Added config support, initially for just the scale factor
• Implemented phosh_private thumbnail views and keyboard-event accelerator grabs
• Reworked window stacking and focus
• Fixed lock screen and idle-inhibit behaviour
• Suspend windows when not in view
• Several other fixes and improvements, with a focus on stability and performance

I am incredibly proud of the progress our team has made here and excited to share the further developments on this end. 

Updates on the Native Apps

Our native apps continue to see more development and improvements. Our first set of apps include the (i) Browser (ii) Terminal (iii) Notes (iv) Files (v) Music (vi) Calc (vii) Clock (viii) Camera. We are hoping to get them to a dev freeze by end of this month, so we can publish more demos in the next update.

You can watch a quick demo below working in sync with our new launcher and keyboard.

You can find their individual repositories on https://github.com/mecha-org, just search with prefix mechanix-

Supply Chain

Component Procurement

We are on track on the procurement, we’ve received all major lead-time critical ICs and are waiting to receive 2 key critical components - the WiFi/BT and Audio Codec IC that are scheduled to arrive in coming weeks.

Rest of the components and parts that are dependent on our mechanical design are targeted to arrive before 15th December.

Updates on timelines, risks and challenge

We’ve made leaps of progress over the past 4-5 weeks and are heading in the right direction. Here is updated status on the milestones in the path to delivery.

While we are making everyday count, these laps towards the end are critical, a misstep now could turn out to be disastrous in the long-run or push things way beyond the estimated timelines.

Here is everything to know on the current status and the upcoming items -

1. The housing mechanical validation and PVT PCB design have taken up 2-3 weeks of additional time in testing, validating and fixing on both the PCB design and the housing mechanicals.
2. Our immediate goals now are to ensure the production tooling starts at the earliest and our PVT PCB get manufactured in-time.
3. Our certification timeline was estimated earlier to 8 weeks, after detailed discussions with the lab they are confident they can pull it of within 4-5 weeks. Our teams will be physically present during certification testing to speed up overall testing time and troubleshooting.
4. The production tooling time has expanded from 4 weeks to 6 weeks after discussions with our manufacturer due to part complexity. We are working closely with them to get simplified parts ready early on for antenna tuning and certification.
5. Though the production will start later in December, we will start working on setting up the environment and fixtures required for production and testing.

All the risks are detailed in our last update - https://mecha.so/blog/charting-the-road-ahead-goals-challenges

As of now we remain optimistic to be able to run production in January and start shipping right after. The LTE variant may see few additional weeks for shipping due to its certification overhead. Next 4-5 weeks remain critical to ascertain the schedule further.

-------------------------------------------------------------------------------------------

Over the weekend we celebrated Diwali (or Deepawali) here in India, also known as the festival of lights to the rest of the world. As we push through these final laps toward production, our team has taken a pause for the next few days for a well-earned rest. 

See you with the next one!

Shoaib & Mecha team