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

]]> http://sandklef.wordpress.com/2010/09/18/xswine-new-program-for-the-gnu-xnee-suite/feed/ 5 sandklef http://sandklef.wordpress.com/2010/05/24/preparing-gnu-xnee-3-06-and-testing-new-xi2-features/ http://sandklef.wordpress.com/2010/05/24/preparing-gnu-xnee-3-06-and-testing-new-xi2-features/#comments Mon, 24 May 2010 13:31:35 +0000 sandklef http://www.sandklef.com/hesa/?p=582 Continue reading →]]> 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 ( http://cvs.savannah.gnu.org/viewvc/xnee/?root=xnee&pathrev=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.

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?

Download 0.7.4 here:

http://savannah.nongnu.org/files/?group=swinput

… and thanks Jesse W for not haunting me for being late

• 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.

• 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.