FunKeyMonkey

[comradekingu]

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.

Cut radius of circle of nub movement into a 1:1 square that fits the 16:9 sides for perfect alignment?

At-least for desktop use that is interesting.

 

[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.

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

Well, there needs to be someone sending the "mouse moved 3px to the right" events at constant intervals even when "nub moved" events are not coming. That someone is either the plugin being polled by funkeymonkey core or a separate thread. I can't set "velocity" to a relative input device. Only send "it moved" "it moved" "it moved" over and over again. What I want to avoid is having the funkeymonkey core poll the plugin just in case something needed to happen at intervals. "Hey, it's been some milliseconds, do you need to do anything? No? Cool."

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.

Cut radius of circle of nub movement into a 1:1 square that fits the 16:9 sides for perfect alignment?

At-least for desktop use that is interesting.

Yeah, thought about that. It's REALLY hard to hit stuff with a mouse like that. Also, not possible to right-click (using left nub) anywhere but center is a downside.

 

[comradekingu]

If you limit the square to the clickable region, you could use the outside area for turning up and down something.

Like having less or more brightness on screen or scrolling/panning by turning in big circles.

Rather depends on sensitivity to resolution, but it could work. (Just thinking aloud)

 

[bzar]

Maybe it could. Not something I'll implement now though

 

[_jr_]

I'm wondering whether this 'keep mouse moving stuff' isn't some kind of key repeat.

 

[bzar]

I'm wondering whether this 'keep mouse moving stuff' isn't some kind of key repeat.

There's no mechanism for telling to uinput "repeat this" as far as I know. Also key repeats seldom happen 60 times per second

But yeah, I guess it could be thought of as such.

 

[_jr_]

Not criticizing, just wanting to understand whether the same mechanism could be reused for autofire or something.

 

[bzar]

Well, making a plugin for autofire is quite simple. Or adding that to this one for that matter. For now I'm implementing what pandora has, but if more configurability is desired I'd probably go for some more generic way of adding timed repeating actions than the current mouse interpolator thread.

 

[_jr_]

Yes, not a priority, but having support for timed events probably has some applications.

 

[ible]

the great thing about funkeymonkey is that you can code these features yourself given some of the very nice examples

 

[bzar]

Tried reloading configuration using inotify yesterday, and it's a bit messier than I'd hoped. Since it's actually watching an inode (inode notify) it works fine when a file is modified in-place, but some editors (like vim) tend to write to a temporary file, remove the original and rename the temporary file to its place on save. When this happens inotify loses the inode it was watching and the configuration no longer reloads. I could define the plugin to require a configuration directory instead, watch the directory to catch files popping in and out of it, but I'd also need to watch all the relevant files in case they're modified in-place. To put it short, doing all this would be the majority of the plugin's current line count .

I think I'll try registering a dbus service with a "reload" method instead.

 

[slaeshjag]

Protip: If you go for a service on the system bus (which you should,) don't forget to create a rule in /etc/dbis-1/system.d, or you won't have permission to claim a name.

 

[bzar]

:mellow: Why does every solution involve complications?

Thanks for the preemptive pointer though

 

[slaeshjag]

Lets just say that my first steps into dbus with dbpd was rough

 

[notaz]

Protip: If you go for a service on the system bus (which you should,) don't forget to create a rule in /etc/dbis-1/system.d, or you won't have permission to claim a name.

Do we really have to do this? I'd prefer to avoid these kind of dependencies, these things tend to change and likely break on OS updates, make it hard to debug if some user has a problem and is generally PITA if you don't know dbus inside out.

 

[slaeshjag]

The dbus system bus has a deny-all policy by default when it comes to owning names. Apart from changing the default, I am not aware of how to avoid the issue apart from adding rules.

This is a relatively recent change, probably happened in the last 5 years.

 

[bzar]

I took the easy way out for now. Added SIGUSR1/2 handling support to FunKeyMonkey and made SIGUSR1 reload configuration for modalgamepad

 

[bzar]

Okay so modalgamepad now has the following features:

• Nub axis modes: left/right joystick x/y, mouse x/y velocity, scoll wheel x/y direction (since setting scroll speed isn't that simple I decided against making it scroll velocity)
• Nub click modes: left/right nub click, left/right mouse button
• Mouse/wheel deadzones
• Mouse sensitivity
• Load nub axis/click modes, deadzones and sensitivity from a file given as command line parameter (defaults to passthrough configuration), reload config file on SIGUSR1

Anything important missing for an MVP?

 

[Neelix]

I don't think that it's needed for a MVP,  but I think it would be nice to have a joystick mode where both nubs and the gaming buttons all presented as a single joystick device.  


This would be especially handy for old dos games which let you control a game with either a joystick or the keyboard but not both at the same time.


-Neelix

 

[bzar]

I don't think that it's needed for a MVP,  but I think it would be nice to have a joystick mode where both nubs and the gaming buttons all presented as a single joystick device.  


This would be especially handy for old dos games which let you control a game with either a joystick or the keyboard but not both at the same time.


-Neelix

That's actually how it works right now


Modalgamepad plugin at this time creates a gamepad and a mouse. I'll probably have to still tune it for the actual evdev input devices Pyra presents when there's information what those are. Because of the specifics the current plugin isn't by any means a drop-in solution, but it's an easily customized one.


Is the pyra a limited keyboard and a full game pad? An overlapping keyboard+gamepad? Two one-nub devices, and overlapping gamebuttons and keyboard devices? A full(ish) keyboard and a two-nub joystick? Personally, I'd perhaps lean to either the first or last of those options. Overlapping devices should maybe be something for the userspace, not generated by drivers, though there are valid points to the contrary as well.