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

September 21, 2021 by Donald Papp 24 Comments

[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.

Controlling External Monitors On M1 Macs With Undocumented APIs

September 8, 2021 by Maya Posch 8 Comments

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 I²C 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

April 24, 2021 by Jenny List 8 Comments

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

March 21, 2021 by Bryan Cockfield 41 Comments

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

December 3, 2020 by Maya Posch 49 Comments

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.

This Week In Security: Zero Days, Notarized Malware, Jedi Mind Tricks, And More

September 4, 2020 by Jonathan Bennett 5 Comments

Honeypots are an entertaining way to learn about new attacks. A simulated vulnerable system is exposed to the internet, inviting anyone to try to break into it. Rather than actually compromising a deployed device, and attacker just gives away information about how they would attack the real thing. A honeypot run by 360Netlab found something interesting back in April: an RCE attack against QNAP NAS devices. The vulnerability is found in the logout endpoint, which takes external values without properly sanitizing them. These values are used as part of an snprintf statement, and then executed with a system() call. Because there isn’t any sanitization, special characters like semicolons can be injected into the final command to be run, resulting in a trivial RCE.

QNAP has released new firmware that fixes the issue by replacing the system() call with execv(). This change means that the shell isn’t part of the execution process, and the command injection loses its bite. Version 4.3.3 was the first firmware release to contain this fix, so if you run a QNAP device, be sure to go check the firmware version. While this vulnerability was being used in the wild, there doesn’t seem to have been a widespread campaign exploiting it.

Continue reading “This Week In Security: Zero Days, Notarized Malware, Jedi Mind Tricks, And More” →

Linux Fu: Turn A Web App Into A Full Program

December 5, 2018 by Al Williams 68 Comments

I hate to admit it. I don’t really use Linux on my desktop anymore. Well, technically I do. I boot into Linux. Then I do about 95% of my work in Chrome. About the only native applications I use anymore are development tools, the shell, emacs, and GIMP. If I really wanted to, I could probably find replacements for nearly all of those that run in the browser. I don’t use it, but there’s even an ssh client in the browser. Mail client? Gmail. Blogging? WordPress. Notes? OneNote or Evernote. Wouldn’t it be great to run those as actual applications instead of tabs in a browser? You can and I’ll show you how.

Having apps inside Chrome can be a real problem. I wind up with dozens of tabs open — I’m bad about that anyway. Restarting chrome is a nightmare as it struggles to load 100 tabs all at once. (Related tip: Go to chrome://flags and turn “Offline Auto-Reload Mode” off and “Only Auto-Reload Visible Tabs” on.) I also waste a lot of time searching since I try to organize tabs by window. So I have to find the window that has, say, Gmail in it and then find Gmail among the twenty or so tabs in that window.

What I want is a way to wrap web applications in their own window so that they’d show up in the task bar with their own icon, but external web pages that open from these apps ought to open in Chrome rather than in the same window. If applications were outside of the single browser window, I could move them to different desktops and organize them like they were any other program, including adding them to a launcher. Hopefully, this would let me have fewer windows like this: