Community contributions

We have a lot of talented people here in this forum and I think it’s important to remember that the beauty of such an open platform means that we can all contribute and are not confined to the whims of a proprietary entity.

I’m starting to discover several folks who are intrigued by the Reform and would like to contribute but are not quite sure how to get started, where they fit in, or what the roadmap looks like so that they can make the most of their time.

I obviously cannot speak authoritatively on the direction of this project, so I’d need a good amount of guidance from Lukas and others, but I’m happy to volunteer my time to help create GitLab milestones, issues, comments, etc. This could potentially help guide people to address problems in an organized and documented way. Perhaps one day if we’d want to propose a public call to arms, if anyone is familiar with the FreedomBox Foundation, one thing I like is that they sometimes publish “contributor invites” on their social media. These posts describe the overall nature of the task, whether it’s more of a programming or documentation task, the estimated time commitment, and the expected difficulty level.

So how do you think we can all come together to make this the best computing platform possible? How can we help encourage potential contributors and ensure they have the information they need to help provide meaningful contributions? I’d be interested in hearing your thoughts.


Sorry - it’ll be rather long and chaotic message, more result of brain dump than clean summary or response. I’m not trying to find solution here (at least not fully) but more present my voice in this discussion.

The beauty of MNT Reform platform and community is width of possible areas of contribution. Some of them we can already see in this forum:

  1. Hardware mods and improvements, including case, keyboards, accessories, wireless antennas… Some of them lead to solutions sold by MNT.

  2. (Partially related to above) fixes to firmware (keyboard backlight, sleep) and new functionalities (battery status in OS/kernel).

  3. Various OS; I’ve seen SculptOS, someone mentioned Arch…

I guess this area will need to expanded when we have more official CPU modules (faster ARM, FPGA with RISC-V). We (MNT and community) will need to find solutions to manage many OS (either separate or variants) without too much overhead when those are available.

All of this gives me hope and energy: there is so much to do, so many opportunities to experiment, so many things to try… At the same time I’m not sure if current community is large enough to follow all those areas. So far I’ve seen few examples when someone comes with solution to some problem or new feature, gets few comments “that looks nice”, few likes, and then thread goes silent (e.g. keyboard light fade-out, kernel module for battery status). But maybe some ideas are just solution for particular people’s problems, and don’t need to be followed by others? Sometimes it might however make sense to incorporate such solution to MNT scripts, or even to Debian package or upstream project.

My example: I’m currently working on scripts to prepare my own Debian image. Official scripts are quite good, but I want to customize my image (use btrfs with subvolumes, set encryption differently, …). So far I’ve been treating it as my niche, not sure if it would be interesting to others - especially as when someone wants to make deep customization, it is easier to start from scratch and not try to twist some other scripts. But I’ve already encountered problems with initramfs or u-boot and btrfs subvolumes, and with waking NVMe from sleep. I’ll also want to look into hibernation (at later stage). Not sure yet if I’ll need some help with that, but I guess description of solutions will be interesting to others.

Looking wider - I guess when someone has idea, testing their solution by other people might be useful. It might be already good idea to go through many threads and gather ideas and their partial solutions. But I’m not sure if forum is the best place for gathering such knowledge and manage longer-term projects. Maybe wiki page or issues on might be better place here.

Thanks for starting this discussion; let’s hope we can develop MNT Reform into better platform!

1 Like


thanks for the initiative! From my POV there have been significant contributions from community members, not only in terms of mods but also features that have already made it into production. Some of these are huge and mainly driven by people who successfully scratched their own itch. Some examples (tell me if I forgot something):

  • Trackball improvement with bearings
  • LPC SPI / Battery status kernel module (this is shipping, but not well enough integrated in the desktop)
  • Clean Debian integration (remember how we shipped custom mesa in /usr/local ? Nowadays you can just apt upgrade)
  • Sleep/power saving for keyboard MCU and LPC
  • 9front Port
  • Genode Sculpt OS Port

Moreover, based on feedback and reviews, we as MNT shipped a bunch of improvements/additions this year:

  • Steel port covers
  • Protected battery boards (batch 1 just arrived, shipping next week)
  • Continuous testing and feedback to the etnaviv and VPU driver developers, resulting in higher performance, less bugs and h264+now h265 decoding
  • Keyboard firmware refactoring and media keys
  • OSHW USB Camera (will ship later this month or latest in January)
  • OSHW Standalone Keyboard

The most anticipated updates are of course CPU modules with better performance and RAM. These are the most complicated and time consuming projects. I could always use help here from skilled KiCAD engineers and kernel hackers, but these people usually already have enough other things on their plate. I can post more about the status of these later.

I also always have smaller things on the TODO lists that are maybe more feasible for community members to tackle. If people are interested in helping out, I can share these from time to time.

Some examples:

  • The keyboard had a low battery alert in the beginning, that stopped working at some point. Bring it back, and also integrate a low battery alert in the OS. A few times I had Reform turn off on me while watching a movie–forgot to plug in the power brick.
  • Port the HDMI Audio driver from the vendor kernel (imx8mq).
  • If the keyboard is woken up during deep sleep (when the machine is off), I’m not sure if it goes to sleep again automatically (LPC does it, I think). Investigate+fix this.

FWIW my perspective on community contributions is that I’m confident enough to do a bit of hacking on stuff, but don’t have enough experience with open source in general to feel great about pushing those contributions to others. I have far too many hangups around “oh no is this The Right Way To Do This”.

Having a list of things that need sorting out is super helpful for me, bc then I can just jump in and know that what I’m doing is useful.

@mntmn re the low battery warning: mine still works! which is odd, bc I thought the diff between my fancy keyboard layout and the mainline keyboard firmware was pretty small. I wonder if the diff will be helpful for tracking things down.


This is interesting. I think I don’t work like this at all. :smiley: For me, what makes me feel that something is useful is “scratching my own itch” as Lukas called it above. Once I’m satisfied I’ll then share what I did as a merge request, on this forum or via irc. If others find it useful: great! If not: no problem either. :slight_smile:

I’d be very interested in a low battery warning for the oled display! Another feature request of mine would be a small info message once the power cable is plugged and unplugged. Right now, every time I plug in the power cable I manually check the oled screen whether the reform is really charging or not. If such an indicator could pop up by itself, that would be great! :slight_smile:

Other than that I really have a hard time thinking about other things that I’m missing with the reform. It has been my only laptop for many months now and since hardware h264 decoding works it can do everything I need my laptop to do. It would be nice if ffmpeg would support it too so that I can use mpv again but clapper+gstreamer works just fine. With Linux 6.1 and gstreamer hardware h265 decoding will also be available. Yay!

My only wishlist items are very low priority stuff:

  • low battery and power plugged indicator for the oled (see above)
  • display could be turned on by u-boot and not by the kernel later

I’ll update above list if anything else comes to mind but I’m a very happy customer. :slight_smile:


  • upstreaming u-boot support
  • upstreaming linux support
  • having only a single dtb upstream instead of having to switch between two dtbs (see my post below)


  • tags and changelogs for keyboard and mainboard firmware

Moderation note: I removed a rude post that contained swearing, personal attacks and was causing bad vibes here. I also set the person on “Ignore” as I have zero tolerance for such behavior.

As the person conflated moderation with censoring, and to show that I don’t have an issue with criticism per se, I will repeat a summary of their criticisms here, in a more objective manner, and some responses:

  • MNT Reform was released with flaws/bugs.

That is true, and normal for most products. We are transparent about it and we have worked and are working on improving the product.

  • MNT Reform misses its goal of being an “open source” device, as there is a piece of closed-source firmware that has to be loaded into the DDR PHYs embedded MCU on startup for training.

MNT Reform is still open hardware according to the OSHWA’s definition of open hardware; namely, the hardware design sources are available in a format editable by the public. The Boundary Devices i.MX8M SOM is a standard component that can be bought off Mouser.

Also, there are no binary drivers/blobs running on the CPU, which was a major goal and motivated the choice of i.MX8MQ in the first place; namely, open source GPU drivers (etnaviv), good documentation and mainline support compared to other options.

The FSF RYF program does not tolerate a firmware blob like the DDR PHYs because of the way their rules are structured. I will not argue about the rules, because if that’s a mental model that works for them and people who buy hardware according to RYF, that’s fine. I personally have a different model.

Moreover, LS1028A is around the corner, which you can theoretically combine with a framebuffer card to get to a blob free system if this is your major pain point.

  • MNT Reform System Image is badly engineered because building the image requires a chroot for some steps.

I don’t really get the problem with this, sorry. Chroots and containers are just normal features of modern operating systems. Also, noone has to build their own image, one can just download it from our CI server.

  • Debug output should go on screen, not a UART.

While this is an inconvenience, most people will never need to use this sort of debugging; and most embedded engineers are fine with using a UART. I would still be very happy about someone finishing bluerise’s work to bring the display to life in u-boot (one could, for example, port the pretty minimal code from 9front).

  • There is no battery cutoff switch.

That is correct, but the newly released battery boards have MOSFETs that disconnect the batteries should they fall below a safe voltage, so it is no longer necessary to remove the batteries for storage.


Main things of interest to me are getting mainline linux kernel support and mainline u-boot support… and maybe a way to semi-regularly check on the upstreaming progress, maybe something kind of like:

Once we have mainline support, I can help with getting the packages into Debian and Guix and work on out-of-the-box support (as much as is possible).


Ah indeed, mainlining is still an issue for u-boot and linux unfortunately. I’ll have to add that to my wishlist above.

This also reminds me of another todo item. I talked with Lucas Stach and they pointed out that they want to make it so that there is only a single device tree upstream that allows for both the internal display and hdmi instead of having two different DTs (only one of which is upstreamed) that the user can switch between. Lucas plans to drive the internal display by the eLCDIF controller always, instead of the DCSS. This means the GPU wastes a bit of memory bandwidth copying the final image, as the eLCDIF can not handle the GPU tiling format directly. However the eLCDIF has better power efficiency…