Dealing with KDE "plasmashell" freezing

I've been using KDE for over a decade now, and something that started happening in the past year or two (at least on Kubuntu 22.04) would be that my whole screen would mostly freeze.  Generally, I'd be able to alt-tab between windows, interact with them, etc., but I couldn't click on or interact with anything related to the window manager (the title bars, the task bar, etc.).

In my case, I'd immediately notice when I came back to my desk and there was obviously a notification at some point, but the rendering got all screwed up:

In this image, you can see that the notification toast window has no visible content and instead looks like the KDE background image.  Also, the time is locked at 5:29 PM, which is when this problem happened (I didn't get back to my desk until 8:30 AM the next morning).

The general fix for this is to use a shell (if you have one open, great; if not, press ctrl+alt+F2 to jump to the console) and kill "plasmashell":

killall plasmashell

Once that's done, your window manager should be less broken, but it won't have the taskbar, etc.  From there, you can press alt+F2 to open the "run" window, and type in:

plasmashell --replace

You can also run this from a terminal somewhere, but you need to make sure that your "DISPLAY" environment variable is set up correctly, etc.  I find it easier to do it it from the run window (and I don't have to worry about redirecting its output anywhere, since "plasmashell" does generate some logging noise).

Sharing a single screen in Slack for Linux

I have a bunch of monitors, and for whatever reason, Slack for Linux refuses to let me limit my screen sharing to a single monitor or application.  This means that if I try to share my screen on a call, no one can see or read anything because they just see a giant, wide view of three monitors' worth of pixels crammed into their Slack window (typically only one monitor wide).

In my experience, disabling monitors/displays is just not worth it; I'll have to spend too much time getting everything set back up correctly afterward, and that's really inconvenient and annoying.

The solution that I've landed on is Xephyr; Xephyr runs a second X11 server inside a new window, so when I need to get on a call where I'll have to share my screen, I simply:

1. Launch a new Xephyr display.
2. Close Slack.
3. Open Slack on the Xephyr display.
4. Open whatever else I'll need to share in the Xephyr display, typically a web browser or a terminal.
5. Get on the Slack call and share my "screen".

Some small details:

• You'll need to open Xephyr with the resolution that you want; given window decorations and such, you may need to play around with this a bit.  Once you find out what works, put it in a script.
• In order to resize windows in Xephyr, it'll need to be running a window manager.  I struggled to get any "startx"-related things working, but I found that "twm" worked well enough for my purposes.
• Some applications, such as Chrome, won't open on two displays at the same time.  I just open a different browser in my Xephyr display (for example, I use "google-chrome" normally and "chromium-browser" in Xephyr), but you can also run Chrome using a different profile directory and it'll run in the other display.

Install Xephyr and TWM:

sudo apt install xserver-xephyr twm

Run Zephyr, Slack, and Chromium:

# Launch Xephyr and create display ":1".
Xephyr -ac -noreset -screen 1920x1000 :1 &
# Start a window manager in Xephyr.
DISPLAY=:1 twm &>/dev/null &
# Open Slack in Xephyr.
DISPLAY=:1 slack &>/dev/null &
# Open Chromium in Xephyr.
DISPLAY=:1 chromium-browser &>/dev/null &

It's kind of dirty, but it works extremely well, and I don't have to worry about messing with my monitor setup when I need to give a presentation.

Edit: an earlier version of this post used "Xephyr -bc -ac -noreset -screen 1920x1000 :1 &" for the Xephyr command; I can't get this to work with "-bc" anymore; I must have copied the wrong command when I published the post.

Encrypt your /home directory using LUKS and a spare disk

Every year or two, I rotate a drive out of my NAS.  My most recent rotation yielded me with a spare 1TB SSD.  My main machine only had a 250GB SSD, so I figured that I'd just replace my /home directory with a mountpoint on that new disk, giving my lots of space for video editing and such, since I no longer had the room to deal with my GoPro footage.

My general thought process was as follows:

1. I don't want to mess too much with my system.
2. I don't want to clone my whole system onto the new drive.
3. I want to encrypt my personal data.
4. I don't really care about encrypting the entire OS.

I had originally looked into some other encryption options, such as encrypting each user's home directory separately, but even in the year 2019 there seemed to be too much drama dealing with that (anytime that I need to make a PAM change, it's a bad day).  Using LUKS, the disk (well, partition) is encrypted, so everything kind of comes for free after that.

If you register the partition in /etc/crypttab, your machine will prompt you for the decryption key when it boots (at least Kubuntu 18.04 does).

One other thing: dealing with encrypted data may be slow if your processor doesn't support AES encryption.  Do a quick check and make sure that "aes" is listed under "Flags":

lscpu;

If "aes" is there, then you're good to go.  If not, then maybe run some tests to see how much CPU overhead disk operations use on LUKS (you can follow this guide, but stop before "Home setup, phase 2", and see if your overhead is acceptable).

The plan

1. Luks Setup
1. Format the new disk with a single partition.
2. Set up LUKS on that partition.
3. Back up the LUKS header data.
2. Home setup, phase 1
1. Copy everything in /home to the new partition.
2. Update /etc/crypttab.
3. Update /etc/fstab using a test directory.
4. Reboot.
5. Test.
3. Home setup, phase 2
1. Update /etc/fstab using the /home directory.
2. Reboot.
3. Test.

LUKS setup

Wipe the new disk and make a single partition.  For the remainder of this post, I'll be assuming that the partition is /dev/sdx1.

Install "cryptsetup".

sudo apt install cryptsetup; 

Set up LUKS on the partition.  You'll need to give it a passphrase.  I recommend something that's easy to type, like a series of four random words, but you do you).  You'll have to type this passphrase every time that you boot your machine up.

sudo cryptsetup --verify-passphrase luksFormat /dev/sdx1;

Once that's done, you can give it some more (up to 8) passphrases.  This may be helpful if you want to have other people access the disk, or if you just want to have some backups, just in case.  If there are multiple passphrases, any one of them will work fine; you don't need to have multiple on hand.

sudo cryptsetup --verify-passphrase luksAddKey /dev/sdx1;

The next step is to "open" the partition.  The last argument ("encrypted-home") is the name to use for the partition that will appear under "/dev/mapper".

sudo cryptsetup luksOpen /dev/sdx1 encrypted-home;

At this point, everything is set up and ready ready.  Confirm that with the "status" command.

sudo cryptsetup status encrypted-home;

Back up the LUKS header data.  If this information gets corrupted on the disk, then there is no way to recover your data.  Note that if you recover data using the header backup, then the passphrases will be the ones in the header backup, not whatever was on the disk at the time of the recovery.

sudo cryptsetup luksHeaderBackup /dev/sdx1 --header-backup-file /root/luks.encrypted-home.header;

I put mine in the /root folder (which will not be on the encrypted home partition), and I also backed it up to Google Drive.  Remember, if you add, change, or delete passphrases, you'll want to do make another backup (otherwise, those changes won't be present during a restoration operation).

If you're really hardcore, fill up the partition with random data so that no part of it looks special.  Remember, the whole point of encryption is to make it so that whatever you wrote just ends up looking random, so writing a bunch of zeros with "dd" will do the trick:

sudo dd if=/dev/zero of=/dev/mapper/encrypted-home;

Before you can do anything with it, you'll need to format the partition.  I used EXT4 because everything else on this machine is EXT4.

sudo mkfs.ext4 /dev/mapper/encrypted-home;

Home setup, phase 1

Once the LUKS partition is all set up, the next set of steps is just a careful copy operation, tweaking a couple /etc files, and verifying that everything worked.

The safest thing to do would be to switch to a live CD here so that you're guaranteed to not be messing with your /home directory, but I just logged out of my window manager and did the next set of steps in the ctrl+alt+f2 terminal.  Again, you do you.

Mount the encrypted home directory somewhere where we can access it.

sudo mkdir /mnt/encrypted-home; 

sudo mount /dev/mapper-encrypted-home /mnt/encrypted-home;

Copy over everything in /home.  This could take a while.

sudo cp -a /home/. /mnt/encrypted-home/;

Make sure that /mnt/encrypted-home contains the home folders of your users.

Set up /etc/crypttab.  The format is:

${/dev/mapper name} UUID="${disk uuid}" none luks

In our case, the /dev/mapper name is going to be "encrypted-home".  To find the UUID, run:

sudo blkid /dev/sdx1;

So, in my particular case, /etc/crypttab looks like:

encrypted-home UUID="5e01cb97-ceed-40da-aec4-5f75b025ed4a" none luks

Finally, tell /etc/fstab to mount the partition to our /mnt/encrypted-home directory.  We don't want to clobber /home until we know that everything works.

Update /etc/fstab and add:

/dev/mapper/encrypted-home /mnt/encrypted-home ext4 defaults 0 0

Reboot your machine.

When it comes back up, it should ask you for the passphrase for the encrypted-home partition.  Give it one of the passphrases that you set up.

Log in and check /mnt/encrypted-home.  As long as everything's in there that's supposed to be in there (that is, all of your /home data), then phase 1 is complete.

Home setup, phase 2

Now that we know everything works, the next step is to clean up your actual /home directory and then tell /etc/fstab to mount /dev/mapper/encrypted-home at /home.

I didn't want to completely purge my /home directory; instead, I deleted everything large and/or personal in there (leaving my bash profile, some app settings, etc.).  This way, if my new disk failed or if I wanted to use my computer without it for some reason, then I'd at least have normal, functioning user accounts.  Again, you do you.  I've screwed up enough stuff in my time to like to have somewhat nice failback scenarios ready to go.

Update /etc/fstab and change /dev/mapper/encrypted-home line to mount to /home.

/dev/mapper/encrypted-home /home ext4 defaults 0 0

Reboot.

When it comes back up, it should ask you for the passphrase for the encrypted-home partition.  Give it one of the passphrases that you set up.

Log in.  You should now be using an encrypted home directory.  Yay.

To confirm, check your mountpoints:

mount | grep /home

You should see something like:

/dev/mapper/encrypted-home on /home type ext4 (rw,relatime,data=ordered)

Now that everything's working, you can get rid of "/mnt/encrypted-home"; we're not using it anymore.

sudo rmdir /mnt/encrypted-home;

Fix for when Chrome stops making screen updates

My desktop environment is KDE, and I use Chrome for my browser.  At any given time, I'll have 2-5 windows with 10-40 tabs each.  However, every once in a while (usually once every week or so), the rendering of Chrome will freeze.  That is, the entire window will remain frozen (visually), but clicks and everything else go through fine (you just can't see the results).  Changing my window focus (switching to a different window, opening the "K" menu, etc.) usually causes a single render, but that doesn't help with actually interacting with a (visually) frozen Chrome window.

Closing Chrome and opening it back up works, but that's really inconvenient.

I'm still not sure why this happens, but I do have a quick (and convenient) fix: change your compositor (and then change it back).  Why does this work?  I'm not sure, but since it's obviously a rendering problem, making a rendering change makes sense.

Step by step:

1. Open "System Settings".
2. Open "Display and Monitor".
3. Go to "Compositor".
4. Change "Rendering backend" from whatever it is to something else (usually "OpenGL 3.1" to "OpenGL 2.0" or vice versa).
5. Click "Apply".

This always solves the problem for me.  You can even switch it back to the original value after you hit "Apply" the first time.

Chrome/Chromium, Roboto, and the horrible text nightmare

I began doing Android development a year or so ago, and the first thing that I noticed was that the official Google Android documentation looked absolutely horrible in Chromium (and Chrome too).  I tried updating fonts, disabling fonts, and installing new fonts, and none of that helped.  On other people's computers, the text looked fine.  In Firefox on my own computer, the text looked fine  On my computer, in Chromium: total crap.

One of the directions that I researched was around the Roboto font (which apparently was released with Android Ice Cream Sandwich).  However, it turns out that the font itself has nothing to do with the problem.

Today, I finally figured it out (and fixed it!), and my Internet (and Android development) experience has been much, much better.

First, let me tell you that I've been running Kubuntu (the KDE Ubuntu variety) this whole time.  So, this covers Kubuntu 11.10, Kubuntu 12.04, Kubuntu 12.10, Kubuntu 13.04, Kubuntu and 13.10.  I had the problem with all of them.

Here's what it looks like:

To make a very long story short, I had to enable anti-aliasing for fonts for the entire system.  I typically set all of my graphics settings to the lowest possible levels in order to not have to see stupid animations or other things that slow down my experience just to be on par with Windows, and it looks like font anti-aliasing is one of the settings that got turned off.

So, a quick tweak to the drop down box here:

And everything now looks nice and pretty.  Here's the exact same page from before, this time with system-wide anti-aliasing enabled:

Problem solved.