f-log

I have a Wacom Bamboo tablet and pen from 7+ years ago. To be fair, I had forgotten I had it. It did get a lot of use originally and I got it working in Linux with GIMP and Blender very cool.

Rebuilding the kernel the other day I made the effort to update my notes for making the tablet work.


[*]Device Drivers - HID Support - Special HID Drivers - Wacom Intuos/Graphire tablet support (USB)
[*]Device Drivers - Input device support - Tablets - Wacom protocol 4 serial tablet support


and once the new kernel was in place just reinstall the drivers.

emerge -av xf86-input-wacom

It worked straight away and I loaded up GIMP Sketched out some rubbish, noting the pressure changing stroke and then the machine stopped responding ...
Completely hung. Not even the CAPS LOCK button would change the keyboard LED.

I did not associate the two events. Drawing with the pen and the machine hanging, cos, why would you?

Then I tried the same thing and it happened again! About two minutes after I started drawing the machine hung, could not even ssh into it.

Now I am worried, Wacoms have worked well with Linux for many many years, so what have I done wrong?

Third time something different happened. The pen would not work even though
xsetwacom --list devices

Wacom Bamboo Pen Pen stylus         id: 10    type: STYLUS    
Wacom Bamboo Pen Pen eraser         id: 12    type: ERASER    

Showed the tablet and pen were detected. I tried unplugging and re-plugging and it worked. Tentatively I opened up GIMP and started sketching ...
1 minute still working
2 minutes not hung
5 minutes no problem
10 minutes I can not see any reason why this is working !! (I prefer consistent failure to inconsistent successes)

So I open up Blender and ... I get weird screen corruption, like raw memory dumps, everything still works and occasionally the screen fixed itself but not for long. When I say "screen" it was in fact only portions of the screen as defined by Blender views(not just 3D ones). But Blender is not reporting any problems and the problems only fix/break when I use the mouse.

I have seen something similar when trying to trans-code large video files but that was with switching VTs not moving the mouse.

Time to investigate.

First stop forums.gentoo.org, seemed Gentoo related but, no one with my sort of problem. A bit Googling led from the Xorg.0.log file

[ 1686.785] (EE) BUG: triggered 'if (in_input_thread())'
[ 1686.785] (EE) BUG: /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/os/io.c:656 in WriteToClient()
[ 1686.785] (EE) ******** WriteToClient called from input thread *********
[ 1686.785] (EE)
[ 1686.785] (EE) Backtrace:
[ 1686.785] (EE) 0: /usr/bin/X (xorg_backtrace+0x4e) [0x59160e]
[ 1686.785] (EE) 1: /usr/bin/X (WriteToClient+0x17b) [0x594c6b]
[ 1686.785] (EE) 2: /usr/bin/X (WriteEventsToClient+0x202) [0x4416b2]
[ 1686.785] (EE) 3: /usr/bin/X (TryClientEvents+0x132) [0x4418b2]
[ 1686.785] (EE) 4: /usr/bin/X (0x400000+0x45295) [0x445295]
[ 1686.785] (EE) 5: /usr/bin/X (DeliverEventsToWindow+0x21e) [0x4455ce]
[ 1686.785] (EE) 6: /usr/bin/X (0x400000+0x120251) [0x520251]
[ 1686.785] (EE) 7: /usr/bin/X (0x400000+0x12accc) [0x52accc]
[ 1686.785] (EE) 8: /usr/bin/X (XIChangeDeviceProperty+0x2ad) [0x52b64d]
[ 1686.785] (EE) 9: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7f4c320b1000+0xe592) [0x7f4c320bf592]
[ 1686.785] (EE) 10: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7f4c320b1000+0x6c6f) [0x7f4c320b7c6f]
[ 1686.785] (EE) 11: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7f4c320b1000+0x74c4) [0x7f4c320b84c4]
[ 1686.785] (EE) 12: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7f4c320b1000+0xbd97) [0x7f4c320bcd97]
[ 1686.785] (EE) 13: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7f4c320b1000+0x5e71) [0x7f4c320b6e71]
[ 1686.785] (EE) 14: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7f4c320b1000+0x5f0a) [0x7f4c320b6f0a]
[ 1686.785] (EE) 15: /usr/bin/X (0x400000+0x1937dc) [0x5937dc]
[ 1686.785] (EE) 16: /usr/bin/X (0x400000+0x195e49) [0x595e49]
[ 1686.785] (EE) 17: /usr/bin/X (0x400000+0x193626) [0x593626]
[ 1686.785] (EE) 18: /lib64/libpthread.so.0 (0x7f4c3eceb000+0x7466) [0x7f4c3ecf2466]
[ 1686.785] (EE) 19: /lib64/libc.so.6 (clone+0x6d) [0x7f4c3ea3b71d]


to

http://debian.2.n7.nabble.com/Bug-862639-xserver-xorg-input-wacom-polluting-my-syslog-update-to-0-35-td4117009.html
https://sourceforge.net/p/linuxwacom/bugs/333/
https://sourceforge.net/p/linuxwacom/bugs/328/
https://github.com/linuxwacom/xf86-input-wacom/issues/8

which indicate a serious bug exists where xf86WaitForInput function used to take a timeout in microseconds, and now the value is milliseconds. Or the other way around, either way it's a timing issue.

Bottom line, better off unplugging the Wacom and waiting for this to blow over.

Alex had a small piece of homework to do, "Phases of the moon". But he wanted to get some extra merits (an unusual request for him) and thought he might do a video.

So we set up a tripod in the bathroom and he stood in the bath. This gave us the interesting and stationary background to add to.

After 8 takes we had a short film he was happy with and we moved over to post production. Blender has a built-in video editor and obviously he wanted a 3D rendered moon. So a quick download of a Moon texture and a couple of spheres later we had the Sun and Moon.

He created a Bezier Circle as a track for the Sun and added the constraint. With lamp inside the Sun, we could easily animate the light on the Moon. Added the video file to Blender s video editor and then a scene, set the mode to Alpha Over and Transparent and now the 3D objects appeared in the video!

He then took some time making the start and end animation points sync up with his words, we started to run out of time here so it gets a little ropy.

Finally he added all the fun credits by just copying and pasting the text he had typed earlier into a text object and animated that moving from the bottom to the top of the screen.

After he had gone to bed I edited in the outtakes with a Transform effect to shrink them and move them to the right.



Turned out the teacher did like the effort. Double merits and the further homework of explaining it to whole school after it went a bit viral(locally).

Many MANY moons ago I had a Dreamcast and I wrote a number of little utilities and games for it. These included the infamous Space Invaders VMU style which got copied and downloaded many 10 of thousands of times.

I also created a tiny C program that converted JPG images into the file format to be used in game called Jet Set Radio (Jet Grind Radio). This I used and had fun with but I never thought anyone else had ever downloaded it.
http://www.jumpstation.co.uk/dreamcast/ii2d.html
16 years later I get an email asking for an upgrade to the binary I distribute to work with 64bit windows!

My first thought was, the source code is included build it yourself, but I wondered how hard it would be to do. I would need to find a windows machine...

Or not, https://prognotes.net/2015/04/compile-c-programs-for-windows-and-linux/ includes instructions to cross compile from Linux to Windows. This boiled down to


sudo apt-get install mingw-w64

i686-w64-mingw32-gcc -o ii2d32-64bit.exe ii2d.c

x86_64-w64-mingw32-gcc -o ii2d64bit.exe ii2d.c

that was it, really nothing else, job done.

So now the executable are available at the bottom of the same page which embarrassingly contains some of the worst spelling and grammar ever, enjoy!
http://www.jumpstation.co.uk/dreamcast/ii2d.html

What is keeping me from my Hi-res Pi blender rendering? Many things, including Joe's Robot Challenge.

One component of Joe's Robot Challenge is a button and for effect my Panic Button is a good fit.


Previously I compiled a kernel module to get it working, this time it made sense to search out a Python script.
I found http://www.righto.com/2010/04/usb-panic-button-with-linux-and-python.html which is a little dated but the only offer.

I copied the script to the Pi and ran it.

pi@raspberrypi:~/button_test $ sudo python PanicButton.py
Traceback (most recent call last):
File "PanicButton.py", line 10, in <module>
    import usb.core
ImportError: No module named core

Then I tried to install the PyUSB library. But could not find the "pyusb" but could find "python-usb" that installed but still got the same error. Even the PyUSB creator suggests you use that package as it is "up to date".

Sadly it is not "up to date" on the Raspberry Pi Jessie latest version. I also tried install it via "pip"

pi@raspberrypi:~/button_test $ sudo pip install pyusb
Requirement already satisfied (use --upgrade to upgrade): pyusb in /usr/lib/python2.7/dist-packages

But it says it is already installed :(

The instructions required uninstalling the current library, but that did not go well

pi@raspberrypi:~/button_test $ sudo pip uninstall pyusb
Not uninstalling pyusb at /usr/lib/python2.7/dist-packages, owned by OS

Still I was able to download the latest version 1.0.0-a1 from https://github.com/walac/pyusb

Then
tar xzvf pyusb-1.0.0-a1.tar.gz
cd pyusb-1.0.0-a1/
sudo python setup.py install
sudo python3 setup.py install

pi@raspberrypi:~/button_test $ sudo python3 PanicButton.py
File "PanicButton.py", line 21
    except Exception, e:
                    ^
SyntaxError: invalid syntax

Drat! It still does not work. Maybe I should try old Python.

pi@raspberrypi:~/button_test $ sudo python PanicButton.py
Traceback (most recent call last):
File "PanicButton.py", line 33, in <module>
    button = PanicButton()
File "PanicButton.py", line 17, in __init__
    raise ValueError("Panic Button not found")
ValueError: Panic Button not found

Double drat! Oh! Hang on. What is that last line? "Panic Button not found". I had not plugged the button in and it had detected it missing !!

pi@raspberrypi:~/button_test $ sudo python PanicButton.py
Pressed
Pressed
Pressed

Every time I pressed the button (or more accurately, released the button) "Pressed" was displayed.

So it works but not with Python3, annoying because we are using Python3 for everything else.

I could have written a new file but instead I just ran Python3 and copied and pasted the relevant lines.

pi@raspberrypi:~/button_test $ sudo python3
Python 3.4.2 (default, Oct 19 2014, 13:31:11)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import usb.core
>>> dev = usb.core.find(idVendor=0x1130, idProduct=0x0202)
>>> dev
<usb.core.Device object at 0xb67c5b70>
>>> dev.detach_kernel_driver(0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.4/dist-packages/usb/core.py", line 695, in detach_kernel_driver
    self._ctx.backend.detach_kernel_driver(self._ctx.handle, interface)
File "/usr/local/lib/python3.4/dist-packages/usb/_debug.py", line 52, in do_trace
    return f(*args, **named_args)
File "/usr/local/lib/python3.4/dist-packages/usb/backend/libusb10.py", line 565, in detach_kernel_driver
    _check(_lib.libusb_detach_kernel_driver(dev_handle, intf))
File "/usr/local/lib/python3.4/dist-packages/usb/backend/libusb10.py", line 357, in _check
    raise USBError(_str_error[retval.value])
usb.core.USBError: Entity not found
>>> dev.ctrl_transfer(bmRequestType=0xA1, bRequest=1, wValue=0x300, data_or_wLength=8, timeout=500)[0]
0
>>> dev.ctrl_transfer(bmRequestType=0xA1, bRequest=1, wValue=0x300, data_or_wLength=8, timeout=500)[0]
1
>>>

Ha ha! That zero was when I had not touched the button and unsurprisingly 1 is when I had pressed (and released) the button.

The error is simply the button already not being attached to the default kernel HID driver.

This is a NodeJS program I created for testing out how the bcrypt module worked for hashing and comparing passwords
// NodeJS console app using the bcrypt module
const bcrypt = require('bcrypt');
console.log('Bcrypt node module example');
console.log('==========================');

var password='default';
var hash;
var workload=12;
if (process.argv.length>=4) {
password=process.argv[2];
workload=parseInt(process.argv[3], 10);
console.log('Input parameters');
console.log('================');
console.log('Password:'+password);
console.log('Workload:'+workload);
if (process.argv.length==5) {
    hash=process.argv[4];
    console.log('Hash:'+hash);
}
} else {
console.log('Usage');
console.log('[password] [workload] (hash)' + process.argv.length);
return;
}

bcrypt.hash(password, workload, function(err, hash) {
console.log('================');
console.log('New hash:' + hash);
if (err) console.log('Hash generation error:' + err);
});

if (hash) {
bcrypt.compare(password, hash, function(err, res) {
    if(res) {
     console.log('Password matched');
    } else {
     console.log('No match');
    }
    if (err) console.log('Compare error:' + err);
});
}


It takes a Password a Workload and an optional Hash. The Password is the plain text for hashing and the Workload represents the weight the algorithm must use to create the hash. Once you have run it with a fresh password then you can use the generated hash in future runs.

If you set the Workload too high then your machine will hang doing the work. 10-12 seem ideal.

What you might be missing in this example is a Salt. Bcrypt takes care of this by including a cryptographically strong Salt in the resultant Hash. Why would you store the Salt with the Hash? It is what you would do in a database record anyway and avoids any weak "security by obscurity" solutions.

Bcrypt also stores the Workload in the Hash. Meaning you can create hashes today with workload = n then in ten years you can by using workload = n+c for new hashes and still be able to compare the original hash.

This is all far better than creating a SHA512 hash of a password then generating a random value as a salt storing it in a database. Then recreating the hash when a password is tried and the comparing the resultant hashes. Because bcrypt uses a variable workload value any cracker must build a rainbow table for each hash deal with the computational impact of the workload per computed hash.

Very clever stuff, so just need to wait until some math proof breaks in all ;)