Using pystromo-mon.py for Intrepid

I think your problem lies in the fact that you shouldn't have to launch pystromo-remap using sudo. If everything is set up as expected, you should be able to run it as your normal user.

It looks like your /dev/input/uinput node doesn't have the correct permissions, or perhaps your user doesn't. Do you have the /etc/udev/rules.d/52-pystromo-debian.rules file in place?
Also, could you supply the output of `ls -l /dev/input/uinput` and `groups` for your normal user please?

The rules file is in place.

Here is the output:

barronmb@Marcy-X:~$ ls -l /dev/input/uinput
crw-rw---- 1 root root 10, 223 2009-01-11 11:00 /dev/input/uinput

barronmb@Marcy-X:~$ groups
barronmb adm dialout cdrom plugdev users lpadmin admin sambashare

In that case it looks like you haven't got the 52-pystromo-debian.rules file in the right place, or perhaps not with the correct permissions (mine is: rw-r-r, root/root).
If I remember correctly, under Intrepid the .rules file may have to go in a slightly different place to Hardy and earlier. The place it should be is certainly in the /etc/udev/rules.d/ hierarchy though. I think there's a sub-directory called "third-party" or such?

I checked the rules.d file and there are no additional file folders contained in rules.d. I will look into that more when I get home this evening.

My mistake, I was thinking about HAL .fdi policy files. Which likely aren't anything to do with your current problem.
Nevertheless, it does appear to be your .rules file which isn't being picked up for whatever reason. I can still only think at the moment that it may be in the wrong place or have the wrong permissions.

Hmm it's possible that the 52-pystromo-debian.rules file has the wrong permissions. Pretty sure that I copied it over w/o changing its permissions. What do the permissions need to be set for on the file?

Here is some output for you. Looks like the permissions are correct... They are the same as every other rules file.

barronmb@Marcy-X:~$ ls -l /etc/udev/rules.d/52-pystromo-debian.rules
-rw-r--r-- 1 root root 97 2009-01-11 11:01 /etc/udev/rules.d/52-pystromo-debian.rules

Hmph. Well the group isn't being set on the uinput node for some reason.
In case something else is affecting or overriding the 52-pystromo-debian.rules file, could you post the output of a `grep -i "uinput" /etc/udev/rules.d/*`?

Other than that, I'm all out of ideas for the moment. :(

Here's the output.

barronmb@Marcy-X:~$ grep -i "uinput" /etc/udev/rules.d/*
/etc/udev/rules.d/20-names.rules:KERNEL=="uinput", NAME="input/%k"
/etc/udev/rules.d/52-pystromo-debian.rules:KERNEL=="uinput", MODE="660", GROUP="plugdev"

What about the permissions for all the other nodes in /dev/input/ - do they get given the same permissions as /dev/input/uinput, or is udev managing to set those ones properly?
I'm also interested to know if there's a difference between their permissions on a fresh reboot, and after those devices are plugged in to a running system.

While I've just been doing some more testing, I've been reminded that pystromo-mon, by default, only looks at the current user's processes. So if you run it as root (with sudo), you'll have to supply to it the -a (--all-users) option before it'll look at processes run by anyone other than root.
That should make it more convenient for you to use pystromo, even if it doesn't help on the permissions front.

I didn't get a chance to get those outputs for you yesterday... I will get them for you this evening when I get home.
I have been using the utility by forcing the map each time as opposed to using monitor. I simply created a terminal launcher with the command:

sudo ~/.config/pyrstomo/pystromo-remap.py -m ~/.config/pystromo/default.map

This works out... Just launch it, input password, and close the terminal window. I would still like to get the monitor working and would like to avoid using root permissions to do it. Hopefully we can figure this out. Thanks.

Here is the output for all of input:

barronmb@Marcy-X:~$ ls -l /dev/input
total 0
drwxr-xr-x 2 root root 160 2009-01-26 21:02 by-id
drwxr-xr-x 2 root root 220 2009-01-26 21:02 by-path
crw-rw---- 1 root plugdev 13, 64 2009-01-26 21:02 event0
crw-rw---- 1 root plugdev 13, 65 2009-01-26 21:02 event1
crw-rw---- 1 root plugdev 13, 66 2009-01-26 21:02 event2
crw-rw---- 1 root plugdev 13, 67 2009-01-26 21:02 event3
crw-rw---- 1 root plugdev 13, 68 2009-01-26 21:02 event4
crw-rw---- 1 root plugdev 13, 69 2009-01-26 21:02 event5
crw-rw---- 1 root plugdev 13, 70 2009-01-26 21:02 event6
crw-rw---- 1 root plugdev 13, 71 2009-01-26 21:02 event7
crw-rw---- 1 root plugdev 13, 72 2009-01-26 21:02 event8
crw-rw---- 1 root plugdev 13, 73 2009-01-26 21:04 event9
crw-rw---- 1 root root 13, 63 2009-01-26 16:02 mice
crw-rw---- 1 root root 13, 32 2009-01-26 16:02 mouse0
crw-rw---- 1 root root 13, 33 2009-01-26 16:02 mouse1
crw-rw---- 1 root root 13, 34 2009-01-26 16:02 mouse2
crw-rw---- 1 root root 13, 35 2009-01-26 16:02 mouse3
crw-rw---- 1 root root 13, 36 2009-01-26 21:04 mouse4
crw-rw---- 1 root plugdev 10, 223 2009-01-26 21:02 uinput

I'm beginning to wonder if this has something to do with the fact that I'm running 64bit (it shouldn't).

So everything has the correct permissions, and your user is in the correct group, yet it doesn't work. :(
Couple of other things which might glean a little more info:
`fuser -av /dev/input/uinput`
`getfacl /dev/input/uinput`

And I suspect you're right about 64bit not being an issue in this case.

Here is the output requested:

barronmb@Marcy-X:~$ fuser -av /dev/input/uinput
                     USER PID ACCESS COMMAND
/dev/input/uinput:
barronmb@Marcy-X:~$ getfacl /dev/input/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/input/uinput
# owner: root
# group: plugdev
user::rw-
group::rw-
other::---

Passed I'm at the same stage as you
sae@saelianli:/etc/udev/rules.d$ fuser -av /dev/input/uinput
                     USER PID ACCESS COMMAND
/dev/input/uinput:
sae@saelianli:/etc/udev/rules.d$ getfacl /dev/input/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/input/uinput
# owner: root
# group: plugdev
user::rw-
group::rw-
other::---

I'm also running 64bit Intrepid, I took my N52 to work today on my 32bit station same build etc, not an issue, worked a a treat!
Not want you want to hear but I'm getting the same!!

sae@saelianli:~/.config/pystromo$ ./pystromo-remap.py -m default.map
Traceback (most recent call last):
  File "./pystromo-remap.py", line 170, in <module>
    inputs = getInputs(keymap, output)
  File "./pystromo-remap.py", line 98, in getInputs
    dev = devices.InputDevice(id=device, keymap=keymap, output=output, **params)
  File "/home/sae/.config/pystromo/lib/devices.py", line 99, in __init__
    node.grab()
  File "/home/sae/.config/pystromo/lib/ioctl.py", line 211, in grab
    fcntl.ioctl(self.fd, const.EVIOCGRAB, grab)
IOError: [Errno 16] Device or resource busy
sae@saelianli:~/.config/pystromo$

Hmmmm Question. Does Pystromo utilize any symlinks on the backend? i.e. does it point out to any lib32 type files (which may be regular lib files for 32bit systems). I have run into this before on a few other 32bit apps...They try to hit a lib file that is symlinked to a file that doesn't exist (b/c lib is our standard for 64bit and lib32 is our 32bit lib repository... Most of those are linked to their 64bit cousins in the lib directory). The solution is to simply find the symlink and download the file being pointed to. Perhaps there is something similar going on here.

If Mingerz is having no troubles on 32bit, and having the same trouble as I on 64bit, then it stands to reason that there is some kind of inherent difference between 32 and 64. Most likely some kind of issue where a rule file or policy file is not where the application expects it to be. Or 64 isn't overriding a rule/policy file through use of its own. (i.e. the case of lib32 vs lib and symblinks).

quick splurge from dmesg if it helps

[ 483.288338] input: Honey Bee Nostromo SpeedPad2 as /devices/pci0000:00/0000:00:1d.7/usb7/7-2/7-2.3/7-2.3:1.0/input/input10
[ 483.338290] input,hidraw3: USB HID v1.10 Keyboard [Honey Bee Nostromo SpeedPad2 ] on usb-0000:00:1d.7-2.3
[ 483.341463] input: Honey Bee Nostromo SpeedPad2 as /devices/pci0000:00/0000:00:1d.7/usb7/7-2/7-2.3/7-2.3:1.1/input/input11
[ 483.384095] input,hidraw4: USB HID v1.10 Mouse [Honey Bee Nostromo SpeedPad2 ] on usb-0000:00:1d.7-2.3
[ 486.815391] input: Pystromo Input Remapper as /devices/virtual/input/input12
[ 489.437974] input: Pystromo Input Remapper as /devices/virtual/input/input13
[ 490.939566] input: Pystromo Input Remapper as /devices/virtual/input/input14
[ 492.437980] input: Pystromo Input Remapper as /devices/virtual/input/input15
[ 542.396510] input: Pystromo Input Remapper as /devices/virtual/input/input16
[ 557.908213] input: Pystromo Input Remapper as /devices/virtual/input/input17
[ 565.619561] input: Pystromo Input Remapper as /devices/virtual/input/input18
[ 663.512081] input: Pystromo Input Remapper as /devices/virtual/input/input19
[ 731.510608] input: Pystromo Input Remapper as /devices/virtual/input/input20
[ 960.495521] input: Pystromo Input Remapper as /devices/virtual/input/input21
[ 1374.152061] input: Pystromo Input Remapper as /devices/virtual/input/input22
[ 7419.878169] input: Pystromo Input Remapper as /devices/virtual/input/input23
[ 7427.910425] input: Pystromo Input Remapper as /devices/virtual/input/input24
[ 9973.371170] input: Pystromo Input Remapper as /devices/virtual/input/input25
[10117.203236] input: Pystromo Input Remapper as /devices/virtual/input/input26
[11085.304013] usb 1-1: new full speed USB device using uhci_hcd and address 11
[11100.416022] usb 1-1: device descriptor read/64, error -110
[11115.632014] usb 1-1: device descriptor read/64, error -110
[11115.848011] usb 1-1: new full speed USB device using uhci_hcd and address 12
[11130.960043] usb 1-1: device descriptor read/64, error -110
[11146.176015] usb 1-1: device descriptor read/64, error -110
[11146.392016] usb 1-1: new full speed USB device using uhci_hcd and address 13
[11156.800014] usb 1-1: device not accepting address 13, error -110
[11156.912017] usb 1-1: new full speed USB device using uhci_hcd and address 14
[11167.320015] usb 1-1: device not accepting address 14, error -110
[11167.320193] hub 1-0:1.0: unable to enumerate USB device on port 1
[11570.091249] usb 7-2.3: USB disconnect, address 7
[12224.413181] input: Pystromo Input Remapper as /devices/virtual/input/input27
[12320.064023] usb 1-1: new full speed USB device using uhci_hcd and address 15
[12335.176028] usb 1-1: device descriptor read/64, error -110
[12350.392014] usb 1-1: device descriptor read/64, error -110
[12350.608012] usb 1-1: new full speed USB device using uhci_hcd and address 16
[12365.720018] usb 1-1: device descriptor read/64, error -110
[12380.936018] usb 1-1: device descriptor read/64, error -110
[12381.152016] usb 1-1: new full speed USB device using uhci_hcd and address 17

dang, I've just managed to replicate this on a 32bit ubuntu intrepid system.
I saw another article about xorg grabbing the device is that possible?

Trying to think of possible differences 32 and 64bit system are 'high end' nvidia whereas working system at the office is 'simple' quadro.
Passed what's your setup? Any clues?

I'm onto my 4th system now, Intrepid Ibex 32 bit laptop lets see what that says!

Mingerz, Is that output w/o using sudo... or with? If w/o I think it somewhat confirms my theory... some kind of rule isn't expressing permission outside of root... so the device isn't accepting the commands.

Wait, so what is it that we're discussing now?
On the 12th, the problem apparently was that uinput wasn't being assigned to the correct group. But the output Passed provided on the 28th indicates the group was being set correctly. That should mean that the "no uinput device-nodes found" problem is solved. Is it? Is the problem now the one mingerz is quoting; "device or resource busy"? :?

Ok laptop test has thrown up some useful stuff.
Same problem occurs BUT if you CTRL-ALT-F1 log into a terminal and run same code, hey presto it works.
I've got back to faulted 32 bit system and sure enuf outside X it works fine.
Went back to faulted 32bit system same holds true there.
Unfortunately for some reason my 64bit system refuses to go to terminal (something to do with my triple head adapter I think)
Passed any chance you can try it in term, it might at least be a temporary work around.

Sorry Raumkraut, that might be my fault, I might be crossing wires here, I'll back off if that helps, hopefully some of my stuff might be helpful in diagnostics!.