This year, we’ve already seen sizeable leaks of NVIDIA source code, and a release of open-source drivers for NVIDIA Tegra. It seems NVIDIA decided to amp it up, and just released open-source GPU kernel modules for Linux. The GitHub link named open-gpu-kernel-modules has people rejoicing, and we are already testing the code out, making memes and speculating about the future. This driver is currently claimed to be experimental, only “production-ready” for datacenter cards – but you can already try it out!
The Driver’s Present State
Of course, there’s nuance. This is new code, and unrelated to the well-known proprietary driver. It will only work on cards starting from RTX 2000 and Quadro RTX series (aka Turing and onward). The good news is that performance is comparable to the closed-source driver, even at this point! A peculiarity of this project – a good portion of features that AMD and Intel drivers implement in Linux kernel are, instead, provided by a binary blob from inside the GPU. This blob runs on the GSP, which is a RISC-V core that’s only available on Turing GPUs and younger – hence the series limitation. Now, every GPU loads a piece of firmware, but this one’s hefty!
Barring that, this driver already provides more coherent integration into the Linux kernel, with massive benefits that will only increase going forward. Not everything’s open yet – NVIDIA’s userspace libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed, for now. Same goes for the old NVIDIA proprietary driver that, I’d guess, would be left to rot – fitting, as “leaving to rot” is what that driver has previously done to generations of old but perfectly usable cards. Continue reading “NVIDIA Releases Drivers With Openness Flavor”→
Regular Hackaday readers will know that we’re big supporters of free/libre and open source software (FLOSS) around these parts. There’s an excellent chance you are too, as so many of the incredible projects you send our way make it a habit to share their innermost details, from firmware source code to the OpenSCAD files that generate its 3D printed components. So when our recently minted Editor in Chief [Elliot Williams] was invited to join This Week in Tech’s FLOSS Weekly podcast, he jumped at the chance to represent our little corner of the Internet to the wider world of open source aficionados. (Ed: The final version is now live! How did we get episode 666?!)
Hosted by [Doc Searls], FLOSS Weekly is known for its in-depth interviews with “the most interesting and important people in the Open Source and Free Software community”, so we hope the incursion by hacker rabble such as ourselves doesn’t taint their brand too much.
It’s live streamed every Wednesday at 12:30 PM Eastern / 9:30 AM Pacific / 17:30 UTC, which means that by the time this post hits the main page of the site, you’ve still got time to tune in. For those of you with gainful employment who can’t slack off for an hour or so in the middle of the workweek, the recorded version will be available afterwards for your time-shifted viewing and or listening pleasure.
[Elliot] will be joined by Hackaday writer and regular co-host of FLOSS Weekly [Jonathan Bennett], making this something of a Jolly Wrencher double-feature. [Jonathan] has been providing readers with a regular peek into the other type of hacking with his fantastic This Week in Security column, and is himself a devout FOSS supporter with a particular passion for GNU/Linux. We’re excited to listen in as the trio riffs on open source at the crossroads of hardware and software, not just because it promises to be an entertaining bit of programming, but because it’s a great opportunity to introduce the world of Hackaday to the wider open source audience.
When we met our contact from MNT in the coffee shop, he was quietly working away on his laptop. Jet black and standing thick it was like an encyclopedia that didn’t quite blend in with the sea of silver MacBook lookalikes on the surrounding tables. After going through all the speeds and feeds we eagerly got our 64 piece driver kit out to open it up and see what made this marvel tick, but when the laptop was turned over it became clear that no tools were needed. The entire bottom of the machine was a single rectangle of transparent acrylic revealing everything from sharp white status LEDs on the bare mainboard to individual 18650 LiFePO4 battery cells in a tidy row. In a sense that’s the summary of the entire product: it’s a real laptop you can use to get work done, and every element of it from design to fabrication is completely transparent.
The device pictured here is called the Reform and is designed and manufactured by MNT, a company in Berlin, Germany (note MNT stands for MNT, it’s not an acronym). The Reform is a fully open source laptop which is shipping today and available via distribution through Crowd Supply. If the aesthetic doesn’t make it clear the Reform is an opinionated product designed from the ground up to optimize for free-as-in-freedom: from it’s solid metal chassis to the blob-free GNU/Linux distribution running inside.
We’re here to tell you that we’ve held one, it’s real, and it’s very well built.
Regular readers will likely remember the Inkplate, an open hardware electronic paper development board that combines an ESP32 with a recycled Kindle screen. With meticulous documentation and full-featured support libraries for both the Arduino IDE and MicroPython, the Inkplate makes it exceptionally easy for hackers and makers to write their own code for the high-quality epaper display.
For one thing, [Guy] has taken full advantage of the ESP32 microcontroller at the heart of the Inkplate and implemented a web server that lets you manage the reader’s library from your browser. This allows books in EPUB v2 and v3 formats to be uploaded and saved on the Inkplate’s SD card without any special software. There’s currently support for JPG, PNG, BMP, and GIF images, as well as embedded TTF and OTF fonts.
As of this writing EPub-InkPlate supports both the six and ten inch Inkplate variants, and uses the touch pads on the side of the screen for navigation. While it’s on the wishlist for the final 1.3 release, the project currently doesn’t support the Inkplate 6PLUS; which uses the backlit and touch compatible displays pulled from Kindle Paperwhites. With shipments the new 6PLUS model reportedly going out in November, hopefully it won’t be long before its enhanced features are supported.
With the rising popularity of ebooks, it’s more important than ever that we have open hardware and software readers that work on our terms. While they may never compete with the Kindle in terms of units sold, we’re eager to see projects like EPub-InkPlate and the Open Book from [Joey Castillo] mature to the point that they’re a valid option for mainstream users who don’t want to live under Amazon’s thumb.
[Rowan Patterson] informed us about a recent ticket he opened over at the Raspberry Pi Documentation GitHub repository. He asked about the the lack of updates to the Raspberry Pi 4’s USB-C power schematics for this board. You may recall that the USB-C power issue was covered by us back in July of 2019, yet the current official Raspberry Pi 4 schematics still show the flawed implementation, with the shorted CC pins, nearly two years later.
[Alasdair Allan], responsible for the Raspberry Pi documentation, mentioned that they’re in the process of moving their documentation from Markdown to AsciiDoc, and said that they wouldn’t have time for new changes until that was done. But then [James Hughes], Principal Software Engineer at Raspberry Pi, mentioned that the schematics may not be updated even after this change due to a of lack of manpower.
As [James] emphasized, their hardware will probably never be open, due to NDAs signed with Broadcom. The compromise solution has always been to publish limited peripheral schematics. Yet now even those limited schematics may not keep up with board revisions.
An easy fix for the Raspberry Pi 4’s schematics would be for someone in the community to reverse-engineer the exact changes made to the Raspberry Pi 4 board layout and mark these up in a revised schematic. This should be little more than the addition of a second 5.1 kΩ resistor, so that CC1 and CC2 each are connected to ground via their own resistor, instead of being shorted together.
Still, you might wish that Raspberry Pi would update the schematics for you, especially since they have updated versions internally. But the NDAs force them to duplicate their efforts, and at least right now that means that their public schematics do not reflect the reality of their hardware.
Python is an absolutely fantastic language for tossing bits of data around and gluing different software components together. But eventually you may find yourself looking to make a program with an output a bit more advanced than the print() statement. Once you’ve crossed into the land of graphical Python programming, you’ll quickly find that the PyGame library is often recommended as a great way to start pushing pixels even if you’re not strictly making a game.
Today, the project is celebrating an incredible milestone: 20 years of helping Python developers turn their ideas into reality. Started by [Pete Shinners] in 2000 as a way to interface with Simple DirectMedia Layer (SDL), the project was quickly picked up by the community and morphed into a portable 2D/3D graphics library that lets developers deploy their code on everything from Android phones to desktop computers.
Things haven’t always gone smoothly for the open source library, and for awhile development had stalled out. But the current team has been making great progress, and decided today’s anniversary was the perfect time to officially roll out PyGame 2.0. With more than 3,300 changes committed since the team started working on their 2.0 branch in July of 2018, it’s a bit tough to summarize what’s new. Suffice to say, the library is more capable than ever and is ready to tackle everything from simple 2D art up to 4K GPU-accelerated applications.
If you haven’t given PyGame a try in awhile, don’t worry. The team has put special effort into making the library as backwards compatible as possible, so if you’ve got an old project kicking around that you haven’t touched in a decade, it should still run against the latest and greatest version. If you’ve never used it before, the team says they’ll soon be releasing new tutorials that show you how to get the most out of this new release.
Since the release of the original Raspberry Pi single board computer, the WiringPi library by [Gordon] has been the easy way to interface with the GPIO and peripherals – such as I2C and SPI – on the Broadcom SoCs which power these platforms. Unfortunately, [Gordon] is now deprecating the library, choosing to move on rather than deal with a community which he no longer recognizes.
As this secondary use is what’s draining the fun out of the project, he has decided to put out one final release, before making it a closed-source project, for use by himself and presumably paying clients. What the impact of this will be has to be seen. Perhaps a new fork will become the new ‘WiringPi’?
Suffice it to say, none of this is a good thing. The illegal use of open source code and the support nightmare that gets poured on the authors of said code by less than informed users is enough to drive anyone away from putting their projects out there. Fighting abuse and junking the ‘spam’ is one way to deal with it, but who has the time and energy (and money) for this?
What are your thoughts on this news, and this issue in general? How should an open source developer deal with it?
Thanks to [Dirk-Jan Faber] for sending this one in.