I like my desktop but some things really drive me mad. I recently switched to an AM5 board (yeah yeah first world problems) which came with an integrated adapter. Which sucks. Badly. Dunno if it’s the driver or interference from the board itself or due to the case shielding the signal. I don’t really care as well. It can however not be deactivated in the UEFI settings.

I’m using a BT adapter plugged in via USB for years now and moved this over to my new system. It works _excellent_ even with multiple devices. I get clear sound without crackling on my headphones, which is what I really care for to stay “in the zone” for work.

Alas Gnome does not let you choose which BT adapter is used – unlike we know this e.g. from the NetworkManager. Apparently it even defaults to the _first_ adapter it finds, which is by design the integrated one – that I do not want in my case. I can basically only tell them apart by their addresses that I can obtain via the hcitool command:

$ hcitool dev
Devices:
	hci1	10:B1:DF:AA:63:50
	hci0	00:1A:7D:DA:71:06

The full details on this can be extracted from this [closed] 5 years old feature request: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/263 (let user choose one bluetooth device from several in gnome control center)

And everything mentioned there is still true and while I usually can understand Bastien’s reasoning in this case I can’t. Alas not all is lost. It’s a little tedious but the following example script was added to unbind an adapter:

#!/bin/sh

ADAPTER_TO_DISABLE=${1:-hci0}
SYSFS_PATH=/sys/class/bluetooth/$ADAPTER_TO_DISABLE

if [ ! -h $SYSFS_PATH ] ; then
	echo "Could not find adapter $ADAPTER_TO_DISABLE"
	echo "Usage: $0 [hciX]"
	exit 1
fi

USB_DEVICE_PATH=`realpath $SYSFS_PATH/device`
USB_DEVICE=`basename $USB_DEVICE_PATH`
echo $USB_DEVICE > $SYSFS_PATH/device/driver/unbind

The adapter will be back on the next reboot so it’s a little tedious but at least I can now kill the malfunctioning one. It’s a hammer to a nail but it works. Put in a script it may be called like this:

sudo unbind-bluetooth-driver.sh hci1

Oddly enough something in the gnome-shell extension acts up now and duplicates the device list.

BT quick selection modal of Gnome duplicating the list of known devices

I can live with that though and it may even be fixed with a more recent version already. I’m still on 44.9 and somewhat behind on this currently.

So I got a stuck from time to time. No mailbox or calendar would load and Evolution eventually claim that it can’t connect to the accounts. Turns out this is quite literal. I’m on and that has a framework for single sign-ins called GNOME Online Accounts or GOA for short (that thing I wish the Nextcloud client would USE too).

Apparently this happens _sometimes_ after standby/suspend, that I use quite often to save on power, so it was really hard to find. Looks like the goa-daemon gets stuck on resume. There is nothing in the journal or so.

Anyway, it can be restarted quite easily by executing `/usr/libexec/goa-daemon --replace` manually. So basically what happens on login. The effect on Evolution is instant. Yay, ~~spam~~mails again!

Today I scratched an itch I had with and . Every time I run it on my PC I have to drag around the window until it fills my 3 displays setup. It’s tricky because it’s a grown installation and the displays have different resolutions.

Gnome has smart borders auto-sizing windows when you come close to a border. Usually that’s awesome but in this case it’s not. wmctrl to my rescue!

Find out about current window position when satisfied: wmctrl -G -l -x

Use that information for a one liner script: wmctrl -x -r code.Code -e 0,0,109,5276,1136

This will do until I get a 4k display or learn how to auto-run this snippet on the launch of vscode (like I do this with RisingWorld to force semi borderless fullscreen) 🤣

Integrate with GNOME Online Accounts Single Framework · Issue #2550 · nextcloud/desktop (GitHub)
GNOME has a feature for managing online accounts in one place ( GnomeOnlineAccounts | GOA). In it's current state Nextcloud is supported and it can read calendar, contacts and documents (as in ...

GNOME has a feature for managing online accounts in one place ( GnomeOnlineAccounts | GOA).

In it’s current state Nextcloud is supported and it can read calendar, contacts and documents (as in providing a quick mount option in the file explorer): https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Providers

This way account credentials can be shared and are configured and managed in one place where they can be requested by an application. The communication is done via D-Bus.

Currently I have to configure my accounts in two places, the nextcloud-client and in GOA, to get a Nextcloud server tightly integrated into my system and while the passwords end up in the same place (gnome-keyring) it’d be more user friendly to share this from a common ground instead of having to configure this twice for each Nextcloud account.

There’s a weird issue with (snap) on that starts when using voice chat causing really bad lag and short freezes (input, rendering, everything) that became worse over time. My journal filled up with looping messages from appindicator causing this.

appindicatorsupport(at)rgcjonas.gmail.com[2514]: discord1, Impossible to lookup icon for 'discord1_12-panel'

Followed by a JS exception and trace:

JS ERROR: Exception in callback for signal: icon: Error: Argument 'filename' (type filename) may not be null

When I finally found the cause of this I went on looking for a solution and it seems like the unsung hero @3v1n0 fixed this long standing bug like 8 days ago: https://github.com/ubuntu/gnome-shell-extension-appindicator/commit/745c66a73e0a15a870e92e5aa461e2e9e646b899

Here is a more coherent report on this: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1849142

Fun thing is: I only have that indicator because Discord would eventually crash without trying to access this.

Now it’s patched and gone – back to 😁

Today I had to access my computer via VNC. There are several manuals how to enable VNC on a typical Linux desktop nowadays. It usually involves some sort of clicking on Sharing => Enable Screenshare and you’re done. It’s really that easy.

How would I do this however remote when I can not access my already running desktop computer via VNC? SSH is enabled on my machines since most of my work involves jumping and tunneling my way through various networks to get stuff done. Just forwarding X was not enough today.

Turns out this is really easy as well. The screensharing feature on my distribution is done with Vino. That’s an integrated server for and this is exactly what the user starts by enabling the screenshare feature. Since is part of gnome it can be configured using gsettings.

So after enabling the screenshare for testing on my laptop I tested for all existing keys by running this listing:

gsettings list-recursively | grep Vino

It’s really short and basically all settings are no-brainers. Only the password had me wondering but it turned out this is just base64 encoded (and also optional). All that is left is running the vino-server binary in the end. This needs the correct environment variable $DISPLAY set since our target is a running X session. This one we can determine by executing the command w and looking for the TTY in use. Hint: It’s :1 in this case.

 beko  ~  w
  20:35:15 up  5:12,  1 user,  load average: 1,92, 2,33, 2,37
 USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
 beko     :1        15:24   ?xdm?   2:02m  0.00s /usr/libexec/gdm-x-session --run-script /usr/bin/gnome-session

Oh and you should also not connect with the X11 forward option -X because running the vino-server with this will result in some really funny endless picture in picture mode that I did totally not try out by mistake 😉

Now that I had all the information I needed I hacked together this little script that does this more or less automatically so I can forget about this again [and look it up two years later in my own blog]. It’s really crude and your mileage may vary. It does not account for multiple users or multiple running X Sessions:

export DISPLAY=$(w -oush | grep -Eo ' :[0-9]+' | uniq | cut -d \  -f 2)
echo "Display is $DISPLAY"
gsettings set org.gnome.Vino require-encryption true
gsettings set org.gnome.Vino use-alternative-port false
gsettings set org.gnome.Vino disable-background false
gsettings set org.gnome.Vino alternative-port 5900
gsettings set org.gnome.Vino icon-visibility 'client'
gsettings set org.gnome.Vino disable-xdamage false
gsettings set org.gnome.Vino authentication-methods "['vnc']"
gsettings set org.gnome.Vino prompt-enabled false
gsettings set org.gnome.Vino require-encryption true
#pw is just base64 so basically just echo -n 'awesomeness'| base64
gsettings set org.gnome.Vino vnc-password "YXdlc29tZW5lc3M="
gsettings set org.gnome.Vino view-only false
/usr/libexec/vino-server &
export VINOPID=$!
echo "Try vnc://$HOSTNAME:5900/"
echo "vino-server pid may be $VINOPID"

And that’s it. There is no root or sudo involved.

Example output executing the script

Don’t forget to kill the pid when done 🙂