GNU Xnee 3.07 released

We are pleased to announce the availability of GNU Xnee 3.07

GNU Xnee is a suite of programs that can record, replay and distribute
user actions under the X11 environment. Think of it as a robot that can
imitate the job you just did. GNU Xnee can be used to:
 Automate tests
 Demonstrate programs
 Distribute actions
 Record and replay 'macro'
 Retype the content of a file

Getting the Software

or one of the mirror sites as found in:


 f9fca0c7475a90487c86eca2027d0fcd  xnee-3.07.tar.gz

 510662476 1779830 xnee-3.07.tar.gz

New in this release

 * New features:
 Supports recording xnd replaying of XInput device events
 * Forced replaying of X11 core events can be done
 * Backward compatible with old session files

 * Build changes:

 Checks for makeinfo once, uses result many times
 Can build guis and manual without all doc stuff

 By default Xnee is built with XI support

 Looks for gtk-config when configuring
 Checks for makeinfo once, uses result many times
 Can build guis and manual without all doc stuff

 * Issues
 Human printout of X Input events needs more work
 Need to make X Input code be totally ifdefed away

 * New options:
 Discard recorded X Input device data,
 use recorded core device data

 Disable recording of XInput events

 * Fixed bugs as reported on ubuntuforums:

 savannah bug: #30134 "Missing xnee.xpm in gnee"
 savannah bug: #30136 "Configure misses to check for gnome.h"

 * Reported problems on N900 are fixed

 * Patches from Tuukka Pasanen, Fabian Keil

 * Experimental and undocumented features (read the source):
 * replay backend
 * xswine - new swinput backend for Xnee

xswine: new program for the GNU Xnee suite

I been writing a small program, xswine, that can take a recorded GNU Xnee session file and replay that to swinput . Swinput had its share of changes and a new swinput release will see the light of day any day. The difference betwen replaying using swinput compared to replaying using Xnee itself is that swinput fakes the device events from the kernel and Xnee fakes at X11 level using XTest.

There’s a some questions that need to be solved before a proper xswine release, such as:

  • how to map the device id as recorded from X Input Extension to the “correct” input device as presented by swinput
  • timing – what do we do when we drift away from the start time, but want to keep the recorded diff between events

Currently there’s not much of the recorded X11 events that can be replayed. Here’s the current list:

  • X11 motion event – no
  • X11 button event – no
  • X11 key event – no
  • X Input device motion event – yes!!!
  • X Input device button event – no
  • X Input device key event – no

This means xswine can replay (using the kernel) recorded Multi-touch events!

But if that’s all xswine can do do, why do I bother writing a blog entry. Two reasons:

  1. nobody reads my blog…so nobody will complain about this blog post
  2. I want to “claim” the name xswine

So, what does xswine mean?

X – is for Xnee

swin – is for Swinput

e – dear reader of this blog (just claimed I had zero readers!), help me out … what should e stand for?

If you compile GNU Xnee and swinput (and install) from CVS HEAD you should be able to do:

sudo modprobe swmouse devs=4 && sudo chmod a+rwx /dev/swmouse*
./cnee/src/cnee --record --mouse -o whoa-mule.xns
cat whoa-mule.xns | ./xswine/xswine

Preparing GNU Xnee 3.06 (and testing new XI2 features)

It’s been a while since the RECORD problems was found. Anyhow, now they’re solved (in Xorg) and GNU Xnee is now working as it should (given you’re using CVS HEAD and the latest Xorg server). I’ll start preparing a GNU Xnee 3.06 right away.

If you’re checking out the branch: xinput2-support ( ) you should be able to see the latest happenings when it comes to supporting XInput Extension (especially multiple input devices). I’ve just finished testing 8 (faked using swinput) faked “mouses”. Some 300 000 events were sent and all went fine so we’re actually making some progress here as well.

RECORD extension seems to be working again, GNU Xnee too

Seems as if I found a solution to a long time very serious bug (see prev. blog post) in GNU Xnee. GNU Xnee can now record (asynch) and use modifier+key to pause/resume/stop recording.

Played around with some XSync, XFlush to make sure we had a record context before firing the enable context call (XRecordEnableContextAsync) call.

Will now clean up the code, test (using swinput) some more (regression) and commit to CVS.

Dare I say we have a 3.04 release coming any day?

GNU Xnee, Xvfb and Xephyr …. and evdev?

In an attempt to automate (read cron) the Xnee tests using swinput I did the following:

  • Start Xvfb (Xvfb can’t read any keyboard and mouse)
  • Start Xephyr inside Xvfb (using evdev as input)
  • Attach the swinput devices to the Xephyr display only

Still the faked user input (mouse, keyboard) from swinput was ‘written’ to the console. Uh oh. Bad!

So, I will now with a new computer (with more than the 500MB of RAM I have on this) test Xnee in a sandbox, probably using qemu for both x86 and ppc. Doing this I should be able to:

  • Run every test case and report using the new coverage stuff in gnulib. All tests and builds can be done in x86 as well as ppc.
  • Verify that cross compilation to ppc works

Can’t wait….. but I have to.

kvm + qemu woos

Having run some basic tests of the upcoming release of swinput. I took the time to write some more test scripts, doing:

  • insert / remove the modules
  • fake key press/releases (write to file and compare with expected)
  • fake motion (mouse)

Worked fine…. so to some extent swinput was proven to work. Moving test/exec of kernel code to kvm + qemu would be a good idea. Decided to do so, but then swmouse stopped working, the faked motion didn’t get up to any device. Strange. The  swkeybd work fine though. So I guess it’s gonna be some Linux input/mouse reading today.