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, 0 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.

wget https://github.com/neutrinolabs/xorgxrdp/releases/download/v0.2.17/xorgxrdp-0.2.17.tar.gz

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
│   │   ├── 40-libcanberra-gtk-module.sh
│   │   ├── 50-systemd-user.sh
│   │   └── 80xapp-gtk3-module.sh
│   └── 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, 2 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:

wget http://ftp.debian.org/debian/dists/Debian10.4/main/installer-arm64/current/images/netboot/debian-installer/arm64/initrd.gz
wget http://ftp.debian.org/debian/dists/Debian10.4/main/installer-arm64/current/images/netboot/debian-installer/arm64/linux

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 https://ci.ubports.com/job/rootfs/job/rootfs-pinephone-systemimage/ 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

Mistakes to Avoid With the PinePhone

As mentioned before by me and many, many others, the PinePhone Brave Heart edition is very much not road ready.  That’s fine, but it does mean you’ll probably find yourself reflashing your device’s image a few times.  What follows are the various mistakes that have led me to re-flash my phone.

Decreasing the Brightness

As soon as you move that slider, your brightness will go to nil. As in no image at all.  If you have SSH enabled, you can probably set that brightness back, but there’s a good chance that you’ll make the move prior to having SSH set up.  Whoopsie.

Applies To

  • Sailfish OS
  • Ubuntu Touch (only if you decrease it fully)
  • PostMarketOS (only if you decrease it fully)

Turning off WiFi

Under Ubuntu Touch, turning off WiFi somehow borks the radio, requiring you to toggle it off and back on.  Not a huge nuisance, but not nothing either.

Applies To

  • Ubuntu Touch

Following that modem.txt document

A lot of folk, myself included, have tried to enable voice calls by following this file.

Don’t. do. it.

The file relies on a custom kernel, and if you set your QDAI settings per this file, you will end up unable to make phone calls until you reset it to factory defaults – which you have to do manually.

Posted by Adam Labay, 1 comment

Ubuntu – The Most Stable PinePhone OS So Far

Of the four operating systems I’ve tried so far on the PinePhone, Ubuntu Touch (aka UBPorts) is the most stable, getting me nearest to actually placing a successful call.


The process starts by downloading the latest image, either from the Pine64 wiki or from the UBPorts Jenkins site. Flash the image onto a microSD card using Balena Etcher or your favorite flashing tool.

First Use

Initial startup works like a charm. You’ll want to attach to WiFi since the SIM won’t initially be read. Once you’re in, hop on the Interwebs and have some fun. Just nothing that requires audio, since that’s the next step.

Enable Mobile Data

Ironically, your fancy new phone won’t be able to use any mobile functions. You need to enable the modem, this time and every time you boot. There’s probably a way to turn the process into a startup script; I’ll report back if so.

At any rate, open the Terminal app and enter these commands (taken from this post):

sudo /usr/share/ofono/scripts/enable-modem
sudo /usr/share/ofono/scripts/online-modem

The sudo password is phablet

Once you’ve entered the first command, the second one is a piece of cake thanks to Ubuntu Touch’s nifty keyboard. Swiping up on the keyboard reveals the cursor, which is moved by swiping around. Nice touch, UBPorts.

Enable Audio

Much like enabling mobile data, you’ll have to do this every time you start the device.

Open the Terminal app and enter the following:

sudo modprobe snd_soc_simple_amplifier
sudo modprobe snd_soc_simple_card_utils
amixer -c 0 set 'AIF1 Slot 0 Digital DAC' unmute
amixer -c 0 set 'Line Out' unmute

Optionally, add the line amixer sset 'Line Out' 100% to max out the volume (best I can tell, you’re setting the volume that 100% on the volume rocker corresponds to; i.e. if you leave this at 55% (the default), the loudest you can make your phone is 55% of its true potential).

Don’t Disable Wifi

If you do, it won’t come back. Rather, it will appear enabled, but no access points will appear and even saved APs won’t connect. To remedy, open Terminal and enter the following:

sudo nmcli radio wifi off
sudo nmcli radio wifi on

What Works

So far, I have successfully

  • Played YouTube videos
  • Surfed the web on mobile data
  • Rebooted the phone a bunch of times

What May Yet Work

It turns out that my cheapo FreedomPop SIM requires some proprietary app to do text and calls, so I can’t test that at present. But if the Reddits and the forums are any indication, I’ll be a lucky son of a gun if I manage to successfully place a call. Texts shouldn’t be a problem.

What Doesn’t Work

Taking a friggin screenshot. Maybe there’s another app required?

Updates to follow.

Posted by Adam Labay, 0 comments