FunKeyMonkey

[bzar]

Pushed a fix for the hanging on device disconnect.

 

[bzar]

Ible, thanks for the contributions

If you want even less latency on your plugin you can remove the event printing. Though I have no doubt it's quite fast enough even with it

 

[notaz]

So I'm thinking if we should make FunKeyMonkey Pyra's input daemon. We could have it running at all times, with high scheduling priority to minimize input lag. It could take care of tasks like abstracting all kernel drivers into single input device, and in some future maybe allowing to control any Pyra program using USB/BT/network devices without having explicit program support and so on.

One of the tasks it could do is to handle all those nub modes, to relieve the kernel driver of this messy task and make the driver only do what it really has, that is to drive the hardware. That brings up the question how would FunKeyMonkey be asked to switch the modes - some sort of dynamic configuration is needed. I guess there could be a config file, which would be reloaded on a signal, or something. Or maybe listen on some pipe or socket for config change commands. I don't know if restarting is an option, like if this is destroying all input all uinput devices, which might confuse the hell out of running programs.

B-ZaR, would you be willing to spend time on something like this?

 

[slaeshjag]

That if anything sounds like a job for dbus. You could have a program request an input device over the system bus, and FunKeyMonkey creates an input device with the requested parameters, if the program supports it I guess.

 

[bzar]

Notaz: much of the above is just a matter of making a suitable plugin to handle wrestling everything to its place. If someone specifies what it should exactly do I can probably make it.

Configuration on the fly via DBus sounds like a good idea to me, but a regular configuration file would probably be a simpler start. The plugin could watch the configuration file for changes and switch configuration on the fly when it's changed.

What I can't say anything about is time frame, since I'm already working on a potential first boot wizard, but I guess I can find time somewhere if someone comes up with a clear specification.

 

[pmprog]

@B-ZaR, I've started a plugin, but wanted to check I'm doing it right.

The code is here, and what I want to happen is when it's activated, it'll create a socket (or maybe pipe, not sure yet). Whilst the overlay program is not active, I want it to let the keypresses through (I assumed I had to create a new virtual keyboard and send them), and if it is active, redirect the keys to the overlay (which I'll probably do using the socket system)

 

[bzar]

@B-ZaR, I've started a plugin, but wanted to check I'm doing it right.

The code is here, and what I want to happen is when it's activated, it'll create a socket (or maybe pipe, not sure yet). Whilst the overlay program is not active, I want it to let the keypresses through (I assumed I had to create a new virtual keyboard and send them), and if it is active, redirect the keys to the overlay (which I'll probably do using the socket system)

Sounds right and looks too. It's basically just: 1) grab the current input device, 2) create a new uinput device, 3) if overlay is not active, forward all events to the uinput device, 4) if the overlay is active, forward them directly to it.

You might want to keep an eye on which keys are held down though so you can release them automatically when activating the overlay.

 

[pmprog]

Sounds right and looks too. It's basically just: 1) grab the current input device, 2) create a new uinput device, 3) if overlay is not active, forward all events to the uinput device, 4) if the overlay is active, forward them directly to it.
You might want to keep an eye on which keys are held down though so you can release them automatically when activating the overlay.

Thanks. That's a good point.

 

[notaz]

Notaz: much of the above is just a matter of making a suitable plugin to handle wrestling everything to its place. If someone specifies what it should exactly do I can probably make it.

Well it would the same stuff pandora currently does - some mouse mode to move the pointer with nubs and a mouse button mode, although I'm not sure about the later, maybe we could use shoulder buttons this time, or something. I guess we'll need ED's input on that. If you want more details on how pandora's driver currently does it I could try to write it down, it's pretty basic stuff though.

Pandora's nubs also have scroll wheel mode, but I don't think anyone uses that so we can leave it out.

 

[pmprog]

I thought the two extra game buttons (I and II) were planned for mouse buttons - at least that's my intention

 

[God Ginrai]

I thought the two extra game buttons (I and II) were planned for mouse buttons - at least that's my intention

Nope.  Take a look at the image of the Keymat.  Those are going to be Insert and Delete.

-God Ginrai

 

[Grench]

I thought the two extra game buttons (I and II) were planned for mouse buttons - at least that's my intention

Nope.  Take a look at the image of the Keymat.  Those are going to be Insert and Delete.

-God Ginrai

I think I can help here.  This is how it was discussed in the keyboard design threads.  

The Pyra nubs do something beyond the Pandora nubs.  The Pyra nubs have a push-click capability when centered.  Note this is not push-click-drag, but just push-click.

So, since the left nub controls mouse movement, push-click on the right nub is the equivalent of a left mouse click.  This allows you to click (using right nub push-click) and drag (using the left nub motion).

Conversely, the left nub push-click is the equivalent of a right mouse button.  This is most commonly used to activate contextual menus.

The right nub is then available for up/down/left/right scrolling.

Hope that helps.

 

[bzar]

Notaz: much of the above is just a matter of making a suitable plugin to handle wrestling everything to its place. If someone specifies what it should exactly do I can probably make it.

Well it would the same stuff pandora currently does - some mouse mode to move the pointer with nubs and a mouse button mode, although I'm not sure about the later, maybe we could use shoulder buttons this time, or something. I guess we'll need ED's input on that. If you want more details on how pandora's driver currently does it I could try to write it down, it's pretty basic stuff though.

Pandora's nubs also have scroll wheel mode, but I don't think anyone uses that so we can leave it out.

That shouldn't be much of an issue. I'll make a plugin implementing those for a generic gamepad to try it out once I find a few spare hours.

 

[bzar]

Got nub mouse mode with nub-clicks almost done yesterday. One issue I faced was with smooth mouse movement, since with absolute axes like an analog stick you only get an event when it changes. So cursor movement happens only when the stick moves. I try to minimize CPU wakeups by not having a timed polling function in funkeymonkey, so I implemented a thread to handle smooth movement that sleeps when relevant nubs are inside the configured dead zone. This way the plugin should use just about no CPU when idle (save for some rare timeout checks for the input device). I'm using the input event codes a WiiU Pro pad causes, but if Pyra's are different from those it's not hard to change.

 

[thatgui]

Nothing interesting to add, just wanted to express my gratitude and (some light form of) admiration for your work

 

[God Ginrai]

Got nub mouse mode with nub-clicks almost done yesterday. One issue I faced was with smooth mouse movement, since with absolute axes like an analog stick you only get an event when it changes. So cursor movement happens only when the stick moves. I try to minimize CPU wakeups by not having a timed polling function in funkeymonkey, so I implemented a thread to handle smooth movement that sleeps when relevant nubs are inside the configured dead zone. This way the plugin should use just about no CPU when idle (save for some rare timeout checks for the input device). I'm using the input event codes a WiiU Pro pad causes, but if Pyra's are different from those it's not hard to change.

What's the difference in how the data is received from the data that you would receive from a mouse?  I'm not sure why you would need polling. :\

-God Ginrai

 

[bzar]

Mouse controls cursor position, nubs control cursor velocity.

As you move a mouse, every quantum of movement gets its own event. As long as the mouse moves the cursor should as well. When you stop the mouse, the cursor should too.

As you move an analog nub, every quantum of change in its position gets its own event. As long as the nub position changes, the velocity of the cursor should as well. When you stop moving the nub, the cursor should keep moving to the direction the nub is being held at. There's no further events to move the cursor with until the nub is moved again.

 

[ible]

one of the nice things about that is we could find a nice function to map analog-position to cursor-velocity, so that you have extra precision near the origin.  or say, for the pyra, if we hold Fn, that we get extra precision.

 

[bzar]

Here's a basic source-configurable nub mouse/joystick with threaded interpolation for mouse/scroll. I defined the raw input values changeable from other threads at any time so the main thread doesn't need to do locking unless absolutely necessary. The worst that can happen is some rogue inside deadzone mouse events or an event missed when deadzone is changed. I deemed the risks trivial for now, but something to keep an eye on. Low latency is more important than event-level precision. Next I'll add a "plugin options" switch to FunKeyMonkey itself for providing the configuration file location and then implement parsing and inotify-based listening for it to the plugin.

https://github.com/bzar/funkeymonkey/blob/master/modules/modalgamepad.cpp

 

[God Ginrai]

Mouse controls cursor position, nubs control cursor velocity.

As you move a mouse, every quantum of movement gets its own event. As long as the mouse moves the cursor should as well. When you stop the mouse, the cursor should too.

As you move an analog nub, every quantum of change in its position gets its own event. As long as the nub position changes, the velocity of the cursor should as well. When you stop moving the nub, the cursor should keep moving to the direction the nub is being held at. There's no further events to move the cursor with until the nub is moved again.

Well yes, but wouldn't you not need to poll even then?  Just assume the same velocity until you receive a new event.

-God Ginrai