FunKeyMonkey

[bzar]

So I made a thing called FunKeyMonkey. It's on github.

It's basically a simplified inputty without Qt and scripts. It currently takes a evdev device path and a shared object plugin path as parameters, and relays any events to that plugin. The source also contains a nice uinput wrapper, that makes creating uinput devices in C++ about as simple as it can be.

The significance for pyra here is that this can be used to for example implement Fn-like behaviour outside the kernel for picky applications like dosbox. The program doesn't yet have an option to grab the evdev device, but it's easy to add.

Unlike inputty, funkeymonkey depends on very little and is generally very low overhead.

If there's specific needs for modules I can make or at least help make them depending on my current time constraints.

Would this be helpful?

 

[comradekingu]

[rejoicing intensifies]

 

[FaeMinx]

Woohoo! Thanks for going a long way to alleviate my concerns.


And the best thing about it?


.... the name!

 

[Grench]

Can it take a symbol input, say "{" actuated on the Fn layer of the hypothetical Pyra and reconstruct it to "shift is being held and [ was pressed" then pass THAT on to DosBox?

 

[comradekingu]

FnkeyMnemonics 

 

[bzar]

Can it take a symbol input, say "{" actuated on the Fn layer of the hypothetical Pyra and reconstruct it to "shift is being held and [ was pressed" then pass THAT on to DosBox?

Yes. Take any input, construct any output.

 

[FaeMinx]

^ My hero.

 

[Grench]

Can it take a symbol input, say "{" actuated on the Fn layer of the hypothetical Pyra and reconstruct it to "shift is being held and [ was pressed" then pass THAT on to DosBox?

Yes. Take any input, construct any output.

Did you try it out on the Pandora with DosBox?

 

[bzar]

Can it take a symbol input, say "{" actuated on the Fn layer of the hypothetical Pyra and reconstruct it to "shift is being held and [ was pressed" then pass THAT on to DosBox?

Yes. Take any input, construct any output.

Did you try it out on the Pandora with DosBox?

No, but I know what can and can't be done with it.

Simply put, it creates a virtual keyboard that any userspace program, including for example X, sees as a USB keyboard. It then reads the actual keyboard and relays all the events from that to a plugin module. That plugin module then does whatever it wants with the events, including but not limited to sending new keyboard events to the virtual keyboard. After I add grabbing as a command line option any other program can't read the actual keyboard, and only get their input from the virtual one.

 

[FaeMinx]

So the virtual one can output scancodes as if a hardware key is being pressed? And the actual scancode 'never happened' as far as the rest of the system is concerned?

 

[bzar]

Yes. The generated event then goes through all the same steps a "real" event would. This includes xkbmap and such that may cause funkiness if they are configured to pyra, but those can be temporarily changed to default ones. Anyway, scancode based applications won't care about those anyway.

 

[MrConfusion]

So, yesturday you said Inputty is too heavy and after what, less than 24 hours, you've got the viable alternative . That's briliant work man!

I recall someone (other than me) on these forums somewhere mentioning that a "input daemon" was also desirable on the Pandora, I just can't locate the post... whoever said it might be interested too...

I see no reason to lock the evdev devices, after all, if you point X, SDL, whatever to the uinput devices who's going to read the "originals"?

Being able to have several uinputs piping this output is a very intriguing idea... if Pandoras SDL supported passing the evdev device to read via an environment variable (or does it? it does read many other things from the env...), it would be possible to have different configurations for different apps even simultaneously!

 

[bzar]

I see no reason to lock the evdev devices, after all, if you point X, SDL, whatever to the uinput devices who's going to read the "originals"?

The devices being "remapped" pretty much need to be locked. Otherwise you get both the generated AND original input, which is not desirable. FunKeyMonkey should be the only one reading the original device in this scenario. For something like pandora that has the inputs spread across several evdev devices one could just "remap" the keyboard and let the others be themselves, especially since many a software depends on the gpio-stuff being in specifically named devices.

 

[MrConfusion]

I see no reason to lock the evdev devices, after all, if you point X, SDL, whatever to the uinput devices who's going to read the "originals"?

The devices being "remapped" pretty much need to be locked. Otherwise you get both the generated AND original input, which is not desirable. FunKeyMonkey should be the only one reading the original device in this scenario. For something like pandora that has the inputs spread across several evdev devices one could just "remap" the keyboard and let the others be themselves, especially since many a software depends on the gpio-stuff being in specifically named devices.

OK, I just now downloaded your work, compiled, tested (after a bit of classical MrConfusionDaFuuu... realized that kernel uinput support might be a requirement and compiled the module . Button goes down, k comes out, good stuff .

Haven't had time to actually dig into it yet. But now I finally understand how grossly I have misunderstood uinput's intended behaviour even after reading the description of it's function.

Clearly I need to reread.

Apologies for not digging deep enough - I hope others haven't had "what'sheonabout"s because of me. Basically I read uinput to be virtual eth in evdev land, if that makes any sense.

The locking will be desirable then. And also, I think there are definitely usecases for grabbing multiple inputs, at least switching action buttons between joystick buttons, mouse buttons and/or regular keyboard buttons - all kinds of cool mayhem like that.

With what I glanced quickly: how about daemonizing and passing a SIGHUP, SIGUSR1 and SIGUSR2 to the module so it can do dirty module specific deeds?-)

 

[moxie]

I have nothing to add, except to say that I'm suitably impressed

 

[bzar]

With what I glanced quickly: how about daemonizing and passing a SIGHUP, SIGUSR1 and SIGUSR2 to the module so it can do dirty module specific deeds?-)

I'll do a first somewhat contained version to a reasonable quality with a small feature set so it's at least decent. We'll see then.

 

[bzar]

Added nicer command line interface, grabbing support and relative path support for plugins.

Usage:
  ./funkeymonkey [OPTION...] - A evdev/uinput wrangler

  -d, --device PATH  Input device to read from, eg. /dev/input/event0
  -p, --plugin PATH  Path to plugin
  -g, --grab         Grab the input device, preventing others from accessing
                     it
  -h, --help         Print help

 

[bzar]

Usage:
  ./funkeymonkey [OPTION...] - A evdev/uinput wrangler

  -i, --device PATH  Input device to read from, eg. /dev/input/event0
  -p, --plugin PATH  Path to plugin
  -g, --grab         Grab the input device, preventing others from accessing
                     it
  -d, --daemonize    Daemonize process
  -h, --help         Print help

 

[aTc]

I recall someone (other than me) on these forums somewhere mentioning that a "input daemon" was also desirable on the Pandora, I just can't locate the post... whoever said it might be interested too...

That's probably me.

Was already busy thinking up my own input daemon, and are discussing things with B-ZaR on irc.

What his program currently does is just the absolute basics, things get a LOT more complex when you want to read from multiple input devices, have some events turned into others, and have some things pass through unmodified.

Things get very fun if you want to make everything easily configurable, like when you want to turn nub certain nub movements into key events, or have keys generate different events based on how long they're held.

It's not helped by the fact that uinput only does actual keypress events. You can't generate a "!" keypress for example, you need to generate "press shift, press 1 , release 1, release shift" events.

It's Xorg that's turning the keypresses into characters, through the keymap.

(It doesn't only do key events though, it's capable of doing any input event linux supports, but with the limitation that it's all the low level raw events.. so nothing is cooked or callibrated)

 

[bzar]

^ Yes. Thinking about the keyboard part as controlling a virtual keyboard with the physical one leads to features such as creating a "!" by pressing and releasing the virtual buttons in the correct order.

My immediate concern is implementing a module for easy Fn mapping to be used with Pyra if needed. Achieving that doesn't need much more than is already implemented. Funkeymonkey doesn't filter any events save for SYN though, so reading and writing game controls and nubs is possible. If anyone wants to contribute I'm all for it