Pyrainput (FunKeyMonkey plugin + pyrainputctl) design


i think it would make sense to fire small scroll events at a low frequency when the nub is less off center, and just fire more frequently if the nub is further off center.
 
Analogue scroll events are actually a thing, think of touchpad scrolling. Touchpads are probably providing absolute instead of relative position information, though.
 
Yes, playing with my trackpad, the two-finger scrolling works as if it's sending a up/down arrow key every centimetre or so I move. Maybe a two zoned approach will be enough for everyone, where it scrollls just one tick if you only move it up to half way, but sends repeated clicks if you move it all of the way, at perhaps some user definable frequency if no happy solution can be found between all the users with their pyras thus far (and willing to contribute to this thread).
 
Analogue scroll events are actually a thing, think of touchpad scrolling. Touchpads are probably providing absolute instead of relative position information, though.
That's a good point, but they're probably handled separately. For example my laptop's touchpad looks like:

Code:
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 325 (BTN_TOOL_FINGER)
    Event code 328 (BTN_TOOL_QUINTTAP)
    Event code 330 (BTN_TOUCH)
    Event code 333 (BTN_TOOL_DOUBLETAP)
    Event code 334 (BTN_TOOL_TRIPLETAP)
    Event code 335 (BTN_TOOL_QUADTAP)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value     42
      Min        0
      Max     1162
      Resolution      12
    Event code 1 (ABS_Y)
      Value    634
      Min        0
      Max      634
      Resolution      12
    Event code 47 (ABS_MT_SLOT)
      Value      0
      Min        0
      Max        4
    Event code 53 (ABS_MT_POSITION_X)
      Value      0
      Min        0
      Max     1162
      Resolution      12
    Event code 54 (ABS_MT_POSITION_Y)
      Value      0
      Min        0
      Max      634
      Resolution      12
    Event code 55 (ABS_MT_TOOL_TYPE)
      Value      0
      Min        0
      Max        2
    Event code 57 (ABS_MT_TRACKING_ID)
      Value      0
      Min        0
      Max    65535
  Event type 4 (EV_MSC)
    Event code 5 (MSC_TIMESTAMP)
Properties:
  Property type 0 (INPUT_PROP_POINTER)
  Property type 2 (INPUT_PROP_BUTTONPAD)

There's not specific scroll events, just touch and multitouch locations. The actual scrolling behavior is handled somewhere else.
 
i think it would make sense to fire small scroll events at a low frequency when the nub is less off center, and just fire more frequently if the nub is further off center.
It would probably need two limit values: when it switches to slow speed and when it changes to fast speed. If these are the same number there's an uncomfortable area where the speed would skip erratically due to the noise in the nubs. The principle is simple, but there's some tuning like this to make it feel nice.
 
probably unrelated but still I have some questions. Where can I find the used mapping? And how do I run the pyra input tester.

when i run the input tester I cant seem to get the nice keyboard layout that shows if my keys are working... tried running it from tty or terminal. but probably im doing it wrong. I suspect my upper right shoulder to not work, I think its mapped to alt but it doesnt show up/work. thats why I am curious about the mapping.

that and getting to know my pyra


Thanks!

bzar pointed me to xinput which you can install from the repo, it monitors if your keys give an input.
 
Last edited:
There's a stupid bug with the way SDL2 reports nub movements that I'm done trying to fix or find a workaround for now. It causes ED and/or the camera to move by itself if the nub is let go quickly. Annoying but still playable. If anyone can let me know of a fix I'd be eternally grateful
This bug undexsym mentions in the thread about his game is related to pyrainput. As a workaround it helps to set nubs.deadzone = -1.

As far as I think what the problem is: In pyrainput.cpp the function "handle" does only send the new position of the analog nubs to the virtual gamepas, if the new position is outside of the deadzone. That seems unintentional.
But I don't really know, if there is a reason for this check. Does it have any negative side effects to remove this?
1757451942762.png
 
Back
Top