-
Notifications
You must be signed in to change notification settings - Fork 42
Road Map
This page is just a scratch space with some musings for further development. Comments are welcome. The author is a busy grad student, and this project is likely to stall for extended periods. If you wish to contribute, feel free to tackle any of these.
Mouse emulation is now working, but is pretty bare bones. It targets a 100Hz polling rate.
However, there aren't any event translators that can take a rel event as input, which limits the functionality of using a mouse as an input device.
How would one map a relative movement onto a button? Onto an axis? Would the latter involve reimplementing a cursor movement scheme?
Allow the user to specify a folder in which to load all profiles. This would allow for splitting the profiles for various drivers into separate files.
Some sort of precedence would be needed, as some drivers might want to inherit events and only specify minor tweaks.
- Number the files to ensure their ordering?
- Require some sort of manifest file in the folder?
Currently all virtual devices are created on start-up, and can be neither created nor destroyed. One might want to create virtual devices only when input sources are connected or in use.
Due to keeping concurrency simple, this will likely be implemented by having the number of output_slots be fixed during runtime, but allow for an output_slot to create/destroy its uinput device as needed. This puts an upper limit on how many might be in use at one time. (Growing the output_slot should be fine, it is freeing them that is a problem.)
The main issue here is player numbering, once that support is in place. Most games will number controllers based solely on their node names, which come from the order they are created. Creation and destruction of event devices can destroy this ordering. Some games might go by order connected, which can differ the device node numbering when low-numbered gaps are created. Others might use jsX nodes, which could also be a different order. (And some things seem to be lazy and depend on js0...)
I consider the ability to let multiple input devices end up on the same slot as a critical feature and design goal of MG. This complicated slot allocation is not an incidental feature.
Related to the above, it would be nice to create a library of virtual uinput device specifications, allowing an output_slot to change the virtual device it presents.
Any run time changes run into the same creation/destruction ordering problems.
Combining this with gendevice files, MoltenGamepad can build up a useful easy to read library of files for a wide range of input devices, which might be of interest to other projects.
Connecting to a slot can be reflected on LEDs on most console controllers these days. Each player number should somehow be associated with: a 4 LED pattern, and an RGB color.
The former should handle going above 4 connected controllers if possible. The RGB value is useful for PS4 controllers, as well as eventually allowing that information to be used in future configuration utilities.
Perhaps it should just be a player number, and let the drivers determine the LED pattern. Some might not be able to control all four independently.
With the above two features, there will be a disconnect with slot names and numbers. E.g. virtpad2 might become player #1. It might be nice to allow specifying slots either name or player number.
I am not sure what to call these, but essentially the behavior of letting a button change the layout/meaning of other buttons, like a shift key.
The main problem here is designing a nice syntax for this, along with the event_translators required to change modes (such as cycling through layouts, or only while held, etc.)
<profile>.<shift name>.<event> = ... is simple, but complicates the logic of shuffling values around depending on how many dots we find. So far this is the best I've come up with. The user should be able to skip naming a shift, an implicit default shift.
In profiles, shifts should have string identifiers, so it is clear that this a driving mode or some such. Internally, this may be mapped down to integers in the parse phase. I think it is reasonable to require that a profile declare upfront which/how many shifts it wishes to allocate.
Many of these would likely involve introducing an init-phase where the translator is allowed to bind to its owner. These are generally pipe dreams rather than priority features.
basic translators:
- calibrated versions, like a
btn2axiswhere one specifies the value on press and release. Possibly even one sided, such as sending no event at all when released. Similar versions for the other translators. -
axis2axiswith more complicated response curves. - an axis-to-buttons method that supports redirecting to other event translators.
- run a shell command
- meta events, like changing to a different profile or slot. These ones are likely more complicated than their worth.
- different event firings, such as a press leading to a fixed-width press, or an autofire functionality.
advanced translators:
-
<device>.(axis1,axis2) = square(axis_trans1,axis_trans2)to convert circular axis limits to square ones. Rather than try to feed the new event values back to the device, it is likely sufficient to just let this advance translator handle it, and let<device>.axis1 = nothing -
<device>.(up,down) = cycle(event1,event2,...)to let two buttons cycle through events, like the number keys in an FPS with multiple weapons. -
<device>.(event,event,...) = cheatcode(...)to allow an event only after a successful sequence of inputs. - A two-axis setup for pressing two buttons, where by tilting one or both buttons may be pressed.
- A axis-with-a-toggle-button set up, like gyroscope controls only when a button is held
This is a crazy idea, but potentially useful. Create a framework in input_source for axis events to be calibrated. Note that this must occur prior to event translation! Ideally this should allow for per-device calibrations rather than just per-driver.
Should allow for changing the max/min, the effective deadzone, and centering.