How to use Xephyr for testing changes
Xephyr is a nested X server that runs as an X application, which means that you get a normal window that shows the X session.
Xephyr can be a useful tool to:
- trying out someone else's build or
- test behaviour or changes without risking that your current window manager session crashes or
- debugging window manager issues or
- taking smaller screenshots
Some general information can be found here:
Let's dive in.
To start I usually open at least two terminals.
In the first one I am going to start Xephyr to start the X server, the command I generally use is this:
Xephyr +extension RANDR +xinerama -screen 1280x760 :3The -screen option naturally specifies the size of the window (and session) while the :3 at the end specifies the DISPLAY the session is to open at.
The +extension RANDR and +xinerama options are not necessary in this case, but I keep them in case I want to add another screen to test multi-monitor functionality. Doing so would just be a matter of adding another -screen 800x600 argument as an example.
It should be noted that although Xephyr supports using more than one screen the interaction with them are rather finicky especially when it comes to mouse support; so expect to have to work mostly with keybindings if you try this.
Running the command should open a blank window.
If the window is swallowed or start up tiled then I recommend adding a client rule like this:
{ .class = "Xephyr", .flags = NoSwallow|Floating|Centered },Now it is time to start something inside the X server.
I move to another terminal and I run the following:
DISPLAY=:3 duskThe DISPLAY=:3 indicates which display the command should be executed under and here we say that the command should use display :3 (this need to be the same as what we passed as the last argument to Xephyr).
Running that a dusk session should start inside the Xephyr window.
If you focus on the window and you press Ctrl+Shift then Xephyr will grab input focus exclusively. You will need this if the modifier and keybindings used in the Xephyr session conflicts with your main window manager (otherwise you may end up moving the Xephyr window instead of the window inside the session, as an example).
Pressing Ctrl+Shift again will make Xephyr release exclusive input focus.
You may notice that dusk and dmenu does not have the same style or colours as you may have set in your .Xresources file. That would be because this is a new X session and no resources have been loaded.
You can run xrdb ~/.Xresources inside the session or DISPLAY=:3 xrdb ~/.Xresources if you are running it from a terminal outside the session to load Xresources.
The same goes with the background wallpaper. It may be blank if no background wallpaper has been set.
If you have Debug logging enabled (configured via the functionality setting) then additional output will be seen in the terminal where you are running dusk from.
In the following example we can see that KWrite is started along with some details indicating what the class, instance, title, window role and window type was and which client rule (if any) the window matched.
$ DISPLAY=:3 dusk
using ipc sock path of /tmp/dusk.sock:3
showws called for ws 1
xrandr: Failed to get size of gamma for output default
xrandr: Failed to get size of gamma for output default
Error: Another instance of the program is already running
unmapnotify: received event type FONT (18), serial 116002, window 4194309, event 528, ev->send_event = 0, ev->from_configure = 0
manage --> client KWrite
applyrules: new client KWrite (4194317), class = 'kwrite', instance = 'kwrite', role = 'MainWindow#1', wintype = '357'
applyrules: client rule 57 matched:
class: kwrite
role: NULL
instance: NULL
title: NULL
wintype: NULL
flags: 67117060
floatpos: 0m 0m 800W 600H
workspace: (null)
label: NULL
manage <-- (KWrite) on workspace 1
configurerequest: received event 12 for client KWrite
- x = 0, y = 0, w = 976, h = 567
propertynotify: received message type of _NET_WM_ALLOWED_ACTIONS (265) for client KWrite
propertynotify: received message type of WM_STATE (239) for client KWrite
propertynotify: received message type of _NET_WM_ICON_NAME (339) for client KWrite
propertynotify: received message type of _NET_WM_NAME (273) for client KWrite
propertynotify: received message type of WM_NAME (39) for client Untitled — KWrite
propertynotify: received message type of _NET_WM_NAME (273) for client Untitled — KWrite
propertynotify: received message type of WM_NAME (39) for client Untitled — KWrite
propertynotify: received message type of _IS_FLOATING (242) for client Untitled — KWrite
This can be useful especially if you are unsure what properties a window starts with and why a specific rule does not match. Note that window properties can change over time and what they start with won't necessarily be the same as what you see when using xprop on the window after the fact.
Back to Guides.