Well, I've looked at it. I totally appreciate the work done here, to map out things. It is really great! But "easy" might be to exaggerate a bit 
? In my case, this seems complex, if not impossible.
Once you understand how it works, it's simple. The hardest part seems to be to grasp the concept. 
First; I don't use BIOS in the game. So, I have to go for the ports. That is ok, it seems.
It's not a requirement to use the BIOS, albeit it's fine to use it because RDPSG is quick enough and it doesn't make sense to read joysticks more than once per frame anyway.
But then it becomes complex (given that I understand this correctly). My design of the game is that, the player should, at any given time, be able to play using joystick or keyboard. Both inputs should be active at the same time. I'm not going to bother the player with setting the preferred input source.
So, this means that I need/want to identify a non-joystick EVERY frame.
Yep! That's exactly how it works. Please give HIDtest a run and check for yourself. It only takes around 1s to autodetect that a new device was plugged. No need for cumbersome menus.
So, first I thought this was ok, as I hoped that the fingerprints would include values that otherwise would be impossible for a joystick. Like UP and DOWN pressed at the same time. But fingerprints from paddles are perfectly valid joystick values (UP pressed). Likewise for "Touchpad(2)".
You understood it right: the fingerprints are values that are impossible for a standard MSX joystick to produce.
And then: the fingerprints needs to be sampled when the input device is not in use. I cannot know if the user is using the input device or not? So, no.
No, no. The fingerprints are sampled for ~1s while the device is being connected. Only that specific moment it must be idle. And since the player only has two hands, he won't be using attaching the plug to the computer and using the joystick at the same time, right? :)
And then it doesn't help that the detection is a bit cpu-consuming too, as one have to do busy waiting between the fingerprint values (not sure if I have to wait here - not sure how this timing works).
I've seen no need for busy waits. All the devices I tested could be detected without delays.
But maybe I misunderstood things ofc, but this one seemed tricky.
I hope to have clarified any misunderstandings. Feel free to ask if you have any other questions. :)
Also, the source code of HIDtest and HIDlib are available at the page I linked. Of course in your case you wouldn't need the extra drivers (*1), just the detection part to be able to ignore the devices you don't want. (that's what I do on my game patches).
*1: maybe only the driver for joyMega if you want to support it too?
Somehow, I feel the mouse bug is something else.
Thanks for contributing, ro
Personally, I don't consider this a bug. But, I might consider it a feature if I handle it, haha.
I too use a general keyboard/stick read-out to navigate in software and I'm having a mouse connected all the time. no worries there. At least in my current openMSX set-up, but also in the past using real hardware.
Perhaps this helps, my functions for that:
Your code is almost identical to mine. The difference is that I flip the bits at the end, and handle accordingly. So what matters and what differs then between your code and my code is how that returned value is handled, methinks. I'll figure it out.
Thanks for following up sd_snatcher!
But then it becomes complex (given that I understand this correctly). My design of the game is that, the player should, at any given time, be able to play using joystick or keyboard. Both inputs should be active at the same time. I'm not going to bother the player with setting the preferred input source.
So, this means that I need/want to identify a non-joystick EVERY frame.
Yep! That's exactly how it works. Please give HIDtest a run and check for yourself. It only takes around 1s to autodetect that a new device was plugged. No need for cumbersome menus.
Lots of code in those files. Will look closer soon.
1 second? But what if the user is removing the mouse and replacing with a joystick or something else? I need to put in this 1s check several places. And 1 second is 60 frames. I fear I need to understand more of this to be able to add to my game with the UX I deem required.
You understood it right: the fingerprints are values that are impossible for a standard MSX joystick to produce.
I can't see this. I often use spreadsheets to automatically "unpack" bytes to bits for clarity. I have made a visual overview based on the data on this page:
https://www.msx.org/wiki/MSX-HID
And it looks like this:
It seems like the fingerprint of:
* "Touchpad(2)" is just "Joystick Down". I.e. possible normal joystick signals
* "Arkanoid Vaus Paddle" is "Joystick Up". I.e. possible normal joystick signals
* "Micomsoft XE1-AP analog mode" is "Joystick Trg A". I.e. possible normal joystick signals
Again - it must be something I don't understand :D
And then: the fingerprints needs to be sampled when the input device is not in use. I cannot know if the user is using the input device or not? So, no.
No, no. The fingerprints are sampled for ~1s while the device is being connected. Only that specific moment it must be idle. And since the player only has two hands, he won't be using attaching the plug to the computer and using the joystick at the same time, right? :)
Ok, but how do I know when a user is switching gear?
And then it doesn't help that the detection is a bit cpu-consuming too, as one have to do busy waiting between the fingerprint values (not sure if I have to wait here - not sure how this timing works).
I've seen no need for busy waits. All the devices I tested could be detected without delays.
So the code here: https://www.msx.org/wiki/Mouse/Trackball#Direct_usage_of_mouse
See "WAITMS". There is A LOT of waiting and even a comment like "; Extra delay because the mouse is slow". This code is for fetching real data, but still... So this waiting is not needed?
But maybe I misunderstood things ofc, but this one seemed tricky.
I hope to have clarified any misunderstandings. Feel free to ask if you have any other questions. :)
Yes, please :)
On OpenMSX, when you have a mouse connected, the game cannot be started. Maybe this is a known issue?
With all respect, but I do not understand why you try this in the first place(!)? @SjaaQ
Simple solution to solve this problem: Just do not connect a mouse! 
On OpenMSX, when you have a mouse connected, the game cannot be started. Maybe this is a known issue?
With all respect, but I do not understand why you try this in the first place(!)? @SjaaQ
Simple solution to solve this problem: Just do not connect a mouse!
I agree!
But I'm checking to see it if would be easily possible to ignore signals from the joystick port in those cases where the device is unsupported. Right now, it does not seem straight forward. Also, it may eat cycles I don't have. Still, I'd like to take a more qualified decision once I know more.
UX-wise the second best solution is to to try to detect unsupported devices, and warn the user about it/consequences somehow.
