Linux: Coming Soon To M1 Macbooks

Regardless of the chipset or original intended use of any computer system, someone somewhere is going to want to try and run Linux on it. And why not? Linux is versatile and free to use as well as open-source, so it’s quite capable of running on almost anything. Of course, it takes a little while for the Linux folk to port the software to brand new hardware, but it’s virtually guaranteed that it’s only a matter of time before Linux is running on even the most locked-down of hardware, like the M1 MacBooks.

[Hector Martin] aka [marcan] has been hard at work getting Linux up and running on the latest Apple offerings with their ARM-based M1 processors. Since these are completely divorced from their x86 product line the process had to be worked from the ground up which included both booting Linux and modifying the kernel to include support for the hardware. [marcan] has a lot of hardware working such as the USB ports and the SD card slot, and notes that his setup is even compatible with the webcam notch included in the latest batch of MacBooks.

There are a few things still missing. He’s running Arch and doesn’t have the GPU configured yet, so all of the graphics are rendered in software. But he has put the computer through the wringer including running some computationally-intense software for nearly a full day before realizing that the machine wasn’t charging, which did not make much difference in performance. These machines are indeed quite capable with their new ARM chipsets and hopefully his work going forward will bring Linux to the rest of us who still use Macs even if they don’t want to run macOS.

A miniature iMac clone running MacOS Monterey

Cute Little IMac Clone Runs MacOS On A Tiny Screen

Building a Hackintosh – a non-Apple computer running MacOS – has been a favorite pastime of hackers ever since Apple made the switch from PowerPC to Intel hardware. Though usually built from commodity PC parts, some have successfully installed Apple’s OS onto various kinds of Intel-based single-board computers. [iketsj] used such a board to build a cute little Hackintosh, and apparently decided that if he was going to imitate Apple’s hardware, he might as well take some clues from their industrial design. The result can be seen in the video (embedded below) where [Ike] demonstrates a tiny iMac-like device with a 5″ LCD screen.

The brains of this cute little all-in-one are a Lattepanda, which is a compact board containing an Intel CPU, a few GB of RAM and lots of I/O interfaces. [Ike] completed it with a 256 GB SSD, a WiFi/Bluetooth adapter and the aforementioned LCD, which displays 800×480 pixels and receives its image through the mainboard’s HDMI interface.

The case is a 3D-printed design that vaguely resembles a miniaturized iMac all-in-one computer. The back contains openings for a couple of USB connectors, a 3.5 mm headphone jack and even an Ethernet port for serious networking. A pair of speakers is neatly tucked away below the display, enabling stereo sound even without headphones.

The computer boots up MacOS Monterey just like a real iMac would, just with a much smaller display. [Ike] is the first to admit that it’s not the most practical thing in the world, but that he would go out and use it in a coffee shop “just for the lulz”. And we agree that’s a great reason to take your hacks outside.

[Ike] built a portable Hackintosh before, and we’ve seen some pretty impressive MacOS builds, like this Mini iMac G4, a beautiful Mac Pro replica in a trash can, and even a hackintosh built inside an actual Mac Pro case.

Continue reading “Cute Little IMac Clone Runs MacOS On A Tiny Screen”

Mini Wireless Thermal Printers Get Arduino Library (and MacOS App)

[Larry Bank]’s Arduino library to print text and graphics on BLE (Bluetooth Low Energy) thermal printers has some excellent features, and makes sending wireless print jobs to a number of common models about as easy as can be. These printers are small, inexpensive, and wireless. That’s a great mix that makes them attractive for projects that would benefit from printing out a hardcopy.

It’s not limited to simple default text, either. Fancier output can be done using Adafruit_GFX library-style fonts and options, which sends the formatted text as graphics. You can read all about what the library can do in this succinct list of concise functions.

But [Larry] hasn’t stopped there. While experimenting with microcontrollers and BLE thermal printers, he also wanted to explore talking to these printers from his Mac using BLE directly. Print2BLE is a MacOS application that allows dragging image files into the application’s window, and if the preview looks good, the print button makes it come out of the printer as a 1-bpp dithered image.

Small thermal printers make for neat projects, like this retrofitted Polaroid camera, and now that these little printers are both wireless and economical, things can only get easier with the help of a library like this. Of course, if that’s all starting to look a little too easy, one can always put the thermal back in thermal printing by using plasma, instead.

Screenshot of MacOS Lunar app

Controlling External Monitors On M1 Macs With Undocumented APIs

Display Data Channel (DDC) is a very useful feature of modern digital displays, as it allows the graphics card (and thus the OS) to communicate with a display and control features such as brightness and contrast. The biggest negative aspect here is the relatively poor access to this feature within an operating system like MacOS, which can change on a whim, as [Alin Panaitiu] found out recently.

Current displays implement DDC2, which is based around an I2C bus. Despite this, few OSes offer DDC-based control of features such as brightness which is where [Alin] developed a popular utility for MacOS that used undocumented APIs to talk DDC2 with external monitors via I2C. Until the new Arm-based Mac systems got released and these undocumented APIs got changed, that is.

Even though there are some ways around this, with some utilities using a simple software-based overlay to ‘dim’ the display, or using an external gamma adjustment via an external Raspberry Pi system hooked up to HDMI and using ddcutil, the best way is still via DDC2. Ultimately the new (undocumented) APIs that provide access were discovered, with another user going by the name [zhuowei] notifying [Alin] of the new IOAVServiceReadI2C and IOAVServiceWriteI2C methods with Arm-based MacOS.

After this it took some more sleuthing to figure out which of the devices on the I2C bus were which monitor in the case of multiple external monitors, but in the end it all worked again, adding hardware-based brightness controls back in the hands of MacOS users. Minus a few apparent hardware issues with HDMI on the M1 Mac Mini and some displays, but who is counting?

[Heading image: Screenshot of the Lunar app on MacOS. Credit: Alin Panaitiu]

A Modern Mac Using An Ancient Mac Display

If you own an Apple product you probably live in a world with a few proprietary interfaces, but by and large your displays and desktop peripherals will use familiar ports such as USB and DisplayPort. For the Mac owner of yore though it was a different matter, as [Dandu] is here to tell us with the tale of a vintage Apple monochrome CRT monitor and a modern Mac.

There are no handy VGA ports to be found in this screen, instead it has a 15-pin D connector following a proprietary interface. With the right adapter it’s easy enough to produce VGA from the modern machine, but while it is in theory possible to map VGA pins to Apple pins there’s a snag with this particular model. Instead of using separate sync pins, it demands a composite sync of the type you might find in an analogue TV set that contains both horizontal and vertical sync pulses. The solution came through a simple transistor circuit, and then with the requisite settings on the modern Mac to deliver the 640×480 resolution it was possible to see a MacOS Catalina desktop on something more suited to a Mac II.

We’re more used to seeing CRT Macs in the form of the venerable SE/30, a machine that’s been on our radar for a long time.

The Long Journey Ahead For Linux On Apple Silicon

An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.

While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.

While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.

Thanks to [Mark] for the tip!

FTDI VCP Chips With Custom PIDs Not Working On MacOS 11 Big Sur

An anonymous reader pinged us about an issue that affects people who jumped onto the latest-and-greatest OS from the Apple gardens: USB devices that stop working due to the FTDI-based USB solution. At its core appears to be that the built-in FTDI driver provided by Apple (AppleUSBFTDI.dext) only supports FTDI chips which provide the standard FTDI vendor and product ID (e.g. 0x0403 and 0x6001 respectively for the FT232R). Many products however set a custom product ID (PID) to differentiate their device, though in the thread some mention that there are driver issues even with the default VID/PID combination.

Over the past years, Apple has been restricting and changing the way kernel extensions (KExt) and driver extensions (DExt) are handled. As these FTDI chips are often used for virtual com port (VCP) purposes, such as with Arduino boards and USB-TTL adapters, this is a rather cumbersome issue that would affect anyone using Big Sur in combination with such a hardware device.

So far only the FTDI team has been somewhat responsive based on the support forum thread, with Apple seemingly rather silent on the issue.