FunKeyMonkey

Discussion in 'Pyra OS (Debian GNU/Linux)' started by bzar, Jul 8, 2015.

  1. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    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?
     
    Tags:
    TeDaDeS, Caine, _jr_ and 8 others like this.
  2. comradekingu

    comradekingu Glowing ember

    Joined:
    Apr 15, 2011
    Messages:
    4,890
    [rejoicing intensifies]
     
    Klumpen and moxie like this.
  3. FaeMinx

    FaeMinx Rainbow Liberation Instigation

    Joined:
    Dec 11, 2010
    Messages:
    3,081
    Location:
    outside looking in side looking out
    Woohoo! Thanks for going a long way to alleviate my concerns.


    And the best thing about it?


    .... the name!
     
    Last edited by a moderator: Jul 8, 2015
    Neelix and bzar like this.
  4. Grench

    Grench Forum Addict!

    Joined:
    Oct 3, 2008
    Messages:
    5,723
    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?
     
  5. comradekingu

    comradekingu Glowing ember

    Joined:
    Apr 15, 2011
    Messages:
    4,890
    FnkeyMnemonics  ;)
     
    FaeMinx likes this.
  6. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    Yes. Take any input, construct any output.
     
    moxie likes this.
  7. FaeMinx

    FaeMinx Rainbow Liberation Instigation

    Joined:
    Dec 11, 2010
    Messages:
    3,081
    Location:
    outside looking in side looking out
    ^ My hero.
     
  8. Grench

    Grench Forum Addict!

    Joined:
    Oct 3, 2008
    Messages:
    5,723
    Did you try it out on the Pandora with DosBox?
     
  9. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    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.
     
    Last edited by a moderator: Jul 8, 2015
  10. FaeMinx

    FaeMinx Rainbow Liberation Instigation

    Joined:
    Dec 11, 2010
    Messages:
    3,081
    Location:
    outside looking in side looking out
    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?
     
  11. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    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.
     
    FaeMinx likes this.
  12. MrConfusion

    MrConfusion Very Active Member

    Joined:
    Apr 11, 2013
    Messages:
    325
    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!
     
  13. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    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.
     
  14. MrConfusion

    MrConfusion Very Active Member

    Joined:
    Apr 11, 2013
    Messages:
    325
    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?-)
     
  15. moxie

    moxie The voice of reason, sense and exasperation Staff Member

    Joined:
    Aug 15, 2006
    Messages:
    2,707
    Location:
    South of Sweden
    I have nothing to add, except to say that I'm suitably impressed :D
     
  16. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    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.
     
    Last edited by a moderator: Jul 9, 2015
  17. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    Added nicer command line interface, grabbing support and relative path support for plugins.

    Code:
    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
    
     
  18. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    Code:
    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
    
     
  19. aTc

    aTc Very Active Member

    Joined:
    Apr 25, 2009
    Messages:
    153
    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)
     
    Last edited by a moderator: Jul 9, 2015
  20. bzar

    bzar A Commando

    Joined:
    Sep 22, 2008
    Messages:
    4,434
    Location:
    Finland
    ^ 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 :)
     
    Last edited by a moderator: Jul 9, 2015

Share This Page

Loading...