Firefox issue
I recently had to reinstall my main PC’s NetBSD system after an unexpected NVMe SSD failure. I didn’t have a full backup of the system, just some configuration and home folder files that made it easier to restore the system, so it was essentially a fresh install of the recent NetBSD 11 release.
I’m using Xfce as my main desktop environment and Firefox as my primary browser. My current graphics card, a Radeon 5700 XT, doesn’t support graphics acceleration reliably. More precisely, it is buggy and causes frequent system crashes, so I started X.org with acceleration disabled.
Interestingly, this caused Firefox to crash and, after the second attempt, drop me into rescue mode. Since it was a pretty fresh installation, I didn’t think it was a plugin issue. Initially, I kept using rescue mode, but since it disables all plugins, that quickly became unfeasible.
After some fiddling around, I found that both the “Use recommended performance settings” and “Use hardware acceleration when available” options had to be disabled. I don’t remember this happening in the past. Typically, these options wouldn’t cause Firefox to crash, but would instead just make it slower. It is likely that newer versions of Firefox behave differently when hardware acceleration is unavailable or disabled.
Disabling the aforementioned options made the browser work normally again. An additional improvement in stability was achieved by rebuilding the packages from the current pkgsrc tree.
wmux issue
As soon as I switched to the NetBSD 11 branch, I started experiencing a very annoying issue with mouse handling. The symptoms would start appearing after a few applications, or a few windows of the same application, had been opened. Switching windows, for example with Alt+Tab, would not actually switch the focus to the new window. The previous application would continue to react as if it still had focus. Additionally, application menus would stop working, even when using keyboard shortcuts.
Using the desktop environment in this state was quite complicated. I suffered from this issue for quite a long time, which forced me either to avoid rebooting for as long as possible when the mouse was working correctly, or to rely mainly on keyboard shortcuts.
Fortunately, I noticed at one point that the mouse would suddenly start working correctly after I removed my wireless gamepad receiver. It turned out that the receiver was attached as a second wsmouse(4) device to wsmux(4), causing the symptoms described above.
The solution I decided to use was to remove wsmouse0 (which was the receiver) from wsmux using the following cron line:
@reboot /usr/sbin/wsmuxctl -f 0 -r wsmouse0
There is a risk that wsmouse0 could be the actual mouse if the receiver is disconnected, or if the device enumeration changes for some other reason. However, this worked quite reliably for me and made my system usable again.
ssh gnome-daemon-keyring
Another small issue I always face is getting gnome-keyring-daemon to start its SSH agent service so that xfce4-terminal asks for the SSH passphrase only once, using a graphical prompt, and then works across all terminal windows during the session.
This can be solved quite easily by enabling the “SSH Key Agent (GNOME Keyring: SSH Agent)” checkbox in the Xfce4 “Session and Startup” settings, under the “Application Autostart” tab. However, this is not enough, because it starts the session but does not propagate the SSH_AUTH_SOCK environment variable to the rest of the environment.
For that, the “Launch GNOME services on startup” checkbox also needs to be enabled in the “Advanced” tab of the same “Session and Startup” settings. I also add the following line to .profile:
export SSH_AUTH_SOCK=0
With these settings, the GNOME Keyring SSH agent works properly across the Xfce session, and xfce4-terminal can reuse the same SSH credentials across terminal windows.
