Astro Slide Early Impressions

The keyboard is bad, and Planet Computers should feel bad

Earlier this week, on the 3rd January 2023, a nearly 3-year saga entered it’s next phase: I finally received the Astro Slide 5G Transformer I backed on Indiegogo back in May 2020. The original estimated delivery date was March 2021, so it’s been A While.

Astro Slide

I’ll say straight away that I haven’t switched to the Astro as my daily driver; in-fact I haven’t even put a SIM card in it yet, but I do have some impressions to share.

The Keyboard

The keyboard is bad, and Planet Computers should feel bad.

  • Me, just now

The Astro was never going to be a Good Phone. Building a top-tier phone in the 2020s needs an army of engineers, huge validation and quality acceptance programs, and large-scale pre-release user testing. Planet Computers (henceforth PC) simply can’t offer or afford any of that.

However, PC do have a unique selling point: They are the only people making a phone like the Astro, with a “proper” two-hand keyboard. Arguably they have the best heritage making keyboard phones too, based on the involvement of Martin Riddeford, who designed the Psion Series 5 keyboard.

Sadly, the Astro’s keyboard falls far short of my expectations.

According to Janko (Mrsic-Flogel, the front-man of PC and the Astro campaign), the Astro keyboard is Planet’s best yet (I’m paraphrasing, I’d like to provide a reference but I think it’s buried in one of the hour-long Indiegogo update videos and I really can’t be bothered. More on that later). If this is true, then their previous devices must have been abysmal.

Size and Layout: Good

The size and layout I’m totally OK with. As promised, the keyboard really is big enough to use on a desk with two hands.

Keyboard size with two hands

In a device this size, the layout is going to have to make compromises. This is fine, having used a variety of small devices with strange layouts over the years, I generally find it doesn’t take long for the brain to adjust to new strange key positions, symbol locations, etc (that said, the position of the comma key, and bizarre decision to put / on shift-, is really tripping me up!).

Most keys have 3 symbols (normal, shift, Fn), and for the most part I’m getting on with that just fine.

PC have also released an “alpha” version of an app which lets you change the keyboard mapping, so you can make some tweaks to suit your own personal preferences; if you can deal with the keys not doing what their label shows.

Keyboard mapper app

Key Feel: Bad

The keys themselves actually “feel” OK. They’re not too plasticky, there’s a decent depth of travel, and a tactile click.

However, unless you hit them dead centre they won’t depress, and even if you get a tactile click, it’s pretty random whether it registers or not. More on that below.

Also, there’s no ridge or bump on the F or J keys, which would really help a lot with finger positioning.

Now, it’s been 20 years since I last used a Psion 5 for more than 10 seconds, but my memory is that it was significantly nicer to type on than the Astro.

Dropped and phantom key-presses: Ugly

The other things I could probably let Slide 😉, but the biggest, most unforgivable problem with the Astro keyboard is that it doesn’t work.

Phantom presses

The first functional issue I noticed is that when pressing certain key combinations in quick succession, a third unrelated key-press will get registered.

For example, if you type (), which I do fairly often in code (one of my Astro use-cases), you often get an additional “bonus” C. Here’s what I get typing () 10 times:


Great! 👍

This happens for other keys too, and is presumably to do with how the keyboard matrix is scanned. You can see in the driver source code (hey, at least we have source code!) that 0 ()) and 9 (() are on the same physical row pin, and 9 (() and C are on the same column. When scanning the key matrix, this must make it appear that C was pressed, when it wasn’t.

// Key          Matrix Row    Matrix Column
{"0", KEY_0, 0, KROW_P0_6,    KROW_P1_6},
{"9", KEY_9, 0, KROW_P0_6,    KROW_P1_1},
{"C", KEY_C, 0, KROW_P0_3,    KROW_P1_1},

The same problem applies to various other combinations, I’m sure if I checked their pins I’d find the same commonality.

This isn’t so bad, but it is pretty annoying.

Dropped keypresses - unacceptable

The big problem is that keypresses get frequently and unpredictably lost. Even when you get a nice solid hit on the key and a tactile click, a high percentage of the time, nothing registers.

It’s unpredictable, which makes it worse. You can’t just type more slowly or carefully, it doesn’t help. I haven’t managed to successfully type my password into a terminal once, and it’s not even a complex password.

It also seems to have a cool-down lock-up behaviour. If you upset it somehow, it won’t let you type anything until you stop, wait a second or two, and then start again.

Here’s me typing the classic English sentence “naturally” on the Astro, with no correction:

The quick brown fox jumps overthe lazy og
The quick bron fo jump overthe lazy dog
Th quick brown fox jumps ovr the lazy dog
THe quick brown fox jumps overthe lazy dog

And here’s slowly and carefully, index-finger-pecking it:

The quick brown fox jups ov the lazy dog
The quick brown fox jumps over thelazzy dog
The quick bown fo jumps ovrthe lay dog
he quick brown fo jumps ove the lazy dog

It’s awful, and it seems even worse when you start getting the Shift/Ctrl/Fn/Alt modifiers involved. Sometimes you will need to press a key 2, 3, maybe 4 times before it does what it’s meant to.

You can type on it, but be prepared to make very, very frequent corrections, stutters and re-presses.

Can it be fixed?

Can this be fixed in software? Maybe.

We can see from the kernel source code (and some experiments with a rooted phone) that the keyboard matrix is attached to an AW9523 IO expander chip, which itself talks to the processor over i2c.

The driver scans the matrix by sending an i2c transaction to energise a row and then another one to read the columns. This in itself is going to be very slow - there’s two read-modify-write and another read i2c transaction for each row, which seems a bonkers way to build a keyboard.

The code is truly horrible - there’s no way I’d be allowed to ship that at my job - and I haven’t spent enough time to really understand it, but it seems possible that a better driver implementation could help. Unfortunately, the i2c GPIO expander is a pretty hard limitation.

The Esc saga

The last complaint I have about the keyboard is the Esc key.

I’m a vim user, and Esc is a very important key in vim. When using vim in termux, I found that Esc doesn’t work - it just acts like BACK.

I spent some time poking around on my newly-rooted Astro and have learnt the following:

  • The escape key is not handled by the AW9523, unlike all the other keys
  • The slide open/close and “smart” button are handled by the same driver that handles headphone insert/remove detection and inline controls (ACCDET - accessory detect maybe?)
  • The volume buttons, power button and escape key are handled by mtk-kpd
  • I’m 90% sure that the escape key and power button are on the same physical circuit, in parallel, and there’s no way to distinguish them in software!

I have done several experiments that back up the last point:

The keypad driver log messages are exactly the same for both buttons. This is what it says for the power button:

[12516.397107] .(2)[114:irq/233-mt6358-]mt6358-pmic 10026000.pwrap:mt6359-pmic: Reg[0x91c]=0x1,name=pwrkey,hwirq=48,type=4
[12516.561076] .(2)[114:irq/233-mt6358-]mt6358-pmic 10026000.pwrap:mt6359-pmic: Reg[0x91c]=0x4,name=pwrkey_r,hwirq=50,type=4

This is what it says for Esc:

[12509.552480] .(3)[114:irq/233-mt6358-]mt6358-pmic 10026000.pwrap:mt6359-pmic: Reg[0x91c]=0x1,name=pwrkey,hwirq=48,type=4
[12509.664913] .(2)[114:irq/233-mt6358-]mt6358-pmic 10026000.pwrap:mt6359-pmic: Reg[0x91c]=0x4,name=pwrkey_r,hwirq=50,type=4

The two buttons also act identically - for example the power button doesn’t turn screen off when the slide is open unless you hold Fn.

When the slide is “closed” (faked with a magnet), the Esc key acts like a toggle, the same as the power button.

The /dev/input/event3 device, which is the main keyboard, reports no events for Esc, and the AW9523 driver key map doesn’t have an entry for Esc.

Also, the keyboard mapping app doesn’t work for Esc.

This again could be fixed in software by having both power buttons report as Esc when the slide is open, but it’s such an incredibly strange design. Perhaps this was the only way to get screen wake-up from a key on the keyboard.

In the interim, I’ve used the keyboard mapping app to have Alt + Space work as escape, and it’s usable.

Keyboard verdict

It’s pretty bad. BUT, if you need to type lots of symbols and special keys (code, terminal, markdown) it totally beats a touch keyboard.

I’m typing this whole blog post on it, and I wouldn’t say it’s fun… but the words are coming out.

I really hope that some PC or community effort can at least partially address the shortcomings with software.

I’m still using the on-screen keyboard to type my password, but I really can do something like touch typing on this keyboard, which is pretty cool.

The most annoying part of all of this is that it seems so unnecessary. They’ve done a good job on the hard part of the physical aspects of a tiny keyboard, and completely blown it with stupid electronics and software. Why isn’t there a dedicated microcontroller scanning the matrix properly?!

The crowdfunding

As a crowdfunding campaign, there was always the expectation that there would be hiccups and delays. The previous PC project overran by around a year before they started shipping, so I expected about the same.

Here we are, close to 2 years after the original target date, and there are still thousands of backers who haven’t received their devices.

The downgrade

One of the disappointing elements of the campaign was the downgrade of the phone’s processor. Allegedly MediaTek went back on their deal to supply PC with the Dimensity 1000 chip, and would only offer the Dimensity 800 as a replacement.

The D1000 was slated as a flagship-level chip (in 2020), whereas the D800 is decidedly mid-range.

I think the D800 is OK, it seems fast enough and probably provides better battery life than the D1000. One thing people have been upset about is the loss of WiFi 6 which was a headline feature of the original spec sheet.

I guess we’ll never really know what went on in the business discussions, but I don’t think any other device has shipped with the D1000 either, only D1000+ and D1000L.

The delays

The Covid pandemic impacted everything, and that’s understandable. Towards the end of 2021, production samples had been completed and the factory was about to start mass production.

Assembly of the first production run started on Christmas Day, 2021. On January 18 2022, the first devices were due “to be packaged up during the next few days […] and shipped out to our warehouse in Hong Kong also this week”.

What happened next was a whole year of meaningless updates of “shipping soon”, “production continues”, “leaving Hong Kong next week”.

My device got “locked” in March 2022, which allegedly meant my device had been produced, quality checked, and was ready to leave the factory. But then some modem issue was found on the UK EE network, and all the UK devices had to be reflashed.

The communication around the delays was completely lacking, and I still don’t now how my device, built in March 2022 (I think confirmed by the serial number which is ASTRO2203000XXX) took a further 9 months just to ship from China to the UK.

Dual booting

Another headline feature of the Astro (indeed all Planet devices) is the ability to dual-boot Linux and Android, which is very attractive to me and many others who want this kind of device.

In the December 3 2021 update, Planet showed photos of Ubuntu running on the Astro.

Ubunto on Astro

In January 2023 there is still no dual-boot and no Linux support whatsoever from PC for the Astro


The Astro has 2 USB-C ports.

The right one is more fully-featured, I assume it connects to the main USB controller on the SoC. It is used for adb, the bootloader, it supports hubs, and allegedly HDMI.

The left one seems to support charging, and maybe a single USB device.

I’ve been trying to map out the USB hardware set-up from the device-tree, but it’s not immediately clear.

The HDMI support is HDMI, not DisplayPort Alt-mode. This means that display support doesn’t work with basically any commercially-available USB-C dock; and furthermore, you can’t use HDMI and USB at the same time on that port. This makes the Astro pretty useless as a “docked” device.

The HDMI thing is another bizarre design decision. It looks like MediaTek has some deals with Lattice Semiconductor around MHL, and indeed the Astro has a Lattice HDMI transmitter, the Sii9022, so I assume the Astro manufacturer is using MediaTek reference designs, and those use Lattice MHL.

DP Alt-Mode had already won when the Astro was announced. MHL is dead. It’s a real shame PC or their ODM didn’t put in the effort to design in DisplayPort. There’s nothing technical that would prevent it.


Another MTK reference design quirk is charging. The Astro allegedly doesn’t support the ubiquitous USB PD charging standard, instead opting for MediaTek’s proprietary “PumpExpress” standard.

I don’t actually know if they are compatible. When I plug in a PD charger to the right-hand port, I can see log messages showing it’s able to read the charger capabilities, but it always seems to settle for 5V. The left port doesn’t seem to have any USB-C negotiation ability.

[33703.186504] .(6)[367:charger_thread][pd_get_cap] nr:4 idx:0
[33703.187234] .(6)[367:charger_thread][pd_get_cap]:0 mv:[5000,5000] 3000 max:15000000 min:0 type:0 0
[33703.188432] .(6)[367:charger_thread][pd_get_cap]:1 mv:[9000,9000] 3000 max:27000000 min:0 type:0 0
[33703.189583] .(6)[367:charger_thread][pd_get_cap]:2 mv:[15000,15000] 3000 max:45000000 min:0 type:0 0
[33703.190753] .(6)[367:charger_thread][pd_get_cap]:3 mv:[20000,20000] 3000 max:60000000 min:0 type:0 0
[33703.191922] .(6)[367:charger_thread][pdc_init_table] nr:4 default:0
[33703.200159] .(5)[105:pd_dbg_info]///PD dbg info 924d

Everything Else

The rest of the phone is more-or-less as expected. It’s Android 11, with Google apps, and various PC and Chinese bloat/snoop-ware. The community are already hard at work stripping that out.

The camera works, but its not good. This is to be expected given PC’s minimal resources.

Apparently the cellular modem isn’t good, the driver crashes frequently and it drops network. I haven’t put a SIM in mine, so I don’t know.

The screen has huge radius rounded corners, which steals quite a lot of space, which I think will prove a bit annoying in a more “desktop” like environment. They should have gone with a much less rounded display, but were probably limited by what was available off-the-shelf.

All in all, it’s fairly well built, it performs well enough, and the Android port seems OK.

Mine does have some damage on one of the ribbon cables, and a minor scuff on the front, but they don’t impact any functionality.

Ribbon cable damage


At this point I’m still amazed that I actually have the thing. I’ve used it to write this whole blog post, and I’m getting used to its quirks. I just hope that PC put some more effort into patching issues and providing the promised dual-boot support.

Failing that, there’s an active community on Discord and we’ll just have to drive improvements ourselves.

Overall, it’s a cool device, with unique hardware, but plagued by bizarre engineering decisions and lack of effort to really make it shine. I’m still optimistic that over time it could be refined into something much better.