Chipsee PPC-J1900-101-C & Me

For more than a decade, I’ve had a little monitor displaying Youtube videos in the hallway. Nothing super useful, ahem, but fun to watch while doing the boring trek from the hallway to the living room.

But there’s some problems. First of all, the monitor I’m using is a DisplayLink device — i.e., a bus-powered USB2 monitor. Which was a fun idea at the time: You only need a single cable, so it’s a lot less messy when setting up small auxiliary screens like this.

On the other hand, there’s real problems: If you want to use a DisplayLink screen as a “real” secondary screen, for instance, you really need it to be rendered by a GPU and not the CPU, and then you need to push all that data over USB2, which means… that it never really took off in a big way. They eventually made drivers that could make your GPU render the data, and then transfer the results over USB to the screen, but it was always more of a neat toy than something major.

As a result, support for this has waxed and waned. Whenever I upgrade Linux, it’s happenstance whether the monitors still work or not. For about a year, support dropped out before anybody noticed, and then they put it back… for some monitors.

So the writing’s on the wall: This technology is dead. Nowadays there’s DisplayPort over USB3/Thunderbolt, and that’s a “real” technology, where you can power a normal screen without any problems.

And another thing: Back in 2012, Linux supported these screens without any tearing, but look at this:

Massive tearing. So these days you have to run a compositor over it to avoid tearing, and *sigh*.

And thirdly, I have a “Home Automation” system that’s currently running on various “real” computers spread around the apt, and I want to move that stuff to micro machines that can be on all the time, and then I can switch the “real” computers off when I go on holidays and stuff. Without having the light switches stop working.

And there’s even a fourthly: Back in the days, it was trivial to have several completely separate displays that were independent: You just start several X servers on each display. These days, Linux really wants to grab all the displays it can get its hands on and morph them into one big screen area. And this makes sense for 97% of what people want to have several monitors for: They want a larger desktop. You can still tell the Desktop manager to fuck off and leave the poor little monitor alone, but it’s a struggle.

So: Move all this stuff to a small machine that has a 10″ screen built in. I originally planned on using one of these, but since it’s RaspberryPi 4-based, there’s so much screen tearing that it’s not even funny.

So: I got one of these — a Chipsee PPC-J1900-101-C, which is an Intel machine, which can hopefully do all this stuff.

And yesterday I got it in the mail. Thanks, Chipsee, for a speedy delivery.

Opening it, I was initially dismayed to see this weirdo power connection thing… did I have to go on a worldwide hunting expedition to find the right connector? (Because the ordering page didn’t say that they were including a power adapter.)

But no! They did include it. Nice.

And also… a pen?

With a nubby end? Huh. Well, it has a touch screen, and perhaps you don’t want the screen to get greasy, so you can use this pen…

Wow, the screen is super reflective.

I mean, it’s very bright in here, but that’s super duper reflective. Fun to see an American Megatrends BIOS on this thing.

Yes, it comes pre-installed with Ubuntu.

Localised to China, of course. But do I want to use an OS installation by Chipsee? I mean, I’m not paranoid — they really are out to get us! — but I don’t want to use Ubuntu, anyway. I’m a Debian sort of person.

So:

It’s wiping time!

Heh. The internal disk on this thing is 64GB. I mean, that’s more than enough, but it’s just a bit amusing, since the flash stick I’m installing Debian from is 128GB. And it looks like this:

*titters*

And look! Debian installed without a hitch. But I should have read the specs before I bought this. The CPU is:

Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz

Which is a model that debuted in 2013. And it’s really an Atom CPU, and these are dog slow. That doesn’t really matter much for my use case, it’s just a bit annoying when building Emacs and stuff, but whatevs.

More serious is that the network is this:

Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

Which is a notoriously flaky wifi thingy, and indeed the network is flaky. And worse, all the recommendations for how to make it be less flaky don’t really work these days, because nobody uses these things any more.

So I rooted through my drawers, uhm, right, and I found a USB wifi stick. Look! It’s barely noticeable!

OK, I need an angled USB connector…

But look! No tearing! This is with Debian bookworm, Gnome Shell and Wayland.

OK, after poking at Debian for quite a few hours, I now have a working setup that starts automatically (and this includes stuff like this Gnome Shell extension). I’m still trying to get stuff like this to work under Gnome, which is a huge mistake really — but for Wayland it’s probably going to be the compositor that wins in the end, so I might as well get on board.

I should get a better mount for the screen… perhaps wall-mount it? If I can find a less-than-huge VESA mount for it (it’s just a kilo, after all).

And yes, there’s dongles to be taken into consideration — the huge WIFI dongle, and the kinda large Telldus Tellstick one, which I use to control wall sockets. I think I’ll buy a smaller WIFI dongle, and then some of these:

That should make things tidier.

I think this is gonna be OK? The screen, which looked pretty bad in a sunny room, looks fine here in the hallway.

OK, off to buy VESA mounts, USB connectors, a wifi dongle and… er… I think that’s it? Then I’m done! Success!

Oh, it looks like the Centrino Ultimate-N 6300 is a mini-PCIe card? Then perhaps I could just swap that out with a slightly more modern card… It would get rid of one USB dongle, which would be nice.

But if I’m doing something similar like this in the future, I’m not buying this model. Anybody know of a more modern 10″ all-in-one that has working wifi (but otherwise has a similar feature set)?

[Edit: Update four days later: The Chipsee machine has died hard twice, so I guess it doesn’t work well. Oops! Gotta get a different model…]

Text Dimensions Are Hard

This blog post natters on about SVG/Emacs font issues, but ends with a question to an Emacs-knowledgeable audience. Feel free to skip to the end if you know Emacs stuff!

Anyway, eplot, the Emacs charting library, needs to know the actual text dimensions for certain things.

Not for the labels on the x axis here — eplot generates SVGs, and SVG can anchor a text to the middle. It even works well with exotic fonts like Jolie Romantique, which is my go-to font for testing weird font rendering artefacts:

Even in the presence of strange things like ligatures that represent swooshes, SVG gets it right with some renderers:

But this fails when using things like rsvg-convert. Hey, Rust Evangelical Strikeforce! Get it together!

Anyway! I wasn’t really going to whine about font rendering, but whine about Emacs. In eplot, I need to see how much space a piece of text will really end up taking, and I need that to calculate how much space I need for things like the Y axes there. And there’s really no other way to determine that than to render the text and see what you get (due to fonts having weird/useless general data, not to mention ligatures and stuff).

For instance, to have these labels centred under each bar, I need to know how tall a typical non-descending character (e.g., “x” and not “g”), because when you specify where to put a text in SVG, the position it renders from is that baseline.

That approach even works with exotic fonts.

So… determining the actual room a text will take is necessary — not only to place the texts at the right place, but to determine how many of the texts we have room for on the axes. We can “eyeball” these things sometimes — we can take the font size and make “guesses” based on that… but in the chart above, the font size used is 60.

And in this chart, where the characters are approximately the same size visually, the font size used is 30!

And that’s the problem I’m whining about here!

OK, if you’re using very normal, boring fonts at lower point sizes, these problems aren’t massive, but once you start stepping up the point sizes, the charts soon look pretty ugly, what with off-centred tick marks and the like.

For instance, did you notice that the vertically rendered x-axis tick marks in the chart above were wrong? Me neither, until I started writing this.

There. Fixed. It was using the height of an “x” to determine the baseline, because that’s generally correct with text (“Thing” both ascends and descends, and you have to be consistent), but if the labels are all numerical, they just ascend from the baseline, making them off-centre.

*phew*

Anyway, an obvious way to see how much space a text takes is to create an SVG, convert it to PNG, strip away the background and then see what’s left. So let’s see how much time it takes.

(benchmark-run
  (cl-loop for size from 0 upto 99
           collect (eplot--text-size-1 "Testing" "futura" 'bold size)))
=> 22.8

Yeah, 22 seconds to do 100 texts using ImageMagick convert to determine the sizes. Because ImageMagick is dog slow on SVGs — it calls out to other programs to do the rendering.

(In practice, this isn’t quite as horrible as it sounds — for a typical chart, eplot only has to measure a couple of strings. And it caches the values.)

(benchmark-run
 (cl-loop for size from 0 upto 99
          collect (eplot--text-size-1 "Testing" "futura" 'bold size)))
=> 4.694829387

But if I do the rendering with rsvg-convert, it takes a fifth of the time. But now we need two external programs, one of which isn’t installed on that many systems…

Emacs does have built-in things to determine the actual width of a text (because I built it into Emacs 😉), so let’s try that:

(benchmark-run
  (cl-loop for size from 0 upto 99
           collect (eplot--text-width-2 "Testing" "futura" 'bold size)))
=> 0.19

Hey, nice! 0.2s is a lot faster than 4.7s (or 22s).

So what am I whining about? Here’s what I’m whining about: Emacs doesn’t have a way to see how tall a text is!

What am I talking about! Of course it does! But no.

Emacs has line-pixel-height, and that’s the room Emacs reserves for a line. (The red box there shows it.)

So that’s the size of the “F”, right?

No, it’s just using the font metrics, and there’s no way to get Emacs to tell me how tall that “o” really is.

I think! Does anybody know how to make Emacs cough out some data on that? It sucks to have to rely on external programs for stuff like this.

C’mon! Emacs power!