Retaining Multi-Monitor Configs After Sleep

I recently upgraded my dual-monitor setup to include a 32″ primary monitor on DisplayPort and a 24″ secondary on HDMI. Apparently, the LG 32GP750 in primary position takes slightly longer to wake up after sleep mode than the Acer K242HYL in secondary — just long enough, in fact, that Arch’s display manager can’t work out what to do and ends up rejecting the primary monitor entirely. Enter a minute of grudgingly editing display settings and rearranging windows.

After 2 months of this nonsense, I shall put up with it no further.

Fortunately, the solution is comically simple.

Step 1: Install autorandr


sudo apt install autorandr


sudo pacman -S autorandr

Step 2: Save your configuration using the name default, unless you’re being sassy and using multiple configs:

autorandr --save default

Step 3: Prosper

There should be a file called /etc/xdg/autostart/autorandr.desktop that invokes the default configuration (see why we called it that?) upon loading of the login screen; i.e. the first step after waking up. Problem solved.

Step 4: Attribution

I definitely did not figure this out myself, but it did take an inordinate amount of googling. For reference, here’s where I got the deets.

Posted by Adam Labay, 0 comments

Installing Kali Nethunter on the OnePlus (and probably other phones too)

In a fit of boredom (and a desire to up my l33t cred), I decided to install Kali Nethunter on a OnePlus 7 Pro that I stopped using about a year ago. Naturally, the first stop was the official installation instructions. Big mistake. They’re darn near incomprehensible, rely on deprecated software, and cost me about 3 days of struggle.

But, with enough time, cussing, and reflashes, anything is possible, and Nethunter is now working beautifully on the OnePlus 7 Pro. So what follow are the steps I used to pull it off. Hopefully they’ll save you some time and heartache.

Obligatory Warnings

Flashing Nethunter requires the following actions, in increasing order of risk:

  • Rooting your phone. If you don’t know what that means, you are wildly out of your depth. Stop, reconsider your choices, and go have some ice cream instead.
  • Wiping your phone, completely, about a fghjillion times. You will lose all your data.
  • Unlocking your bootloader, which, in addition to wiping your phone, makes it display an annoying security message every time you boot from here on out.
  • Disabling your phone’s encryption. That is, even without knowing your passcode, someone who possesses your phone can view all those nudes you’re probably storing on it.

Further: doing any of the above can brick your phone. Bricking your phone will result in:

  • Turning your expensive-ass phone into a shiny paperweight
  • Voiding any and all warranties
  • Earning you mockery and derision on Reddit when you explain what you did in a desperate plea for help
  • Hours spent in the XDA-Developers forums — where you will encounter less mockery and derision, but the same bleak despair when they explain what you’ve done

Still here? Let’s go.

Step 0: Learn what region your phone is

Most manufacturers have different editions of the phones – with different hardware – for various regions like the USA, Europe, China, and India. Installing the wrong edition won’t fully brick your phone, but it’ll give you a good scare and cost a few hours to fix.

Typically, the regional variant of your OS is appended to the version number. For example, my OxygenOS version (available by going to Settings | About Phone | Build Number) is, where GM21AA is the variant.

If you’re on a OnePlus like me, it gets slightly more complicated, as there is a T-Mobile variant within the USA/Global variant, and you may have to reflash your entire phone’s image before you can proceed at all. I’ll write a follow-up post on how to do that, provided I remember.

Step 1: Update your phone to the latest stock OS

Installing any updates to your operating system will result in re-enabling the encryption that we are working so hard to remove. Ergo, you will not be able to update Android after installing Nethunter unless you want to repeat the entire Nethunter installation rigmarole.

Therefore, do future you a favor and get your phone on the latest version of Android (in my case, Oxygen OS for the USA/Global edition).

Furthermore, you must use the stock version of Android that ships with your device. No custom OSes here.

Step 2: Install ADB and Fastboot

If you don’t know what these are, you should probably bail right now. At any rate, here’s how to get them:

  • Windows/Mac: Download from Google and unzip somewhere. Unless you want to get all fancy with the PATH variable, though, you’ll have to drop any files you intend to upload into this folder. This is the only time I will mention this caveat, so don’t forget it.
  • Ubuntu: sudo apt install android-tools
  • Arch: sudo pacman -S android-tools

Step 3: Enable USB Debugging and other fancy developer tools

Remember that build number from Step 0 (Settings | About Phone | Build Number if you already forgot somehow)? Tap on it 7-8 times to enable Developer Mode. Now, you can go to Settings | System | Developer Options and do the following:

  • Enable USB Debugging
  • (Optionally) enable Advanced Reboot

Step 4: Install Magisk

Magisk is a lovely app that serves multiple functions in our adventure, namely:

  • Rooting your phone
  • Disabling encryption
  • Installing Nethunter

To install:

  1. Go to Magisk’s GitHub page and download the .apk of the latest release. Don’t download Magisk from anywhere other than GitHub! It is known that amateurs are always looking for easier ways to root their phones, and bad actors capitalize on their naivete with malware-laden fakes.
  2. In a terminal (command prompt for your Windows folk), push the file to your phone with
    adb push Magisk-v25.2.apk /sdcard/Download
  3. On your phone, open the File Manager app and install the .apk that now resides in your phone’s Downloads folder. You’ll probably have to enable a bunch of permissions to accomplish this, but at least the menus involved are intuitive.

Step 5: Patch your Boot Image

In order for Magisk to work its rooty magic, it first needs some help by way of a patched boot image. Fortunately, Magisk will do the patching for you; all you have to do is secure that juicy .img file. To do so:

  1. Get a factory image of your OS. Two ways to do this:
    • Go to the vendor’s support site and poke around
    • Google “factory image [OS build]” where [OS build] is the build number from Step 1.
  2. Open the .zip file that you downloaded and extract payload.bin.
  3. Clone the payload_dumper repository (or just download a ZIP of it from GitHub).
  4. Move payload.bin into the payload_dumper folder.
  5. Make sure that you have Python 3 installed with the following (pip) packages:
    • protobuf
    • bsdiff4
  6. Open a terminal in the payload_dumper folder and run
    python3 payload_dumper payload.bin
  7. Once it completes, there will be an output folder containing boot.img. Push it to your phone with
    adb push boot.img /sdcard/Download

Now you can patch that boot image in Magisk. To do so:

  1. Open Magisk.
  2. In the Magisk section (i.e. not the App section), click Install.
  3. Choose Select and Patch a File as your method.
  4. Navigate to boot.img from earlier.
  5. Let Magisk do its thing. When it finishes, the last line will give the name of the output file, along the lines of
    magisk_patched_[string of stuff].img.
  6. Retrieve that patched file with
    adb pull /sdcard/Download/magisk_patched_[string of stuff].img .

Step 6: Unlock the bootloader

Reboot into the bootloader. Two ways to do this:

  • adb reboot bootloader
  • Long-press the Power button and select bootloader, which should be available if you enabled Advanced Reboot in Step 3.

Once in the bootloader, unlock it with
fastboot oem unlock

Accept that this will wipe your phone and let it proceed.

Step 7: Repeat Steps 3-4

Remember when I said you’re going to wipe your phone a fghjillion times? Yeah, you’re gonna repeat Steps 3-4 a healthy number of times as well.

Step 8: Patch your boot image

Reboot into the bootloader, same as you did in Step 6. Then, flash the boot image that Magisk produced with
fastboot flash boot magisk_patched_[string of stuff].img

Once it’s flashed, boot the phone. Your phone is now rooted!

Step 9: Disable encryption

This is where the stock Nethunter installation instructions make their first mistake. They advocate using Disable_Dm-Verity_ForceEncrypt, which is deprecated and will soft-brick your phone.

Instead, you need Disable Force Encryption NEO (hereafter DFE-Neo). You can learn all about it on the XDA-Developers forum, or you can just download it from SourceForge.

You can download the file directly to your phone, or download it to your computer and adb push it to your phone. Either way, the next steps are:

  1. Open Magisk. It may request a reboot to complete installation; let it.
  2. Tap Modules in the bottom-right.
  3. Select Install from Storage and select the DFE-NEO zip you downloaded.
  4. Use Volume Up to cycle through the languages and use Volume Down to select the language of choice.
  5. Hit Volume Down again to continue.
  6. Hit Volume Up to select the Use arguments.txt option, and Volume Down to select.
  7. Let it run its course. When you get to the end, though, don’t hit the blue Reboot nugget. Instead, reboot into the bootloader using your preferred method from Step 6.

Step 10: Wipe the Data partition

Time to enter Recovery mode. For this, you will want the latest version of TWRP Recovery. Go to, find your device, and download the most-recent .img file.

Don’t install TWRP as it will overwrite your boot partition that you worked so hard to flash. Instead, we’re just going to boot into TWRP as a one-off. To do so, use
fastboot boot twrp-[version]-[model].img

Once TWRP Recovery has loaded, select Wipe and Wipe Data. Once that’s done, reboot.

Step 11: Repeat Steps 3-4

Another wipe of the phone, another reinstallation of Magisk.

Step 12: Install Nethunter

Friggin finally. Obtain the latest Nethunter image from, either by downloading directly to the phone or pushing via adb.

Open Magisk, and install the Nethunter image the same way you installed DFE-NEO in Step 9.

Step 13: Celebrate!

You did it! l33t points will be added to your account in due course.

Posted by Adam Labay, 10 comments

XRDP on Manjaro (The Easy Way… When It Works)

I have a much lengthier post on getting XRDP to work on Manjaro, which happens to be one of the top Google results for getting the whole apparatus to work.

And to that end, I want to provide a quick and easy way of getting XRDP to work on Manjaro for folks who aren’t interested in prologue and might be afraid to edit weirdly-named files on their own.

Caveat Emptor

The easy way doesn’t always work. Reasons include:

  • The xrdp and xorgxrdp(+/- git) packages need to be in perfect alignment. If one is updated while the other is not, sadness will result.
  • The xrdp and xorgxrdp(+/- git) packages need to both be properly signed, which has been an on-and-off issue for the past couple years.
  • If you’re running a desktop environment that’s not XFCE, then you’ll have to make some modifications. Fortunately, if you’re here, you’re probably running the default Manjaro desktop environment, which happens to be XFCE.

Should the easy way fail, you may want to visit my original post on doing it the hard way.

The Steps

Assuming you can ssh into your machine, the commands are as follows:

sudo pacman -Sy base-devel xorg-server-devel yay
yay -S xrdp xorgxrdp-git
echo "allowed_users = anybody" | sudo tee -a /etc/X11/Xwrapper.config
sed -i '12s/xfce-session/xfce4-session/g' ~/.xinitrc
sed -i '42s/ --exit-with-session//g' ~/.xinitrc
sed -i '66s/\$1/\$SESSION/g' ~/.xinitrc
sudo systemctl enable xrdp
sudo systemctl start xrdp

What They Do

  • The first line installs the packages you’ll need to build and install xrdp and its friends.
  • The second line installs xrdp and xorgxrdp-git, which are sort of the point of this exercise
  • The third line permits you to enter an X (desktop) session without being at the computer – sorta important if your goal is to remote in.
  • Lines 4-6 correct some typographical issues that prevent xrdp from running normally.
  • Lines 7-8 enable and start the xrdp service.

Good Luck!

Let me know if any of this ceases to function and I’ll do my best.

Posted by Adam Labay, 3 comments

XRDP on Manjaro (fixing the blank screen issue)

Updated 22 November, 2021

Recently, I repurposed an old desktop machine to be a headless server for running machine learning and ArchiveTeam stuff. In its former life it ran Manjaro alongside Windows 10, so I figured I might as well stick with Manjaro in its new role.

Of course, since it would be running headless, I needed to install a remote desktop solution. xrdp has worked a treat in the past on my various other Debian-based systems, so what the heck.

Unfortunately, a quick Google search will confirm that running xrdp on Manjaro is anything but straightforward. The issues are twofold:

  1. A required package has a borked GPG signature, so you have to build it yourself.
  2. Even once you have all the dependencies installed, you’re greeted by a blank screen.

Fortunately, the solution is relatively straightforward. So without any further prologue, let’s go.

Note: XFCE

I’m assuming that your desktop environment is XFCE, since that’s the default Manjaro environment. If you’re using KDE or Gnome, I’m guessing the same steps apply. But don’t take my word for it.

Step 1: SSH into your machine

Since this is a headless machine, I’m doing everything via SSH. That said, other than Step 2, everything will be via the terminal anyway.

Step 2: Install some dependencies

Specifically, we’re going to install:

  • yay – which enables the installation of AUR packages. xrdp doesn’t live in the regular pacman universe, so we need yay.
  • base-devel – which enables the building of said AUR packages
  • xorg-xserver-devel – which provides necessary dependencies for xrdp.
  • xorg-server-dev – successor xorg-server-devel. Provides necessary dependencies for xrdp.
sudo pacman -Sy yay base-devel xorg-xserver-devel

Step 3: Install xrdp

Now we can install xrdp using yay.

yay -S xrdp

Agree to install all dependencies, blah blah, and you’re good.

Step 4: Download and install xorgxrdp

Normally, we’d install xorgxrdp through yay, same as xrdp. Unfortunately, the GPG keys are scuzzed up, so we have to do this the hard way: by building it ourselves.

Fortunately, this isn’t hard at all.

Step 4a: Download xorgxrdp

As of this writing, the latest release is 0.2.17. Find the current link on the AUR page under Sources and proceed accordingly.


Step 4b: Extract the files and enter the directory

tar xvf xorgxrdp-0.2.17.tar.gz
cd xorgxrdp-0.2.17

Step 4c: Configure, make, and install

sudo make install

Step 5: Create (or edit) your Xwrapper.config file

My understanding of this step is sketchy, but it goes like this: by default, X11 won’t open a session unless you’re at the display. This is understandably an issue if you’re remote.

So we either edit /etc/X11/Xwrapper.config (if it exists) or create a fresh copy (most likely the case), containing the ending (or only) line:

allowed_users = anybody

Step 6: Edit ~/.xinitrc

This is the file that is causing your blank screen woes, and likely why you’re reading this post in the first place. The stock version has a couple of typos that result in the window manager never actually being invoked. In particular, we need to make 3 edits:

  1. Change SESSION=${1:-xfce-session} to read SESSION=${1:-xfce4-session}
  2. Change local dbus_args=(–sh-syntax –exit-with-session) to read local dbus_args=(–sh-syntax)
  3. Change exec $(get_session “$1”) to read exec $(get_session “$SESSION”)

The resultant file should look like

# ~/.xinitrc
# Executed by startx (run your window manager from here)



# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
    for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
        [ -x "$f" ] && . "$f"
    unset f

        #local dbus_args=(--sh-syntax --exit-with-session)
        local dbus_args=(--sh-syntax)
        case "$1" in
                awesome) dbus_args+=(awesome) ;;
                bspwm) dbus_args+=(bspwm-session) ;;
                budgie) dbus_args+=(budgie-desktop) ;;
                cinnamon) dbus_args+=(cinnamon-session) ;;
                deepin) dbus_args+=(startdde) ;;
                enlightenment) dbus_args+=(enlightenment_start) ;;
                fluxbox) dbus_args+=(startfluxbox) ;;
                gnome) dbus_args+=(gnome-session) ;;
                i3|i3wm) dbus_args+=(i3 --shmlog-size 0) ;;
                jwm) dbus_args+=(jwm) ;;
                kde) dbus_args+=(startplasma-x11) ;;
                lxde) dbus_args+=(startlxde) ;;
                lxqt) dbus_args+=(lxqt-session) ;;
                mate) dbus_args+=(mate-session) ;;
                xfce) dbus_args+=(xfce4-session) ;;
                openbox) dbus_args+=(openbox-session) ;;
                *) dbus_args+=("$1") ;;

        echo "dbus-launch ${dbus_args[*]}"

exec $(get_session "$SESSION")

Step 8: Enable and Start xrdp

sudo systemctl enable xrdp
sudo systemctl start xrdp

Step 8.1: Bypass nVidia Drivers

If you’re running nVidia drivers, there’s one more step, which I discovered courtesy of this delightful post.

In short, the nVidia drivers will cause the blank screen to resurface. We want to keep the drivers for use by applications, but deny their use by xrdp. Here’s how:

  1. Make the directory /etc/X11/nvidia.d
  2. Move the files 90-mhwd.conf and [stuff].nvidia-drm-outputclass.conf to said directory where [stuff] depends on your specific installation. For me the file was 10-amdgpu-nvidia-drm-outputclass.conf but your mileage (and CPU) will vary.
sudo mkdir /etc/X11/nvidia.d
sudo mv /etc/X11/xorg.conf.d/90-mhwd.conf /etc/X11/nvidia.d
sudo mv /etc/X11/xorg.conf.d/10-amdgpu-nvidia-drm-outputclass.conf /etc/X11/nvidia.d

Your /etc/X11 directory should look something like

├── mhwd.d
│   ├── nvidia.conf
│   └── nvidia.conf.nvidia-xconfig-original
├── nvidia.d
│   ├── 10-amdgpu-nvidia-drm-outputclass.conf
│   └── 90-mhwd.conf -> /etc/X11/mhwd.d/nvidia.conf
├── tigervnc
│   └── Xsession
├── xinit
│   ├── xinitrc
│   ├── xinitrc.d
│   │   ├──
│   │   ├──
│   │   └──
│   └── xserverrc
├── xorg.conf.d
│   └── 00-keyboard.conf
├── xrdp
│   └── xorg.conf
└── Xwrapper.config

Step 9: Prosper

Hop on in, and be greeted by the XFCE environment.

Let me know if you still have any issues, though the chances of my being able to solve them are miniscule. Godspeed!

Posted by Adam Labay, 5 comments

Update: Consistently Successful Calls on PinePhone with UBPorts

This’ll be a short one.

A short while ago I posted about my first successful outgoing calls on the PinePhone, and stated that they weren’t terribly consistent and that they had no voice:

I can get the PinePhone to ring other phones – which is still a new accomplishment – but no voice comes through. Alas.

If you’re like me, you’ll now have a 1:5 (up from 0:5) chance of being able to successfully dial out.

That has changed, due both to a software update and a trick.

Stick to the Dev Channel

I can’t speak for the Stable channel, but at least with Dev Version 61 outgoing calls have crystal-clear voice 100% of the time.

Lose the Extra G

Browsing the UBPorts Forums, folks indicated that UBPorts doesn’t have a good time with VoLTE (Voice over LTE), and thus can’t pull off 4G calls at all. Normally, the phone should be able to recognize this fact and switch automatically to 3G, and I’m guessing that’s what my phone did the 1 in 5 times that it successfully placed a call.

To up that ratio to 1:1, go to Settings | Network | Cellular Settings and select 2G/3G as the Connection Type.

Thereafter, calls should always connect.

Posted by Adam Labay, 0 comments

Creating an ARM64 Debian Image

As part of another project, I need to be able to build software for the PinePhone, and that means I need an ARM64 environment with as much oomph as possible (trying to compile stuff on the PinePhone = bad idea).

The solution is to run a Debian VM that, in turn, runs a Qemu ARM64 emulator with a Debian image.

Nearly every step that follows is taken verbatim from this guide by Blahcat, so all credit goes there.  The only reason I made my own post is because I had to change a couple lines in order to get the network working. Hopefully this brings you joy.

Get that VM going

I’m a VirtualBox guy, but you do you. You’ll also want the latest Debian ISO, which at the time of writing is Buster. I gave mine 4 cores, 4GB of RAM, and 20GB of storage.

Install Qemu

Terminal. sudo apt install qemu. Nuff said.

Download the Debian Bits

You need the initrd and kernel of the Debian installer. Blahcat’s links are outdated, so here’s the latest:


Make a disk. To hold stuff.

Blahcat recommends 20G, but that’s the size of my Debian VM. I haven’t managed to fill up 12G yet — but, as said before, you do you.

qemu-img create -f qcow2 disk.qcow2 12G

Invoke the Installer

This is where I depart the most from Blahcat. Every time I followed their instructions, the resulting image was unable to connect to the internet, even though it ran a blasted net installer. The solution, in my case, was to force the emulation of an ethernet adapter (in addition to the one that Qemu automatically creates). Some of the command that follows is likely malformed, redundant, or both, but by golly it worked.

qemu-system-aarch64 -smp 2 -M virt -cpu cortex-a57 -m 1G \
    -initrd initrd.gz \
    -kernel linux -append "root=/dev/ram console=ttyAMA0" \
    -global virtio-blk-device.scsi=off \
    -device virtio-scsi-device,id=scsi \
    -drive file=disk.qcow2,id=rootimg,cache=unsafe,if=none \
    -device scsi-hd,drive=rootimg \
    -device e1000,netdev=net0 \
    -net nic \
    -netdev user,hostfwd=tcp:,id=net0 \

During installation you’ll be asked to pick an Ethernet adapter; pick the Intel one and life is good.

Extract your fancy new kernel

Let it be known that I have no idea how half this stuff works, nor what nbd stands for. Essentially, you mount your new image, extract the kernel and initrd, and use them the next time you invoke the image.

sudo apt install nbd-client
sudo modprobe nbd max_part=8
sudo qemu-nbd --connect=/dev/nbd0 disk.qcow2
mkdir mnt
sudo mount /dev/nbd0p1 mnt
cp mnt/initrd.img-4.19.0-9-arm64 mnt/vmlinuz-4.19.0-9-arm64 .
sudo umount /dev/nbd0p1
sudo nbd-client -d /dev/nbd0


You should now be able to run your new, emulated system – and have internet access too!

qemu-system-aarch64 -smp 2 -M virt -cpu cortex-a57 -m 1G \
    -initrd initrd.img-4.19.0-9-arm64 \
    -kernel vmlinuz-4.19.0-9-arm64 \
    -append "root=/dev/sda2 console=ttyAMA0" \
    -global virtio-blk-device.scsi=off \
    -device virtio-scsi-device,id=scsi \
    -drive file=disk.qcow2,id=rootimg,cache=unsafe,if=none \
    -device scsi-hd,drive=rootimg \
    -device e1000,netdev=net0 \
    -net nic \
    -netdev user,hostfwd=tcp:,id=net0 \

Posted by Adam Labay, 0 comments

Extending onto a USB Monitor with Manjaro

Normally, my ASUS MB169B USB Monitor lives in my briefcase, to be used when I need two screens at a coffee shop or a client. But, given the new work-from-home reality, it’s found a new life as a dedicated spot for tiles showing email, calendar, and Slack…

…at least it does when I’m running Windows. When running Manjaro, the USB monitor has sat idle, unused, and sad.

That’s not to say that Manjaro doesn’t support the use of DisplayLink to attach USB monitors — it’s just that, like all things Arch Linux, you have to work for it; doubly so if you’re running an nVidia card.

So, here’s how I got mine working.

1. Install DisplayLink and EVDI drivers.

Do you need both? Beats me, but this is what I have and it works. Purists will do this via pacman but I’m lazy and used the GUI.

2. Install the nVidia drivers, even though they’re not very good.

This turned out to be the key step. Normally, I use modesetting as my graphics driver, mainly because it doesn’t suck. With the nVidia drivers, I get some annoying mouse flickering that I haven’t yet been able to address.

However, the USB monitor also uses modesetting, and with both on the same driver, xrandr returns the following when you try to link them up:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  21 (RRSetCrtcConfig)
  Value in failed request:  0x0
  Serial number of failed request:  22
  Current serial number in output stream:  22

What does it mean? No idea.

How do we fix it? Bust out those crap-ass proprietary drivers.

Enter Manjaro Settings Manger, choose Hardware Configuration, and attain the following setup (the video-linux drivers may be optional, but they’re doing no harm so whatev):

3. Enable and configure the DisplayLink service

Per the instructions in the Arch Wiki, enable DisplayLink by typing in the terminal
sudo systemctl enable displaylink.service

Then, create a file at
with the contents

Section "OutputClass"
	Identifier "DisplayLink"
	MatchDriver "evdi"
	Driver "modesetting"
	Option  "AccelMethod" "none"

Note: It’s entirely possible that this step is obviated by use of the nVidia drivers, but I’m not taking chances.

4. Reboot

Just to make sure.

5. List the displays in xrandr

In the terminal, enter
xrandr --listproviders

With luck, you should see both displays, with their respective drivers:

Providers: number : 2
Provider 0: id: 0x1b8 cap: 0x1, Source Output crtcs: 4 outputs: 7 associated providers: 1 name:NVIDIA-0
Provider 1: id: 0x238 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

6. Connect the displays in xrandr

In the terminal, enter
xrandr --setprovideroutputsource 1 0

If you’re lucky, this will mirror your displays. Of course, that’s probably not what you want, so let’s get them extended.

7. Configure Manjaro to extend your displays

Open Display Settings and declare your primary monitor as such (I’ve found that the USB monitor tends to be marked as primary, initially).

Uncheck Mirror Displays for obvious reasons.

Choose a resolution for your USB monitor that makes sense (probably not the same as your big-ass desktop monitor).

8. Have a lovely beverage

Celebrate your success. Or let me know if it failed. I probably can’t help, but hey who knows.

Posted by Adam Labay, 2 comments

(Nearly) Successful Voice Calls on PinePhone with UBPorts

Update (3 July): Calls now work 100% of the time.

So, this tweet turned out to be a teensy bit premature:

I can get the PinePhone to ring other phones – which is still a new accomplishment – but no voice comes through. Alas.

But, since this remains a new development, here’s how it came about:

1. Flash the latest available Pinephone System Image

Go to and download the latest image. (NB: this is a new URL. Any builds from the old site won’t work since they lack the code to self-update.)

Use BalenaEtcher (or dd if you’re grizzled) to flash the image to your SD card.

2. Switch to the Dev channel

This is where it gets new. Gone are the days of flashing each day’s image and losing your stuff. Now, UBPorts can auto-update (w00t).

Navigate to Settings | Updates | Update Settings (the last being cleverly hidden at the bottom of the screen) and change your channel to Development.

Give the phone some time to think, and it should load the latest Ubuntu image (at the time of writing, the latest is version 54).

Nota Bene: These version numbers are not updated daily, and as such have no correspondence to the build numbers on the CI page.

3. Reboot and Update

Once the update has been downloaded you will need to reboot so that it can load. When you reboot, make sure that you’re still on the dev channel since sometimes it reverts.

4. Place a call (prayer never hurt)

If you’re like me, you’ll now have a 1:5 (up from 0:5) chance of being able to successfully dial out.

(The title to this post said “nearly” for a reason.)

5. Stay Tuned

At this rate an actual, working voice call can’t be far off, right?

Posted by Adam Labay, 0 comments

Successful Phone Calls on the PinePhone

I’m hardly the first to get this to work, but it’s still been a long time coming so I’m celebrating, dammit.

So far, the only configuration that I’ve used that can pull off both incoming and outgoing calls is PostmarketOS.  The steps – what relatively few there are – follow.

Install per the wiki

My preferred interface is Phosh, and I prefer to include the firefox and midori packages since the built-in browser never connects, no matter how many hints I follow.

Even though most work on the device is via ssh, it can also be helpful to install xterm.

I’ve also started including the postmarketos-anbox and android-tools packages in an attempt to get Android apps running, but that’s another story entirely.

Configure sound

Once the phone is up and running, the only additional step needed is to enter Sound configuration and set both configurations to Place a Phone Call.  This accomplishes all the mappings that we were previously trying to pull off using pactl.

‘Tis Better to Receive than to Give

I don’t know why, but for some reason I can’t place calls until I’ve received one first.  So make sure that your first test is a call to your PinePhone.

Celebrate your cleverness

Receive a call. Place a call.  Revel in the new ability to say “hello” from your left hand and hear it with your right hand.

Posted by Adam Labay, 0 comments

Taking Screenshots on the PinePhone… sort of

We all know that, when playing around with a new device, the most important thing you can do is record the experience so that others can behold your techno-wizard glory.  Pics or it didn’t happen, no?  Which makes it that much more frustrating that the PinePhone currently can’t take screenshots in seemingly any of the OSes that are compiled for it.

Attempt 1: The Built-In Option

I’ve been using Ubuntu Touch, since at the moment it has the most features and the least suck of the available OSes.  (Technically the build is from UBPorts, but I’m going to use the terms interchangeably because I’m lazy.)  Allegedly, UBPorts lets you take a screenshot by simultaneously pressing Volume Up and Volume Down, but that doesn’t work on the PinePhone – best I can gather, that only works on Android ports of Ubuntu Touch.

Attempt 2: The Command Line Option

Other posts suggest that you can use phablet-screenshot from the phablet tools package, but that too leads to disappointment, with the program freezing.  Running debug mode (-d) shows that it’s trying to pull the screenshot from adb:

+ adb start-server
+ check_devices
+ set +e
+ adb wait-for-device

Since the PinePhone isn’t running Android, adb isn’t really a thing, and you’ll end up waiting forever.

Attempt 3: The Raw Option

Looks like we’re going to have to create this from scratch.  All of the above-mentioned techniques essentially do the same thing: they dump the framebuffer /dev/fb0 to a file and then convert that file to PNG, JPEG, or whatnot.  How hard can that possibly be?

Dump the Framebuffer

The first step is easy enough: cat /dev/fb0 > img.raw.  This dumps the framebuffer (i.e. what’s on screen) to a raw file.

Figure Out Your Screen Size

The raw image file is just that: a raw stream of pixels, with no dimensions built in.  As such, you next need to figure out how big your screen is.  For the PinePhone, this is 720×1440 pixels.  If you want to discover this yourself, you can just type fbset (sudo apt install fbset if necessary).

Get the Script

This helpful chap cooked up a lovely little Perl script that will then convert the raw image to png.  Download the script, chmod + xto mark as executable, and invoke with ./iraw2png 1440 720 img.raw img.png.

NB: I swapped the dimensions.  You’ll see why.

Inspect the Results

Here’s the result, which doesn’t exactly look like the Desktop:


It definitely captured a thing.


It captured some manner of console, perhaps the TTY output? I don’t know. Evidently there are other framebuffers to be found. If you know how to find them, please do send a comment since I’m up a creek on this one.

Posted by Adam Labay, 5 comments