The problem#

For various reasons you might want graphical access to another computer, since some things can't be done over a text interface, including actually designing and troubleshooting what the graphical interface looks like. The other computer might be in a remote location across the internet, in a different room, or simply have a less convenient form factor like a tablet or television, so it's easier to use your desktop's keyboard, mouse, and monitor.

The solution#

The standard solution for this is VNC, specifically the x11vnc VNC server.

To keep a VNC server open to the current X11 session:

x11vnc -usepw -nevershared -forever -localhost -loop &
#... (run one or more graphical applications that block)
# When done, kill everything.
rkill $$

Then to connect to it, assuming the hostname is tablet and you're set up to connect to it via SSH:

$ vncviewer -via tablet -passwd ~/.vnc/tab-passwd localhost

This assumes you've created a ~/.vnc/passwd password file on the server by running

$ x11vnc -storepasswd

and entering something at the prompt from your favorite password generator. No need to save the password anywhere as the file itself is the actual password; just copy it to the client at ~/.vnc/tab-passwd to match the path used in the example above.

The details#

The problem#

Web browser UIs have a lot more than just displaying the web page, which is useful when using them as a browser, but clutters the screen if all we want is to define what is displayed on part of the screen using HTML. So, can we get Firefox into a mode where it really does show just the website and nothing else? Firefox does have a fullscreen mode that does that, but it covers an entire monitor.

The solution#

To hide all of the Firefox menus and toolbars, put the following in the chrome/userChrome.css file under your Firefox profile directory (you will likely want to create a separate profile from the one you use for web browsing):

#TabsToolbar, #TabsToolbar-customization-target,
#nav-bar, #urlbar-container, #searchbar {
  visibility: collapse !important;
}

To hide the window border and titlebar, compile toggle-decorations.c and run

firefox &
./toggle-decorations $(xdotool selectwindow)

and then click on the Firefox window once it opens. It may be easier to bind it to a hotkey with xdotool getactivewindow or use some other way to identify the window.

The details#

The problem#

Many applications have a fullscreen mode that has a different interface from their windowed mode. For example, many media players will show just the video in fullscreen mode but include media controls in windowed mode. But, especially if you have a large monitor, you may want to use that interface while only having the application take up part of your monitor.

The solution#

I could not find a solution that works on every window manager.

The window manager handles resizing the application when it switches to fullscreen, so the most straightforward way to accomplish this is to not run a window manager. Problem solved! Unfortunately, window managers are really useful, so outside of some niche cases where you're positioning windows with xdotool, that's probably not what you want.

There's a "fakefullscreen" option in some forks of the very configurable window manager dwm: base dwm with the fakefullscreen patch always does fullscreen that way, the instantWM fork has a hotkey Super+Shift+F that toggles fake fullscreen for a window, and awesome can be configured to do the same.

For more common window managers, there is a solution, but more than two virtual monitors requires an xorg-server newer than 21.1.10 (which is the most recent release at time of writing, so you would have to compile it yourself), and in my tests, it only worked on Compiz, and not Mutter, KWin, or Xfwm. Use xrandr 1.5+ to define virtual monitors on sections of your monitors and then maximizing or fullscreening applications should respect those boundaries:

xrandr --setmonitor lefthalf 960/217x1080/132+0+0 LVDS-1
# This is a hack, should be "LVDS-1", not "none".
xrandr --setmonitor righthalf 960/217x1080/132+960+0 none

where the the geometery specification format is w/mmwxh/mmh+x+y (mmw/h="millimeters width/height") and LVDS-1 is the name xrandr gives to my physical monitor. Note that xorg-server 21.1.10 and older have a limit of one virtual monitor per physical monitor which we can circumvent by putting the second virtual monitor on "none".

The details#

The problem#

Which window I have focused is a signal to the computer for the state I want it to be in. For instance, I normally leave my speaker muted so, for example, I don't accidentally play sound from a website with unexpected videos. But this means that when I do want sound, I need to manually unmute the sound, even though I've already told the computer that I want to watch Netflix, which always involves turning on the sound.

Of course, for the particular problem of unmuting the sound, adding a keyboard shortcut and rereading xkcd 1205: Is It Worth the Time? probably would have been a more appropriate solution. But I wanted a general solution to the problem.

The solution#

Download x11_watch_active_window.py. Then the following script will unmute the speakers if Netflix is focused:

#!/bin/sh
x11_watch_active_window.py | while read -r FocusApp
do
    if [ "Netflix - Google Chrome" = "$FocusApp" ]
    then
        echo Netflix is focused, unmuting.
        pactl set-sink-mute 0 0
    fi
done

The details#

The problem#

The monitor-lock.py script in my previous blog post uses python-xlib, which currently mainly relies on manually porting Xlib functions to Python. This is why it is missing the barrier-related functions I needed in that post. There is work on automating this process, but it appears to be abandoned. I started trying to pick up where they had left off before finding the python-xcffib project which provides auto-generated bindings for libxcb and therefore gives full support for interacting with X at a low level from Python.

python-xcffib (named after the cffi library it uses for binding to the C XCB library) gives a slightly lower-level API than python-xlib, but they are both fairly thin wrappers over the X protocol, so the differences are minor. It was fairly straightforward to port my script from the previous post to use python-xcffib, available as monitor-lock-xcb.py.

Unfortunately, I ran into a bug in python-xcffib:

Traceback (most recent call last):
...
  File "./monitor-lock-xcb.py", line 38, in main
    devices = conn.xinput.XIQueryDevice(xcffib.xinput.Device.AllMaster).reply().infos
...
  File "/usr/lib/python3/dist-packages/xcffib/__init__.py", line 139, in _resize
    assert self.size + increment <= self.known_max
AssertionError

The solution#

I've submitted the fix upstream, so most likely you will not encounter this error. Updating to the latest version (after v0.8.1) should be sufficient to fix the problem.

The fix I applied was to modify the module's __init__.py (the location, which may be different on your machine, is in the stack trace). Specifically, on line 108 in the function Unpacker.unpack(), in the call to struct.calcsize(), change fmt to "=" + fmt.

The details#

The problem#

I hosted a LAN party¹ a little while ago and ended up needing to loan out multiple computers to guests in the interest of having no one try to lug their desktop over. As it turns out, I don't keep multiple of spare gaming-ready laptops around, so I needed to get more computers somehow.

The solution#

My desktop has three screens attached to it (two monitors plus a projector), so given an extra keyboard and mouse (or two), it should be possible to run multiple instances of the game on it at the same time to let multiple people play using the same computer.

The script from this forum post makes it easy to set up multi-pointer X so a second keyboard and mouse will get its own mouse cursor. Then each keyboard and mouse pair can interact with its own instance of the game.

As an additional aid, I wrote monitor-lock.py which allows you to assign a mouse to a monitor, so it cannot be moved off that monitor to prevent accidentally interacting with the other player's instance of the game.

The basic usage is that you first run it with no arguments to get the available screens and pointers getting an output something like this:

$ ./monitor-lock.py 
...
Available screens:
screen 0: {'x': 0, 'y': 0, 'width': 3840, 'height': 2160}
screen 1: {'x': 3840, 'y': 0, 'width': 1920, 'height': 1200}
screen 2: {'x': 3840, 'y': 1200, 'width': 1920, 'height': 1080}

Available pointers:
device 2: Virtual core pointer
device 17: second pointer

USAGE: ./monitor-lock.py [device] [screen]

and then in a screen session (so you don't have to worry about accidentally doing this on a monitor you've locked your pointer away from), run

./monitor-lock.py 2 0

and

./monitor-lock.py 17 1

to lock the primary pointer to the first screen and the second pointer to the second screen.

Just use Ctrl+C to kill the process when you want the pointer to be able to move freely again.

The details#

The problem#

I recently replaced my old Nvidia graphics card with a newer one. Upon booting up, I ran glxgears to test that 3D graphics were working properly and got an error like

X Error of failed request:  BadWindow (invalid Window parameter)
 Major opcode of failed request:  155 (NV-GLX)
 Minor opcode of failed request:  4 ()
 Resource id in failed request:  0x1200003
 Serial number of failed request:  34
 Current serial number in output stream:  34

The solution#

Either delete /etc/X11/xorg.conf or edit it and remove (or comment out) the "Files" section; that is, the lines

Section "Files"
    ...
EndSection

X forwarding#

Normally with X, it's easy to run an application on a remote computer just by using X forwarding:

local:~$ ssh -X host
host:~$ echo $DISPLAY
localhost:20.0
host:~$ xterm

The xterm will appear on your local computer.

But if you want to continue working with that application on a different remote computer (or once you are physically in front of the computer it is running on), then you're out of luck.

For an application running in the terminal, you can start it inside a GNU Screen (or tmux) session which you can detach and then attach to again on another ssh connection.

GNU Screen for X#

xpra (X Persistent Remote Applications) lets you move graphical applications from one computer to another in addition to fixing other problems with X forwarding. If you instead use xpra for the forwarding, then you can detach and reattach to the session at will.

X clipboard#

The X Window System, the basis for the GUI on most desktop Linux systems, defines how the clipboard works for copying and pasting between applications in Linux. One notable quark of X clipboard is that there's actually two clipboards in common use: the one you expect explicitly accessed via Copy and Paste menu items or key shortcuts called the CLIPBOARD and another one where you copy by selecting text and paste by pressing the middle mouse button called the PRIMARY selection.

X clipboard utilities#

Occasionally it is useful to be able to read or write the clipboard at the command-line. For most uses, your terminal emulator's copy and paste options are probably enough. The primary use case I have for using a command-line program to interact with the clipboard is when I am uploading a file as a Gist:

<file xclip

The xclip utility will copy the contents of the file onto the clipboard (PRIMARY, not CLIPBOARD, by default) and then I can paste it on the Gist website.

My system also has xsel which is very similar to xclip. Wikipedia actually lists several such programs, including the unfortunately named xcopy, not to be confused with XCOPY.

GNU Screen copy mode#

GNU Screen provides its own clipboard for copying information between the different windows of a screen session. ctrl+a, [ enters copy mode. In copy mode you can move the cursor using the arrow keys and page up/page down keys. Screen keeps a history (of configurable size), so you can scroll back pretty far. In fact, I use Screen's copy mode far more often for viewing the history in a terminal than for actually copying anything. You can exit copy mode either by using esc to cancel or enter once to mark the start of the selection and again to mark the end of it. Once you have copied something, ctrl+a, ] pastes the contents of the clipboard.