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)[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:

Here is a more coherent report on this:

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
 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
 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 🙂