Xephyr glamor option not working

[blackbird9]

hI've been figuring out how to use Xephyr to make a second X display on a thinkpad T61. I read on phoronix that Xephyr had some work done a few years ago to add the glamor driver to improve its performance, so I've been trying to get it working. I installed it from packages, and Xephyr works fine on my system when running with defaults, which glxinfo reports uses the vmware opengl driver. Xephyr -? lists a -glamor option, so it appears to be in the code. I'm starting it using a script like this:-

#!/bin/sh
export DISPLAY=:0
Xephyr -glamor -screen 800x600 -nolisten tcp -reset -terminate :1 &
export DISPLAY=:1
twm

If I omit the -glamor option, everything works and I get the x-server up in its own window, and I can start other clients
from the twm root menu as usual. When I add -glamor, I just see a black unresponsive xephyr window, and xephyr process appears to hang. Twm returns exit code -1 and prints the error message :-
"twm: unable to open display ":1""
I get the same error if I replace 'twm' with 'xterm'.

$ uname -a
FreeBSD bear2 12.0-RELEASE-p4 FreeBSD 12.0-RELEASE-p4 GENERIC amd64
I can see in /var/log/Xorg.0.log that the Xorg root server has loaded the glamor driver successfully and is running it.

Does anyone know if the Xephyr glamor option has ever worked on freebsd?

 

[Phishfry]

I am looking at xephyr versus Xnest. How would you rank them?
Neither seems very popular.
Looks like Redhat is EOLing Xorg so I need to try out these features before all the old work is ruined.

 

[blackbird9]

Bit of a late reply(!) but I've had a better experience with Xephyr than Xnest, at least recently. I have used both for years, very useful if you want to get an X session on a remote machine, eg a machine on the test floor, either to run single clients or whole desktop. I also use nested X to obtain independent desktops for multiple users on the same machine, so run the nested server full screen in one virtual desktop, but for a different user.

Xephyr works very well, but sadly it appears to be no longer maintained and is actually deprecated by some linux distributions, I was very glad to see it still in ports on Freebsd 13.1. Xnest is part of the Xorg distribution so presumably will continue to be maintained, however in the version I am currently using there is a bug where expose events aren't being passed to clients properly which means that invalid areas of windows aren't always refreshed; for example a terminal window will lose it's refresh and I have to ctrl-l to get the client to redraw it. So I would recommend Xephyr if you are experimenting with nested X on freebsd.

A couple of nice things you can do with nested X:-
1. reserve a virtual desktop in your primary WM for a xephyr session; switch to a VC, log in as a different userid, and use xephyr to give this user an entire independent X desktop; a nice way to try out new window managers, for example, without recourse to a full VM

2. Essentially do the same as (1), but use ssh to start the X session on a remote machine. So for example to start a gnome session on a remote linux box from your BSD desktop, you might say something like
ssh -x username@remotesystem /usr/bin/gnome-session
- which will result in the entire gnome desktop running within the xephyr x-server.

This is just so useful in any kind of software development project, especially if you have multiple teams spread around different geographies.

There are lots of howto's on the web, just search for "run remote x session".

Another software that is interesting in this field is NX, which was a commercial product, with an open source version called freenx. That was designed to work over low bandwidth links and implemented clever compression techniques of the X protocol to achieve that. It also had the major benefit of full session management, so worth investigating if you are thinking of this type of application.

Network transparency was always one of the best features of X, which seems to be often overlooked in modern systems, and it's sad to see that is being removed as a design goal in wayland, as I understand it they are going to rely on things like vnc and rdesktop for remote sessions. Of course I can understand their decision in some respects, building a networked windowing system that will work across heterogeneous hardware is a much more difficult problem than making a single-machine local display system, which is hard enough in it's own right. And we can argue that web technologies can perform a similar function, for example if you were managing systems in a remote data centre, the modern way would be to use a web interface.

All credit to the original developers of X11 for "jumping high" and having a good stab at meeting that goal, it was pretty ground-breaking stuff back in the 80s, and in some ways was the foundation of companies like Sun.