Checking In On The Damn Linux Tablet One

Tablets, slates, phones, and fablets, there are no shortage of electronics that take the Star-Trek-ish form factor of a handheld rectangle of glass that connects you to everything. This is the world we live in, but unfortunately it’s not currently a world with many Linux options, and certainly not one that includes modular design concepts. This is what motivated [Timon] to design the Damn Linux Table one, a “Proper Linux Tablet” built around the Nvidia Jetson Nano board.

The design really took off, because who isn’t interested in the ability to upgrade and customize a tablet? During last year’s Hackaday Supercon we caught up with [Timon] for an interview the morning after he won the Best Design prize for DLT one. Check out that video below, then join us after the break for an update on the latest from the project.

There’s only one week left to get your project entered in the 2020 Hackaday Prize. We won’t know this year’s winners until the Hackaday Remoticon rolls around this November. The Call for Proposals for that virtual conference is still open!

[Timon] is realistic about the limits of modular design. He readily admits you’re not going to upgrade a graphics card on a mobile device, but when it comes to the peripherals, why not? You might want to choose between micro-USB, USB-C, barrel-jack, or do something completely custom. One hacker’s NFC equipment might be replaced by another’s SDR or LoRa. This tablet design sees a world where connecting PCIe components to your mobile devices is completely doable. The point is to make a base model that works great, but has the potential to be what each different user wants their device to be.

It should have come as no surprise to everyone paying attention that [Timon] won the Best Design in the 2019 Hackaday Prize for the Damn Linux Table one. He tells the story of the design is this superb overview video that includes a teardown of the prototype. In it we’re introduced to the aluminum plate that makes up the central slice of the tablet, with screen attached to the front side and the uniformed modular mounting holes milled around the edge of the back side that allows components and spacers to be easily positioned.

At the center of the plate is the “motherboard” designed to break out the IO of the Jetson Nano system-on-module (SOM). Flat cables bridge the gap from the motherboard to peripherals you choose to use. The really interesting thing about the Jetson is that it uses a SO-DIMM module and [Timon] went with a reverse-mount connector. That way, a cutout in the motherboard allows the module’s chip to pass through the circuit board and make contact with the aluminum plate as a heat sink.

The $10,000 prize has allowed him to continue iterating on the design. Last month we were treated to an update on the progress of the tablet’s display. It was a struggle to get the DisplayPort screen working because there is a bug in the driver when dealing with 2-lane screens. The 10.1″ 4-lane screen shown here is working at a beautify 2560×1440. With that technical hurdle pushed aside, progress is once again under way to polish up the fit and finish and begin work on the battery management system.

Projects like this one are a tour de force of skills that at one time would have taken an entire company. The fact that this can be designed by one person is a testament to the hacker community sharing feedback and skill, the availability of design tools, the accessibility of supply chains for individuals, and above all the determination of Timon to see the project continue. Head on over to his project page, there’s a week’s worth of reading there and the opportunity to send kudos and constructive feedback.

27 thoughts on “Checking In On The Damn Linux Tablet One

  1. This inspires just a whole bunch of motivational questions in my mind. Why not just use a pinetab? Why not just use Android? Why use a tablet form factor at all, why do we need something between phones and 12″ laptops? That last one is one I can’t personally make much headway on…I’ve owned several tablets and I basically never use them, the one enduring use case is viewing digital sheet music. A tablet sits on the stand well, but since none of my laptops are “convertible”, nothing else will…and the phone is too small.

    But “why not just use android” is a question that keeps coming back to me with more urgency each year. My first tablet (original Nexus 7), after I realized I never used it for anything anymore, I hung it on the wall in the bedroom and used it as an alarmclock. But due to some well-known but poorly-described flaw (in the built-in flash chip?), it got slower each year. After 5 years, it became too slow to use as an alarmclock. Too slow to use as an alarmclock. That’s one I still have trouble wrapping my mind around — just how poor is the engineering in Android?

    I once had a feature that was common between two different apps I’d written, and I had consumed enough Android kool-aid that I wrote it as a third app that offered this feature as a Service to the other two. I found out when I began using it that RPC takes a full half second on Android! No GUI, just sending a 10-byte message to another app and getting a 1-bit reply, half a second! That was on a new flagship phone at the time (original Moto X). The hardware has gotten a lot faster since, but this fundamental fact remains…RPC on Android takes real wall time. I was stunned, and simply re-factored to put the feature independently in both apps. In some ways, Android is technologically astoundingly bad. This is the kind of failure that made me flee Microsoft in the 90s. This is “MS Word 6.0 can’t keep up with touch-typing” bad.

    In other ways, though, I love Android. The bulk of the common parts of the Java API and XML layout descriptions are pretty tolerable. Punting to JNI directly into a framebuffer has always served me well for graphics-intensive applications. I was stunned the first time I learned that Java takes measurable wall-time to process 10kB of flat text — even if you’re smart about using byte[] instead of String — but that, too, was quickly resolved with JNI. It’s decently well-documented and decently transparent (open). And the old SDK (using ant) was pretty easy to work with, and if you just want to run your app on your hardware, you can still just use that…write for SDK version 7 and run it on any new phone. Impressive backwards compatibility.

    But then Android is such a moving target, and if you publish on the app store they make you update to the new SDK every year. On top of that, the development culture at Google sucks — the “brand new” SDK they just forced you to upgrade to is based on core components that have already been abandoned/obsoleted internally. They’ve already abandoned fixing bugs in this new version, even before it was released to/forced upon external developers. New user-facing bugs appear and you can’t simply downgrade if the bugs are too harsh. For years they told you to use the default themes, but vendors (Samsung) would override colors such that all your text would wind up white-on-white and no one could use it. Now Google itself keeps changing the default themes, so every button winds up white-on-white even with new versions of the stock OS. You have to manually specify foreground and background color for every element now! Colors are just a tiny example, the whole API is now like this. It’s a constant experience of debugging stupid Google mistakes just to keep up with the mandatory SDK updates. Nevermind that the SDK has grown to 44GB and takes hours to update every time you load it. Eclipse! It’s 2020 and people are still forcing me to use Eclipse!!

    But there’s nothing else even close. iOS is worse in every possible way, for example. And on a tablet, even I do not really want a command-line interface, and I’ll be damned if I’m gonna use some KDE or Gnome-derived garbage, they’re as bad as Android just less well-supported. And it is frankly really cool that a couple apps I made just for my own self, thanks to the wide compatibility of Android, now have 13,000 users between them.

    I had a little hope for apps in browsers to help, but every time I’m actually using HTML I don’t get to the point of being struck by the fact that HTML is actually a crappy screen layout language because the performance is always such a complete non-starter at the proof-of-concept stage. I’m not talking about games, either, I’m talking about an app that displays a 2000×1000 static scaled PNG on the screen, and the browser on any Android device older than a year simply can’t do that in less than a second. Once you accept that your page will take seconds to load, it is amazing what a browser on a modern PC can do — even VR. But if you just want to do basic 1980s-style computer tasks, 10 print “hi” sort of stuff, it is always amazing to me that even modern PC browsers can’t deliver a satisfying performance for these elementary operations.

    So I really don’t know what we should do.

        1. His post contributes cool information about the inner workings of Android and the struggle of developing a sandboxed OS. I know almost nothing about android app development and backends, but I have been using Android for over a decade. This was a fun read, and reminds me of my own issues I’ve had using tablets.

          A little off topic, yes. Cool info and insider experience on a blog known for digging into technical details, absolutely!

          Here’s to my 2013 Nexus 7 living long enough to at least be used as an alarm clock in the future…

    1. I know that MS is pretty unpopular with many in this group… but if you are hating the Eclipse environment (I do), and don’t like the rough feel of the various Gnome/KDE environments, I find Visual Studio to be an amazingly powerful IDE. If you can’t stomach using Microsoft stuff, the JetBrains IDE is also quite good.

      1. from the pot into the frying pan :) i want efficient simple commandline tools. I only use eclipse to update the SDK, and I object to the fact that it takes forever to load, and then forever just to explore the menus, and then forever to perform the update. And most of all I object to the fact that what it’s actually doing is almost completely opaque.

        I don’t mind its editing features/UI, because I never use them. :)

          1. i was very interested in it, but it still requires the full ‘android studio sdk’ experience. it’s not interacting with android directly, it’s just using the C++ API that underlies the java API.

      2. It’s a myth that one needs an IDE at all to write code. A nice code editor (Geany, Sublime, Gedit, …) and a terminal application are entirely sufficient.

        File browsing? Use the regular file browser.

        Looking at the just built web page? Use the regular web browser.

        Building? Type ‘make’ or ‘npm build’ or whatever is needed into a terminal and hit enter. Next time it’s just arrow-up and enter.

        Searching text? Use ‘grep’. Ten times faster than any IDE-integrated search, anyways.

        As a nice side effect, working in a more bare bones environment helps quite a bit to understand what’s actually going on. No more “magic” features, these just blur the procedures and make it harder to grok actual mechanisms.

        1. Maybe you should try writing ioctrl codes directly to your HDD instead of using those fancy text editors. And why use a compiler? Just write the machine code yourself. As a bonus, no more “magic” features that blur the lines that prevent you from actually groking all of the mechanisms. Or if you are really hard-core, just use butterflies.

          In all seriousness, if what you describe is all you think an IDE does, you probably haven’t ever used one. There is a considerably more to them than just file browsing, building and searching text. That would be the bare minimum, and yes, not much more useful than a good text editor and a make file.

          1. Well, I write code for a living and each time I try one of these IDEs, they come with three things:

            – Duplicating many parts of the general desktop.

            – Hidden procedures to do this or that. Me is the developer, so I certainly want to know what’s going on and how stuff works.

            – Slow and complicated to use. Endless chunks of not needed features (because they try to please everybody).

            One can deal with this to some extent by disabling most of these “features”. But general experience is, dropping IDEs altogether takes a bit longer to get a project started, but allows long term to dance circles around those sticking to them.

          2. Fair enough. But as long as we are in something of a pissing contest – I also write code for a living. I find that many of these features, too many to count, are huge time savers and often help prevent easy-to-miss mistakes. To each his/her own I suppose.
            As one developer to another though, be careful not to let the state of the art pass you by. I’ve seen it happen too many times. Many shops are not going to be impressed by someone shunning the tools the rest of the team uses and likely depends on. Though if you are able to remain in the top-tier for your niche, you’ll probably always find a well paying spot – or make your own spot.

          3. I have to grin a bit. Somehow it appears like you correlate not using an IDE with some backwards orientation, while for me it’s exactly the opposite, and I receive proof regularly.

            “State of the art” is just the lowest common denominator. There are better measures for quality. For example size and performance of the build result or speed to develop bug fixes and feature implementations. With an IDE one can do only what this IDE allows to do, using the command line and specialized applications one has the whole world of tools at one’s disposal. That’s why IDE users approach me when they’re stuck, why I consider leaving IDEs behind is an achievement and why my build results often outperform everything else by a margin.

            One caveat, though. As IDEs are so high in fashion, independent code editors I’m aware of are currently a bit behind. I wish I could cut one of these IDE code editors out of their IDE for using them solo.

    1. We use Jetson boards at my job and they’re junk. The arm cpu is dead slow and the configuration using a device tree is a nightmare to work with. It needs signed binaries to boot from and the third party carrier boards have features that just plain don’t work. Documentation isn’t great and neither is support. Internal throughput is also bad when trying to stream data from usb3 devices.

      1. Most of that isn’t true. The arm CPU is not supposed to be fast. The GPU is what you pay for. It does not need signed binaries to boot, unless you can figure secure boot, In which case you sign your own.

        Documentation is comprehensive but no one reads it. There is also a forum where you can communicate directly with the developers, who are, actually, responsive. If you’re having problems with the USB port you should ask on the forum. It might be a hardware issue in which case you can RMA it.

        I work with these boards everyday, for fun and for pay. Everyone took Linus’s joke too seriously. Nvidia is not a bad company. Sure not everything is open source, but quite a lot is. Besides, No arm boards are 100% open.

      1. The Nexus 7’s cheap nand was the issue. Not sure about the Nexus 9. In any case, Google isn’t making Android tablets anymore so you have nothing to complain about.

  2. Waaay too much negativity here. Personally I wish I’d thought of it. I have a dozen Android tablets in various stages of battery death all over the house. Why? Because a book color was better built w better power management for a decade. Windows on anything under 12″ is a joke. But I’ve been working on Linux portables since my dauphin dtr1. I ordered a pine tab, just wish it was 10″. But they are using the crippled version. Like trying to run a desktop off a pizero. You can but should you? I think this guy has the right plan and I hope more folks follow his lead. After all that’s how we got the pinebook pro a perfectly good daily driver for me.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.