Our Friendship is Over. Xdummy Replaces Xvfb

I don't even know why I did this. Well, I kind of do. When I asked GNOME to play, he bitched about Xvfb not having RANDR extensions. Petty right?

I remember something when reading the x11vnc pages, about how this Xdummy was 'better' because it supports such a thing. So I went over to take a look. From their page;

A hack to run a stock Xorg(1) or XFree86(1) X server with the "dummy" (RAM-only framebuffer) video driver such that it AVOIDS the Linux VT switching, opening device files in /dev, keyboard and mouse conflicts, and other problems associated with the normal use of "dummy".

In other words, it tries to make Xorg/XFree86 with the "dummy" device driver act more like Xvfb(1). The primary motivation for the Xdummy script is to provide a virtual X server for x11vnc but with more features than Xvfb (or Xvnc); however it could be used for other reasons (e.g. better automated testing than with Xvfb.)  One nice thing is the dummy server supports RANDR dynamic resizing while Xvfb does not.

So, for example, x11vnc+Xdummy terminal services are a little better than x11vnc+Xvfb.

To achieve this, while running the real Xserver, Xdummy intercepts system and library calls via the LD_PRELOAD method and modifies the behaviour to make it work correctly (e.g. avoid the VT stuff.) LD_PRELOAD tricks are usually "clever hacks" and so might not work in all situations or break when something changes.

It pointed out that a driver should exist in this location;

/usr/lib/xorg/modules/drivers/dummy_drv.so

Unfortunately (as it would appear my luck), this file did not exist. The file is located in the package

xf86-video-dummy

Which... did not exist for the BB in Angstrom. Time to build it. I got the tar.gz file, and extracted it out. I noticed, unlike building x11vnc where I ran ./configure and then make, that the only file that could be run was autogen.sh. So I ran it. It seems this automagically pulls together a bunch of macro files (.m4) from /usr/share/aclocal and then does some other things, and then does the ./configure and then make for you. Assuming you don't get any errors. Which of course, I did.

./configure: line 20790: syntax error near unexpected token `RANDR,'
./configure: line 20790: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'

Poking around, I noticed that this macro should exist in a file called xorg-server.m4 located in /usr/share/aclocal that I spoke of. I didn't have this file. It comes with the xserver-xorg-dev package, which thankfully exists. I ran autogen.sh again and...! Nothing. After literally hours, I ran across some reference to autoreconf and the --force option which will force updating all files. Hmmmm, perhaps this was the issue? Worth a shot. So, I opened the autogen.sh file, and added --force to the command;

autoreconf -v --install --force || exit 1

Ran again. Boom. Everything OK, and it spat out the library file into ./src/.libs

Now I had the driver, I also needed this Xdummy application. This comes with the tar.gz file that comes with x11vnc, and resides in the ./x11vnc/misc directory. Copy this to the /usr/bin folder.

Now, I start my startx slightly differently;

startx -- `which Xdummy` :1

And she's away! Sorry Xvfb, go sit in your corner.

A Little About startx

startx [ [ client ] options ... ] [ −− [ server ] [ display ] options ... ]

OK, so startx is what is used to start your X server and some X clients. As I previously mentioned, most times you'll just be running your Display Manager (xdm, gdm, etc.) which will do similar things to what startx would; that is - start your X server (hardware abstraction) and X clients; a lovely login screen ready for GNOME (or whatever).

Not having a /dev/fb0, and thus not being able to run startx in its default greatness, meant I needed to look under the hood. I found this command;
startx -- `which Xvfb` :1 -screen 0 1024x768x24

Assuming you have Xvfb installed (I believe it is by default on BB A6), then try typing which Xvfb at the command prompt. You should see /usr/bin/Xvfb. That's to say you could just as happily typed;
startx -- /usr/bin/Xvfb :1 -screen 0 1024x768x24

Here we only have server side arguments (stuff after the '--'); that is, the server to use, what display to attach it to, and some server arguments.

Now, just some of the variables that are set up in the default code;
userclientrc=$HOME/.xinitrc               DOES NOT EXIST
sysclientrc=/usr/lib/X11/xinit/xinitrc    EXISTS
userserverrc=$HOME/.xserverrc             DOES NOT EXIST
sysserverrc=/usr/lib/X11/xinit/xserverrc  DOES NOT EXIST
defaultclient=xterm
defaultserver=/usr/bin/X

This is from the manual.

To determine the client to run, startx first looks for a file called .xinitrc in the user’s home directory. If that is not found, it uses the file xinitrc in the xinit library directory. If command line client options are given, they override this behavior and revert to the xinit(1) behavior.

To determine the server to run, startx first looks for a file called .xserverrc in the user’s home directory. If that is not found, it uses the file xserverrc in the xinit library directory. If command line server options are given, they override this behavior and revert to the xinit(1) behavior. Users rarely need to provide a .xserverrc file.

See the xinit(1) manual page for more details on the arguments.

OK, so lets use an example. The system-wide xinitrc and xserverrc files are found in the /usr/lib/X11/xinit directory. Now looking at the code;

# process client arguments
if [ x"$client" = x ]; then
    client=$defaultclient

    if [ x"$clientargs" = x ]; then
        if [ -f "$userclientrc" ]; then
            client=$userclientrc
        elif [ -f "$sysclientrc" ]; then
            client=$sysclientrc
        fi
    fi
fi

This checks if $client is NULL.
x"$client" = x

If it is, then it sets the default client. Now, if no client arguments are given, then that is replaced with the xinitrc file. So running this command;
startx -geometry 80x50+494+51

Would cause the client to be set to xterm via the $defaultclient, however, the xinitrc file would not be run due to the arguments.

The .xinitrc is typically a shell script which starts many clients according to the user’s preference. When this shell script exits, startx kills the server and performs any
other session shutdown needed. Most of the clients started by .xinitrc should be run in the background. The last client should run in the foreground; when it exits, the
session will exit. People often choose a session manager, window manager, or xterm as the 'magic' client.

twm &
xclock -geometry 50x50-1+1 &
exec xterm -geometry 80x66+0+0 -name login

So, start all your clients in the background using the '&' operator. The last one should use exec and be run in the foreground. This basically means that the process is passed over to xterm. Once this shuts down, xinit will then shutdown the X server and process any shutdown commands.

Running an Executable (Should be Easy, Right?)

Remember in Windows when you move to a directory like this?
cd dir1
cd subdir2

And then you want to run an executable file in subdir2?
exec1.exe

All good? Try that in Linux, and it is always trying to load the file from the /usr/bin folder. If you actually want to tell Linux to load from the folder you have just spent 15 minutes navigating to, type;
./exec1

The joys.

Extracting tar.gz files

I found this command which works a treat

tar -xvzf filename.tar.gz

f: this must be the last flag of the command, and the tar file must be immediately after. It tells tar the name and path of the compressed file.

z: tells tar to decompress the archive using gzip

x: tar can collect files or extract them. x does the latter.

v: makes tar talk a lot. Verbose output shows you all the files being extracted.

Headless GDM - Stop GDM From Trying to Start an XServer

So, you may have worked out that in order to load up X Clients, you need an X Server. startx is commonly used to start the X Server, however, most times you'll be using a Display Manager (xdm, gdm etc.).

Now let's say that you have a BeagleBone; which if no cape (LCD/DVI) is detected, it doesn't load up the /dev/fb0 device. I guess to save memory. Without that, the X Server fails to start;

(EE) open /dev/fb0: No such file or directory
(EE) No devices detected.

That's fine, I didn't like you anyway.

I made a new friend with Xvfb, and with x11vnc I can happily have X Clients, including GNOME and Firefox load themselves there.

So - what if I want to log in via VNC, and see the GDM graphical login screen? You'll see lots of articles about using the XDMCP (display manager control protocol) which allows the VNC server to pass requests to GDM on UDP 177; but this is related to terminal services. By that I mean, GDM needs to be happily running already at the local console, before it will start dishing out remote requests.

Since, I'm guessing version 2.30, GDM appears to have culled the ability to STOP GDM from trying to start the X Server. That means, the --no-console doesn't work, and neither does trying to mess around with the /etc/gdm/custom.conf file under the mysteriously vanished [servers] heading. So don't try adding '0=inactive' to that either.

Short answer is then; with GDM 2.32.1, you cannot get it to start up without having it try and start an X Server. Even though you have your new Xvfb friend available.

Headless Xvfb + x11vnc and XTEST Not Found

I just wanted to post my findings with the A6 rev of the BeagleBone (white). If no LCD/DVI cape is attached, then the boot doesn't load a frame buffer (/dev/fb0). As such, no X11 server starts up. x11vnc requires a real X11 server to be running for it to work. There is also the program xvnc which can create a virtual X11/frame buffer on your behalf, but I couldn't see it in the Angstrom packages.

 

So, I installed Xvfb - and created a virtual frame buffer. Install the package

xserver-xorg-xvfb

 

When starting, keep in mind (for the newbies like me coming from Windows), it is case-sensitive. To create a virtual X11 server;

Xvfb :1 -screen 0 1024x768x16 &

When you do this, you will probably get these errors;

(EE) AIGLX error: dlopen of /usr/X11/lib/dri/swrast_dri.so failed (dlopen(/usr/X11/lib/dri/swrast_dri.so, 5): image not found)
(EE) GLX: could not load software renderer

So, load the package;

mesa-dri-driver-swrast

 

OK, error gone. Now we can export our display (an environment variable so Firefox, or whatever X11 client you run, can attach to the display).

export DISPLAY=:1

 

Load up Firefox (something to see)

firefox &

 

And now we try and start the x11vnc;

x11vnc -display :1 -bg -nopw -xkb

 

At this point, with this distro, you'll see an error about XTEST not being found/not available when it was built. Here describes the issue;

http://www.karlrunge.com/x11vnc/faq.html#faq-missing-xtest

 

I made sure that I had all the proper libraries installed, so I figured it must have been a bad build on Angstrom. So, now to build it myself. I ensured all required libraries were available; these are the ones ending with '-dev'; by default they all appeared to be available. I followed the instructions here;

http://www.karlrunge.com/x11vnc/#building

 

Except the copy line didn't work too good for me, so do what you need to do to copy it to the /usr/bin folder.

 

Now it starts, and there are no errors about XTEST, and the input works!

Alias and Directory Listings

Coming from a Windows background, learning Linux is tough. The stock 'ls' (directory listing) is horrid to my eyes. To 'Windows' it up, I use;

ls --color --group-directories-first -al

So I don't have to type that every time, I creat an 'alias';

alias ls='ls --color --group-directories-first -al'

To us ls as originally intended, just enclose it in single quotes;

'ls'

Turns out that this doesn't survive a reboot. Now to play with bash and profile scripts... Yeah - what the?

I pinched the examples here;
http://www.gigamegablog.com/2012/01/29/beaglebone-linux-101-configuring-angstrom-linux/

Apparently the .bashrc is not good enough - you also need the .profile. I believe this has something to do with 'login' or 'non-login' shell;

What is a login or non-login shell?

When you login (type username and password) via console, either sitting at the machine, or remotely via ssh: .bash_profile is executed to configure your shell before the initial command prompt.

But, if you’ve already logged into your machine and open a new terminal window (xterm) inside Gnome or KDE, then .bashrc is executed before the window command prompt. .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal. 

Of course it is.