userspace input daemon

[aTc]

Since this stuff is sort of important, I rescued a few bits from the other thread and put them here.

As anyone who ported an app that tries to use the pandora controls knows, it's all a bit of a pain to work with. (although using the patched SDL lib does hide a few of the problems).

The kernel driver that handled everything wasn't that nice either (creating/destroying input devices based on which mode was poked into them)

It can at least be done slightly more sensible this time, and have the gamepad bits show up as a single gamepad. A lot of programs have support for gamepads, but you couldn't use that on pandora because they don't expect gamepads to show up as something spread over two devices and half the keyboard.

But this is not how the hardware is connected (bunch of unrelated devices on different buses) and such driver has no chance to be ever mainlined. Nobody likes to sit on old kernels just because there's nobody to do the porting work. Unless we can do it in userspace this is not going to happen.

If any hacks need to be done, it'd better be one small userspace daemon, than having to patch half the OS. (Not everyone will want to run debian anyway)

But you do need some easy way of switching the daemon between generating mouse/keyboard events, and gamepad events.

You can't have it always do both , generating mouse events and nub movements at the same time , or fire buttons that also press keys at the same time for example will do weird stuff in a lot of games.

A clearly labeled keyboard button that makes the daemon switch between modes shouldn't be THAT hard to explain to users. Make it light up a led to indicate the mode, and everyone should be able to figure out what's going on and what to do when they move the nub and the mouse doesn't move. (you could do it in software with an applet, but you'd probably want to switch modes inside a fullscreen game sometimes, and having to go back to the desktop just to switch it around is even less user friendly)

One failed project for pandora was a daemon that took all those devices and made them show up as a single gamepad. So doing it in userspace is certainly a possibility.

Well, i've contacted JayFoxRox, and he still had the sources for it luckily.

Turns out it's far less of a hack than I thought, the linux kernel itself has a nice way of having userspace programs generate input events.

uinput allows a program to generate whatever input events the kernel supports (mouse,keyboard,joystick,touchscreens, etc.).

And with that, you can easily have a small daemon taking whatever the buttons/nubs appear as on the hardware side, and make it all appear to come from standard controls.

This way, programs will need no special modifications to work with the pyra controls.

This also has the advantage that it's more versatile and configurable than the pandora kernel drivers ever were.

 

[Linux-SWAT]

Isn't wiimote thing using uinput ?

 

[RuneIV]

How are things looking from the input standpoint?

uinput seems to be an interesting solution based on what I've read online. Are you guys still heading in that direction?

Edit: Just saw the other thread. http://boards.openpandora.org/topic/16443-keyboardgame-control-modes/