6 mar 2010
#what is ois? i quote [1]:
Object Oriented Input System (OIS) is meant to be a cross platform, simple solution for using all kinds of Input Devices (KeyBoards, Mice, Joysticks, etc) and feedback devices (e.g. forcefeedback). Written in C++ using Object Oriented Design patterns
i’ve finally found out why ois [1] does not work with my linux system. see this:
ls -la /dev/input
crw-r----- 1 root root 13, 73 Feb 28 12:46 event9
crw-r--r-- 1 root root 13, 0 Feb 28 12:46 js0
as most linux users will instantly see: js0 can be read but not be written to. so is this bad? or does this degrade useage? probably it is not bad since a user might only have to write to a jsX device if it is a ‘force feedback’ supporting device. but for only reading from the device it should be useable as expected. but the joystick/gamepad did not work with OIS at all, so i wondered why and i started to look at the code of OIS. i found a ReadMe.txt file with an obsolete autotools toggle - guess what - i hate autotools.
anyway, the ReadMe.txt states:
./configure --disable-joyevents --- Uses /dev/input/jsX instead of /dev/input/eventX
so i tried –disable-joyevents but it seems that this option is not used anymore because ./configure complains with:
configure: WARNING: unrecognized options: --disable-joyevents
however, this made me think: what is that event9 device when plugging in the gamepad (still the ps3 controller). it is yet another interface to access the gamepad. so one can either use js0 or event9 (on my system, since the names are autogenerated by the system).
after changing the permissions of event9 (as root) with:
chmod 0777 /dev/input/event9
and trying the ois demo again it worked! no wonder but took me at least about 1h to find out. so why don’t they try to open the js0 device? why don’t they complain about permission issues? at least the console demo application could do that (it can’t since the input opening and handling is in the linux part of the library anyway) but what about some lines like:
event1: can't open device for reading
event2: can't open device for reading
...
event9: can't open device for reading
this would be very handy for debugging the situation. or seen from a different point of view, is this a gentoo issue? is this a udev issue? why does that device not have read permissions per default? maybe for securty? how knows…
thanks to [3] i found this handy udevadm command:
udevadm info -a -p $(udevadm info -q path -n /dev/input/js0)
this can be combined to what i’ve written about udev already at [4]. in short (looking at the output of the above command we search for these two parameters):
ATTRS{idVendor}==“054c”
ATTRS{idProduct}==“0268”
these two parameters will do the work. so the new udev rule looks like this:
# cat /etc/udev/rules.d/99-myrules.rules
KERNEL=="event[0-9]*", SYSFS{idVendor}=="054c", SYSFS{idProduct}=="0268", MODE="0666", GROUP="games", SYMLINK+="eventPS3"
KERNEL=="js[0-9]*", MODE="0664'", GROUP="games"
WARNING: i named that file 11-myrules.rules with the result that the group was changed but never the mode so i wondered why. later i found out that there is some other rule which had overwritten the MODE but not the GROUP. (so i renamed it to 99-myrules.rules) WARNING: using 0666 makes the GROUP=“games” useless since every user can attache that device now, you might want to add your local user to the ‘games’ group and change MODE=“0660” instead
so after making changes to /etc/udev/rules.d one MUST NOT forget to do this:
udevadm trigger
this will reload the rules (and one of these rules we just changed). now replug your gamepad and see if the permissions were changed in /dev/input, probably with: ‘ls -la /dev/input’
debugging ois is not easy if the software isn’t installed correctly. that is the case with the linux package since they don’t install
this is again a complaint about package management…
ois is designed cross platform which is very good. ogre 3d can use ois and as far as i can tell the design of ois is sound. it does not detect my ps3 controller as a ‘force feedback’ device but i can live with that. what really bugs me is the fact that ois (same goes for libSDL) does not support device hotplugging - i’ve not tried on windows but i’m sure of linux and mac (since mac uses libSDL as backend currently).
every person who has once used a ps3 or a xbox knows how cool device hotplugging is!
there was a project for sdl to make device hot-plugging for linux work. however this was - if i recall correctly - not implemented into the library but instead the library was queried for a list of devices if the linux hardware abstraction layer (HAL) called a callback via dbus to notify of device changes. the new device was then opened as any normal joystick device using sdl.
what i want is different: i don’t want to use dbus in my application. and i don’t want to code like that. i just want to have a additional event which informs me about the state-change of currently opened joysticks (that is for instance js0 which is in use). right after it is unplugged my callback for new events (same goes if i poll the device every frame) i will receive the event that the device is now gone so i can close the device handler and the game could also react to it probably with a game pause or a screen showing: you don’t have any input device attached, can’t continue… please attache at least one device.
this way one could also switch from one player to two player mode or one could display a device manager dialog when plugging a second device… basically whatever you want to do.
device hotplugging is on the todo list for ‘sdl 1.3’. i wonder when that is released… (according to [2])