Streamline keyboard input #71
Conversation
Following the conversation here: libretro/libretro-cap32#23 We decided to try to establish some conventions for some undefined behavior in the API so both core devs and frontend devs can play by the same rules Goals: Define how KBD / Mouse should work in cores - Physical KBD / Mouse always should work (in cores that require KBD and Mouse) - When the ports are set to RETRO_DEVICE_KEYBOARD gamepad input on that port is disabled so a frontend can dedicate that port to KeyMapper input (if implemented) - RETRO_DEVICE_NONE should always be honored (meaning no inputs are passed) This is just an idea and we hope we can get some traction so computer cores can become more popular / user friendly
|
About the last part:
In this PR I'm handling this in the core, but I guess the frontend could handle it too to avoid polling when it's not required |
|
Can you give examples of what the calls to
|
|
You mean the frontend side? |
|
Yes |
|
Well I'm not really sure, I mean the frontend doesn't really care about specifics, basically iterate over your configured number of maximum users setting the frontend ports one by one. https://github.com/libretro/RetroArch/blob/master/command.c#L978 Following what we just agreed upon these cases:
Would be impossible, you wanted keyboard to be always active, that's what we're doing here and now we're basically establishing ONE condition were it's not active (all ports set to none) |
|
Maybe we can change the writing here:
To
|
|
I think we need an out-of-band method to indicate keyboard presence. Using joystick ports fails if there are no joystick ports. |
|
If you use a core option please include this in the libretro API. Frontends shouldn't have to have knowledge of 60 cores and their options to disable a keyboard. |
|
Yeah I removed that comment, I guess we need an env callback to explicitly enable / disable the global keyboard. |
|
Right, then when the keyboard is enabled, it can be queried using |
|
Well, with these changes basically physical keyboard is not attached to any port which was the initial goal. Changes to the API are not my forte, I'm only here because I wanted the keymapper so I'm just trying to achieve what you want without major changes to RA or the API. I think we can leave the API change for later, and basically no way to explicitly enable the keyboard for now? Otherwise we need @twinaphex and @Alcaro to chime in. |
|
Changes to the libretro API will not be made lightly and will only be done after heavy deliberation, and I see that as falling outside of the scope of this particular PR anyway. We will not fall into the trap of so many other projects where the ABI / API is just broken carelessly just to support new features, it has to be done in an intelligent way to ensure all fronts remain on the same page and confidence in the API isn't lost. Even the VFS PR (after it has finally been merged) is still giving us some problems here and there, and I kinda wish that we had taken even longer before we finally got that merged, since obviously not enough testing was performed still and we were not careful enough. If this had been ffmpeg, we'd have broken API about 20/30 times a year already and everybody would have to endlessly update to the latest ffmpeg API. I think this is kinda the bane of multimedia players' existence, and probably the reason why Kodi and other projects just hardfork ffmpeg entirely. We want to avoid that deadtrap entirely for libretro. Basically, the extreme vetting process that goes into any changes to libretro is to avoid another ffmpeg scenario from emerging, where nobody can rely on the main API to remain stable and every project that depends on it (VLC/Kodi/PPSSPP/etc) just starts hardforking away in order to have anything stable. So yes, any API additions will not only be carefully vetted to ensure backwards compatibility and to ensure no interfaces are broken in the process, but I think in this case it also falls outside the scope of this particular PR. I don't see anything wrong with this current PR. I will leave it up to @fr500 as to whether or not he wants me to merge this or not, I have no real opinion on it currently. |
|
Ok I'll be checking this again on the weekend and I'll try to bring dosbox, px68k up to speed with this |
Following the conversation here:
libretro/libretro-cap32#23
We decided to try to establish some conventions for some undefined behavior in the API so both core devs and frontend devs can play by the same rules.
Goals:
Define how KBD / Mouse should work in cores
This is just an idea and we hope we can get some traction so computer cores can become more popular / user friendly.