Wayland on Major Hayden

Fix big cursors in Java applications in Wayland

major@mhtx.net (Major Hayden) — Fri, 26 Apr 2024 00:00:00 +0000

Scroll through the list of Wayland posts posts on the blog and you’ll see that I’ve solved plenty of weird problems with Wayland and the Sway compositor. Most are pretty easy to fix but some are a bit trickier.

Java applications are notoriously unpredictable and Wayland takes unpredictability to the next level. One particular application on my desktop always seems to start with massive cursors.

This post is about how I fixed and then discovered something interesting along the way.

Fixing big cursors

I recently moved some investment and trading accounts from TD Ameritrade to Tastytrade. Both offer Java applications that make trading easier, but Tastytrade’s application always started with massive cursors.

To make matters worse, sometimes the cursor looked lined up on the screen but then the click landed on the wrong buttons in the application! Errors are annoying. Errors that cost you money and time must be fixed. 😜

Some web searches eventually led me to Arch Linux’s excellent Wayland wiki page. None of the adjustments or environment variables there had any effect on my cursors.

I eventually landed on a page that suggested setting XCURSOR_SIZE. I don’t remember ever setting that, but it was being set by something:

$ echo $XCURSOR_SIZE
24

One of the suggestions was to decrease it, so I decided to give 20 a try. That was too big, but 16 was perfect and it matched all of my other applications:

$ export XCURSOR_SIZE=20
# /opt/tastytrade/bin/tastytrade

That works fine when I start my application via the terminal, but how do I set it for the application when I start it from ulauncher in sway? 🤔

Desktop file

The Tastytade RPM comes with a .desktop file for launching the application. I copied that over to my local applications directory:

cp /opt/tastytrade/lib/tastytrade-tastytrade.desktop \
 ~/.local/share/applications/

Then I opened the copied ~/.local/share/applications/tastytrade-tastytrade.desktop file in a text editor:

[Desktop Entry]
Name=tastytrade
Comment=tastytrade
Exec=/opt/tastytrade/bin/tastytrade
Icon=/opt/tastytrade/lib/tastytrade.png
Terminal=false
Type=Application
Categories=tastyworks
MimeType=

I changed the Exec line to be:

Exec=env XCURSOR_SIZE=16 /opt/tastytrade/bin/tastytrade

I launched the application again after making that change, but the cursors were still huge! There has to be another way. 🤔

systemd does everything 😆

After more searching and digging, I discovered that systemd has a capability to set environment variables for user sessions:

Configuration files in the environment.d/ directories contain lists of environment variable assignments passed to services started by the systemd user instance. systemd-environment-d-generator(8) parses them and updates the environment exported by the systemd user instance. See below for an discussion of which processes inherit those variables.

It is recommended to use numerical prefixes for file names to simplify ordering.

For backwards compatibility, a symlink to /etc/environment is installed, so this file is also parsed.

Let’s give that a try:

$ mkdir -p ~/.config/environment.d/
$ vim ~/.config/environment.d/wayland.conf

In the file, I added one line with a comment (because you will soon forget why you added it 😄):

# Fix big cursors in Java apps in Wayland
XCURSOR_SIZE=16

After a reboot, I launched my Java application and boom – the cursors were perfect! 🎉

I went back and cleaned up some other hacks I had applied and added them to that wayland.conf file:

# This was important at some point but I'm afraid to remove it.
# Note to self: make detailed comments when adding lines here.
SDL_VIDEODRIVER=wayland
QT_QPA_PLATFORM=wayland

# Reduce window decorations for VLC
QT_WAYLAND_DISABLE_WINDOWDECORATION="1"

# Fix weird window handling when Java apps do certain pop-ups
_JAVA_AWT_WM_NONREPARENTING=1

# Ensure Firefox is using Wayland code (not needed any more)
MOZ_ENABLE_WAYLAND=1

# Disable HiDPI
GDK_SCALE=1

# Fix big cursors in Java apps in Wayland
XCURSOR_SIZE=16

I’m told there are some caveats with this solution, especially if your Wayland desktop doesn’t use systemd to start. This is working for me with GDM launching Sway on Fedora 40.

Efficient emoji experience in Wayland

major@mhtx.net (Major Hayden) — Fri, 27 May 2022 00:00:00 +0000

I recently moved over to the Sway window manager (as I mentioned in my last post) and it runs on Wayland. That means bidding farewell to X. Although this is a step forward, it caused some of my workflows to break.

My original post about my efficient emoji workflow inspired many people to give it a try. Everything was great until I moved to Wayland and suddenly rofimoji stopped pasting emojis on demand. 😱

So is this a big deal or something?

Well, yes.

Some people would shrug this off and go on about their day. But wait – emojis are core to my workflow. Sure, I use them liberally in my communications via chat or email, but I also sprinkle them in various places to ensure applications handle unicode characters properly.

When I worked on the Continuous Kernel Integration (CKI) team at Red Hat, we wanted to send concise and informative emails in plain text. Our team added colorful emoji symbols, reduced the length of our emails, and won praise (and some consternation) from kernel developers. We even named our releases using emojis for a while (the first one was 🐣). 🤭

Emojis in wayland

In Fedora, we need some packages:

$ sudo dnf install rofimoji wl-clipboard wtype

Why do we need these?

rofimoji pops up an emoji picker in rofi where you can quickly search for emojis
wl-clipboard gives you the wl-copy and wl-paste tools, similar to xclip from X
wtype replaces xdotool from X

Sway is heavily keyboard driven and that’s why I love it. More typing and less mouse. We need a keyboard shortcut for rofimoji. I use MOD-D for regular rofi, so I chose to use MOD-E for rofimoji. (MOD is likely the key on your keyboard with the Windows logo on it.)

Open your sway configuration file (usually ~/.config/sway/config) and add a line:

bindsym $mod+e exec ~/bin/launch_rofimoji

Save the shell script to ~/bin/launch_rofimoji:

#!/bin/bash

# Determine which output is currently active (where the mouse pointer is). 🤔
MONITOR_ID=XWAYLAND$(swaymsg -t get_outputs | jq '[.[].focused] | index(true)')

# Let's pick our emojis! 🎉
rofimoji --action type --skin-tone light \
 --selector-args="-theme solarized -font 'Hack 12' -monitor ${MONITOR_ID}"

Ensure the script is executable:

$ chmod +x ~/bin/launch_rofimoji

At this point, you can reload sway’s configuration with MOD+SHIFT-C. After a brief screen flicker, try the MOD+E keyboard combination and rofimoji should appear! Search for your favorite emoji, press enter, and enjoy! 🍰

Caveats

This script works well for me terminals, Visual Studio Code, Firefox, and most GTK-based applications. However, I still have issues using it with Electron based applications (such as Slack). If I bind a sway key combination to something super simple, like wtype banana, I end up with numbers pasted into Electron applications. That’s something I am still working to solve¹.

If you run into issues where emojis don’t appear, or you have unusual carriage returns after your emojis, you may want to remove --action type and try --action copy or --action clipboard. These different actions use different methods for copying and pasting emojis into your applications. You can stack actions separated by spaces, such as --action clipboard type. You may need to experiment with these to figure out what works on your machine.

Still having trouble? Consider using clipman. It’s a more robust clipboard for wayland and you can start it automatically in sway:

exec wl-paste -t text --watch clipman store --no-persist

You can query clipman history as well. This could help you determine what’s not being copied across correctly from rofimoji.

My workaround is to use Slack in Firefox. I’d love to just stop using Slack altogether, but I don’t have a choice. 😭 ↩︎

Sway reload causes a Firefox crash

major@mhtx.net (Major Hayden) — Tue, 24 May 2022 00:00:00 +0000

My workday takes me from email to terminals to browsers to documents. I love tiling window managers because they keep me organized and less distracted. Many are less resource-intensive as well.

Although i3 has graced my displays for years now (and I’ve written many posts about it), I recently picked up an AMD graphics card and made my way to sway.

The biggest difference between the two is that sway runs on Wayland rather than X. Sway has control over how nearly everything works, such as input devices, displays, backgrounds, and more. If you were frustrated with lots of hacks in i3 for various X-related things, you might enjoy sway.

But then stuff breaks

Much of my early experience with sway involves this process:

Change a configuration in sway 1.7.1
Reload the configuration live
Scrunch my face and say “Well, that’s not quite right.”
Read the docs
Go to step #1 😉

Fortunately, sway puts up with my constant reloads of the configuration until one day when I changed lots of configuration items and suddenly every reload caused Firefox to crash. My primary version of Firefox is the Developer Edition (currently 101.0b9), but I also keep a stable version of Firefox (version 100) around that Fedora provides.

I started up the default Fedora version of Firefox, reloaded the configuration in sway, and the stable Firefox crashed, too. 🔥

Nothing appeared on the screen when Firefox crashed. The window just disappeared and my terminal filled up the screen where Firefox was. I could reproduce the crash multiple times with both versions of Firefox. The crash kept occurring even after a reboot.

When I ran either version of Firefox from the command line, I finally got some error output:

Lost connection to Wayland compositor.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

Hmm, it looks like Firefox can’t talk to Sway for a moment and that might cause the crash. But why did this suddenly start happening?

Working backwards

I gradually backed out the recent sway configuration changes and finally found the configuration involved in the crash:

input * {
 # Enable numlock when sway starts.
 xkb_numlock enable
 # Set up compose keys.
 xkb_options compose:rctrl
}

If I removed that section, Firefox stopped crashing on sway config reloads. If I put it back in, Firefox crashed.

I tried removing only the xkb_numlock line. Firefox crashed. The same thing happened when I removed only the xkb_options line.

Sway’s documentation notes that you can apply input configuration to all devices with input *, so the configuration was valid.

Search time

Armed with an error message and a method for reproducing my crash, I set off to use the most powerful system administrator tool on the market: Google. 😜

I landed on Mozilla Bug 1652820 where other Firefox users noted that sway config reloads caused crashes for them, too. A user noted further down in the bug that if they removed the * from their input configuration and specified the actual device identifier, the problem went away.

Fixing the crash

I ran back and looked at my problematic configuration:

input * {
 xkb_numlock enable
 xkb_options compose:rctrl
}

Now the big question: how do I identify my keyboard? 🤔

As I mentioned before, sway controls everything, including input devices. You can query about things that sway knows by using swaymsg and it automatically dumps data in JSON format if you use a pipe:

$ swaymsg -t get_inputs | jq -r '.[].identifier' | grep -i keyboard
1241:662:USB-HID_Keyboard
1241:662:USB-HID_Keyboard_Mouse
1241:662:USB-HID_Keyboard_Consumer_Control
1241:662:USB-HID_Keyboard_System_Control
1241:662:USB-HID_Keyboard

My keyboard is identified as 1241:662:USB-HID_Keyboard according to sway. I updated my input configuration to specify the exact device:

input "1241:662:USB-HID_Keyboard" {
 xkb_numlock enable
 xkb_options compose:rctrl
}

I reloaded the sway configuration, started Firefox, reloaded the configuration once more, and Firefox was still running. 🎉

🐙 Have multiple keyboards or input devices? Other users noted in the bug report that the crash will happen again (even with specific identifiers) if you have two keyboards and both keyboards are connected. If you run into this problem, another user shared their workaround using swaymsg called via exec.