Keyboard/game-control modes

[Binky]

In a device like the pandora, there are more logical input devices needed than physical ones.

Pandora software uses keyboard, media controls, game controls and pointer/mouse button control.

The current system is rather messy for anything other than the default setup.

For example, to get the face buttons set up in a way I like, openbox autoruns ABMouse.pnd whenever I log in, which then uses a custom xmodmap file to set them to right, middle, left, enter. Then some pnds insist that PgUp/PgDown/Home/End are used for controls (making some games unplayable) and then I have to change everything back again manually,. Some apps check the buttons at a lower level (like PNDManager), so they register two events, a button press and a mouse click.

Likewise, I have my nubs setup as mouse and scroll. Some pnds will set/reset these as required. Some won't.

I suggest that there should be a unified interface where the user can remap (keyboard, nubs, buttons) to (gamepad, keyboard, mouse) by pressing a keyboard shortcut (Ctrl-Pyra-number perhaps?)

Then I could have custom mappings on controls-to-joystick, custom mappings of controls-to-mouse, etc, and user-facing software wouldn't have to know or care about it.

If one game needed a joystick, but the desktop needed a mouse I would be able to change easily between them as needed, and would have full control over the process.

Unfortunately, I have no idea how to implement such a system, but I do think its an issue worth consideration.

Normally, I'd make a comment saying that this was a software issue that could be implemented on the pandora if someone started a thread like this one, but since the Pyra will have a different distro, and (I imagine) rather different nub controllers, I though it might make sense to put this in Pyra Development.

 

[LEOXD]

Hm. So, the basic issue is that applications sometimes ask for key codes and sometimes for key labels (or whatever they're called). 

Advantages of using keycodes are that they are layout-independent. Disadvantages are that you cannot switch the controls (e.g. changing in-game controls from abxy to bayx)

Advantages of using key labels are that they are easier (=more obvious) to code, and that you can switch them (xmodmap). Disadvantages are, well, that you may have to change your configuration to do so (see also: the WASD-problem on AZERTY-keyboards or the ShiftZXC-problem on both AZERTY and QWERTZ). 

I'd say that using keycodes is better. However, it's hard to get all package maintainers of debian to agree on that. I bet not even this forum will agree on that. That said, trying to unify something here will most likely not work. 

Generally, xmodmap is a bad solution for these things, because it does it the hard way and you have to turn it on and off, like, all the time if you switch between applications. Of course, you could have a bash script that changes the keyboard back to default when called (e.g. by Ctrl+Pyra), and sets it to the custom settings if you call it again, but I think this makes it more complicated than necessary. 

A better solution would be a switching application that uses the X Keyboard Extension (XKB). These can have differents layouts for different windows, and they use shortcuts to change the layout (usually Alt-Shift or Super-Space), and they just go through the list of the layouts in a similar way as Alt-Tab goes through windows. Well, at least the one Gnome uses does. 

However, here comes the issue using XKB:

1. There is AFAIK no easy way (preferably with GUI) to write a new layout or edit an existing one.
2. If you have 30 applications that all want different layouts, the list you'll Super-Space through will be long. Having a setting that automatically sets certain layouts to certain applications when they are started would be great. AFAIK there is no easy way to do that, either. 

XKB can most probably handle all of the things blinky mentioned. Except the mouse/joystick-switching. I have no idea what to use here. Do you pandora-using people have one?

 

[aTc]

basically , http://boards.openpandora.org/topic/15587-userspace-input-daemon

 

[levi]

Yes, that sounds like what we want.


I gave up using ABMouse because of having to switch it on and off all the time, and even though my right nub isn't very dependable at ever being able to double-click when wanted, it's still preferable to that faff. I suppose good use of the PND-pre and post scripts would help here, but the current user tools for managing those always felt a little too hacky too.


Out of interest, where would we put Pgup/Home/Dn/End if we used some of those buttons for mouse buttons? On the r-stick?

 

[aTc]

well, with a configurable input daemon, you could put it wherever you want. It would have to come with some sensible defaults of course, but if you don't like those you can map keys/buttons to whatever you want, and save us all a lot of forum fights/polls.

Switching to different profiles based on the launced pnd/pyr ID wouldn't be a problem either, biggest issue is writing the daemon and a proper configuration gui.

 

[sebt3]

I bet you'll code it this time... (or maybe you'll whine as usual )

 

[notaz]

There is event duplication issue with the daemon though, as it's not going to suppress original events. For example plain X programs (and SDL, if it's not hacked) will see both keyboard and matching virtual gamepad (or whatever from the daemon) keys pressed at the same time and may cause double actions or get confused in general.

Another disadvantage is custom distros will have to install the daemon if they want some things to work.

 

[aTc]

in the jayfoxrox stuff he added a hal rule to stop the /dev/input for the device beeing created.

I haven't managed to find that succesfully manages to do the same with something more modern, since hal is obsolete now.

I did try a few udev rules on a .next image, but that didn't really seem to work.

I think a few other input type daemons just open the device exclusively to stop xorg/anything else from accessing it, forcing it to use the uinput created devices.

It's still a slightly better solution than the mess that we have on pandora now, and far more flexible.


<?xml version="1.0" encoding="UTF-8"?>
<!-- This file should be in /usr/share/hal/fdi/preprobe/20thirdparty/ for prototypes and BeagleBoard! -->
<deviceinfo version="0.2">
<!-- Block original Pandora hardware -->
<device><match key="info.product" string="cx88 ir"><merge key="info.ignore" type="bool">true</merge></match></device>
<device><match key="info.product" string="cx88 ir"><merge key="info.ignore" type="bool">true</merge></match></device>
<device><match key="info.product" string="cx88 ir"><merge key="info.ignore" type="bool">true</merge></match></device>
<device><match key="info.product" string="cx88 ir"><merge key="info.ignore" type="bool">true</merge></match></device>
<device><match key="info.product" string="cx88 ir"><merge key="info.ignore" type="bool">true</merge></match></device>
<!-- Block creation of joysticks for analog nubs -->
<device><match key="info.product" string="vsense66"><merge key="info.ignore" type="bool">true</merge></match></device>
<device><match key="info.product" string="vsense67"><merge key="info.ignore" type="bool">true</merge></match></device>
</deviceinfo>

And me whining about things is all you get at the moment, unless I get some serious help with things. It's far too much work to have to do everything myself.