## Wacom Hacking

Recently, I acquired a rather old Wacom Intuos A5 tablet, for reasons I won’t delve into at the moment.

It’s an old serial model, and although I don’t have a serial port anymore, I do have a USB-to-serial adapter, which thought would probably work fine with the X.org driver produced by the linuxwacom project, since they do mention support for serial tablets on their website.

I plugged it in, followed the linuxwacom documentation about setting everything up in xorg.conf, and fired up the X server. Nothing happened… So I started digging in the wacom driver source.

### First Obstacle: Prolific PL2303 USB Serial Port

The first problem I encountered was with my USB-serial adaptor. Apparently, the wacom driver used a TCIOCGSERIAL ioctl, which is supposed to return information on a serial device, to determine if it’s talking to a serial or a USB device. If the ioctl fails, it thinks it’s not talking to a serial device, and starts talking USB HID to the tablet.

Unfortunately, the pl2303 driver in the linux kernel (as of version 2.6.32.8 that I tested) does not implement the aforementioned ioctl, even though it’s supposed to present a proper serial port to the system. So I had to hack the kernel, and add that ioctl in the pl2303 driver (patch against 2.6.32.8).

(edit: my pl2303 patch got included in linux 2.6.34, so you don’t need the patch any more)

Sadly however, although now the wacom driver realized that it was dealing with a serial device, the tablet still didn’t work…

### Second Obstacle: The linuxwacom Driver

After a lot of digging around the source of multiple wacom driver versions, it turns out the guys at the linuxwacom project removed the code for old serial tablets from the driver sometime last year!

I tried installing a few older versions of the driver (anything prior to 0.9.1 had the serial code), but they would not compile with the much newer X.org headers in my system. Apparently some changes with the XInput extension broke the old driver. So I started hacking again.

First I tried back-porting the XInput changes from the newer wacom driver to the old 0.8.4 version, but although I managed to compile it, it would segfault upon being loaded by the X server. Evidently I screwed something up during the backport, which I could have probably fixed eventually, but I realized that it’s a bad idea to get stuck to the old wacom driver.

So instead I started from scratch in the opposite direction, re-integrating the old serial code from 0.8.4 to the most recent 0.10.4 wacom driver.

### Success!

And indeed after a few hours of hacking, I managed to get my serial Wacom Intuos to work perfectly! Here’s the patch in case anyone needs it.

I must say it’s an impressive input device, pressure-sensitivity, tilt sensing, everything works perfectly. The only problem is that I still can’t draw any more than I could on paper :)

## Stereoscopic OpenGL part2

My obsession with stereoscopic rendering continues unabated. It’s just so fucking cool to write a bit of code and have 3D objects pop outside of your monitor and float above your keyboard.

Fact is, I couldn’t settle with my crummy anaglyph glasses see previous post. I had to try out proper shutter glasses and quad-buffer OpenGL visuals.

Thanks to nvidia’s policy of supporting quad-buffer visuals and stereo ports only on expensive Quadro graphics boards, and the proliferation of flat panels which are entirely unsuitable for use with shutter glasses due to ridiculously low refresh rates, I couldn’t do that with my PC. On the other hand, my trusty Silicon Graphics Octane2 workstation was more than up to the task as it comes with a stereo synchronization port and quad-buffered OpenGL support out of the box.

So off I go to ebay, where I bought the cheapest lcd shutter glasses I could find, the ASUS VR100 glasses which came once upon a time bundled with some expensive ASUS TNT2 graphics cards as a high-end gimmick.

Connecting these glasses to SGI workstations has been done before and it was a piece of cake to follow that guy’s schematic and construct the necessary circuit to translate the signals from the SGI stereo port to those required by the shutter glasses.

The only problem I’ve had, is that my Octane2 has the low-end V6 graphics option, which apparently doesn’t provide a z-buffer when using stereo visuals.

Now I didn’t feel like z-sorting all polygons like the good old days when z-buffering was too expensive to use on underpowered PCs while doing software polygon rendering, so I tried to figure out a couple of graphics hacks that I could do which wouldn’t require a z-buffer to look right. So I came up with this swirling tunnel, and a simple wireframe teapot.

## OpenGL stereoscopic anaglyphs and patents

An anaglyph is a combination of two images into one, in such a way that they can later be separated by viewing the image through appropriately colored transparent filters. The objective is to present slightly shifted views of the same 3D environment to each eye, in order to achieve depth perception (i.e. really perceive the 3rd dimension).

I’ve never dealt with anaglyphs in the past, but during my recent week-old obsession with stereoscopy, I’ve stumbled upon a pair of free anaglyph viewing glasses (made out of cardboard and cellophane of course). So I couldn’t help but try to find out how I can use them with my own programs.
Read the rest of this entry »

## Raytracing Anamorphic Images

A long time ago, I stumbled upon a couple of strikingly odd images on Jim Arvo’s web site, which are apparently called “anamorphic”. The idea behind an anamorphic image, is that it’s distorted in such a way, that its true shape can be seen only when viewed in a particular manner. In the case of these images, you’re supposed to print the image and place a highly reflective cylindrical object, such as a chrome pipe, at a specific marked location in order to see the geometric shapes correctly.

I kept the images back then, with the purpose of either finding an appropriate cylindrical object, or raytracing them to see what they look like, but for some reason I’ve forgotten all about them until I accidentally found them again yesterday, in a dusty corner of my filesystem.

So I decided to hack some code to add perfect ($x^2 + y^2 = r^2$) cylinder primitives to my raytracer and do a couple of renderings with those images texture-mapped onto a ground quad (I could just do the same thing with another raytracer such as pov-ray but where’s the fun in that?).

So anyway here are the anamorphic images along with the renderings (click on the images for the full rendering):

After the first successful test of my webcam marker tracking algorithm, it’s now time for the real deal.

The purpose of my experiment, is to be able to detect the position of my head in 3D space, by processing the webcam-captured frames, locating the 2 markers, and then performing an inverse projection from 2D space to 3D space. That information can be used to set the view-point of a 3D environment to follow the motions of the user’s head, thus increasing the user’s immersion in the 3D world considerably. Simple, natural motions of the user’s head, are carried along in the virtual world, making the screen act as a window into that 3D environment.

Of course the point tracking code from my previous test is the same. However, I modified my tracking program to accept local connections from client programs that need to use that tracking information ($x, y$ normalized position of each marker). Then I wrote a test program, that renders a simple OpenGL “world” (a bunch of balls and a couple of coordinate grids), and uses the marker positions from the other program, to calculate the user’s head 3D position, and set up the virtual camera to coincide with that.

Once again, you may watch the result at youtube. There’s still some way to go, and some details to be ironed out… I’ll keep you posted on anything new with this experiment :)

Oh, and of course, the code is always available at my subversion repository:

 webcam marker tracking program (server): svn://nuclear.dnsalias.com/pub/compvis/cam_test 3D environment test (client): svn://nuclear.dnsalias.com/pub/compvis/vr_test my webcam library (used by cam_test): svn://nuclear.dnsalias.com/pub/libwcam
Posted in hacks. 11 Comments »

Finally, after some weeks of putting it off, I manged to sit down and write some code to talk to video4linux2 drivers, in order to get streaming video from a webcam.

My motivation for messing around with webcams and v4l ioctls, was a little experiment of mine. I wanted to write a program, that given video input from a webcam, is able to detect two “markers” attached to my head. This in turn is but a step in a slightly larger experiment I’m conducting, which I’m not going to go into right now.

So what this program does, is to detect the two markers in the video stream, and draw a blue rectangle around each marker. Check out this youtube video for a demonstration of my test program. Be warned: it’s rather silly :)

Also, I wrote a nice little v4l webcam library as part of this experiment. The code is available, as usual, in my subversion repository: svn://nuclear.dnsalias.com/pub/libwcam. The test program is also available here: svn://nuclear.dnsalias.com/pub/compvis/cam_test

Posted in hacks. 4 Comments »

## Automatic Class Diagram Generation

Some time ago, I needed a widget toolkit that would be able to draw widgets in an existing OpenGL window. However, I also needed it to be independent of the underlying graphics library, or event system, so I could use it in conjunction to both OpenGL, and another nameless 3D graphics API, that I was forced to use at the time for reasons I won’t go into right now. Anyhow, to cut the long story short, I started writing one such toolkit from scratch.

I opted for a fully object-oriented design, such as I rarely do lately, because OOP really makes sense for widget toolkits, and used C++ for the implementation.

Before long, I wanted to show what I was doing, to the rest of the team working on the project, for which I was writing the toolkit. And decided I should visualize the class hierarchy, as a quick overview of the widgets and their relations.
Read the rest of this entry »

Posted in hacks. 3 Comments »