Joystick Port

The values returned depend on the components used and how they are connected. So neither "fingerprint" nor "signature" is adequate. If you have a better idea, feel free to change it. "fingerprint" seems better to me.

This trick needs the pin 8 to works. So it only works with controllers that use it.

MSX Joysticks are connected to no pins when no switch is pressed. So they are not detectable too.

I read the part of the Datapack about the general purpose port, but it doesn't talk about detection at all (as you might expect).
Access times are only specified for reading data from the mouse.
The information I am missing is mainly how the numbers in the MSX-HID article are obtained. I don't own any of the devices that are not supposed to return the same value all the time, so it's hard to test to know the right way to read these bytes.

This also only talks about reading the data from the mouse.
Just to clarify: my mouse reading function (derived from MRC one) works just fine. :)

Now, I would like to add a detection function.
Even if the MSX-HID never existed as such, it seems that is the method used by the MSX2 BIOS (or more) to detect joysticks, mouse and trackballs (?) and manage them differently.
Without implementing all the MSX-HID protocol I would like to have at least the BIOS detection level in my library.

Except for some short messages, I've been keeping some distance from these forums and, in particular, from anything that "shouldn't have been done" for the OPLL, MSX-Audio, MSX-HID or game patches.

I hope I don't regret coming back here to try to clarify your questions. I also hope you don't mind that I use some relatively modern terms to describe ancient hardware, just to make comprehension easier.

Having some knowledge on electronics is important to understand what's happening, since that's exactly what the algorithm uses to detect the devices. Without that, all I can tell you is "don't worry, it works just fine if all the premisses are followed."

One important aspect that is present on the HIDlib documentation (README.TXT file) and not on the article (*1) is that it's a stateful machine. IOW, you have the "detection state" and the "device mode" state.
*1: Never found again the motivation to add it there

• Detection state: just care about detecting the devices, but doesn't know how to talk to them
• Device mode: Doesn't do any detection. It will just call the appropriate driver to read a package of data from the device. If the driver signals that the device was disconnected, the "device mode" state switches the machine to the "Detection state".

Here's where the electronics knowledge is more important. I'll try to explain the best I can:

On the "detection state", the pin-8 of the joystick port is used to send clock pulses. On each pass you read the 6bits of the joystick port to check how the device reacted, and flip the pin-8 value for the next cycle to use, then save that value and repeat until 3 values have been read. Yes, you could read more values, but just 3 is enough. These are the "device fingerprint". In a nutshell, you read the 3 values with the pin-8 in low, HIGH and low states respectively.

Don't care about the timings on the clock pulses, since it's not relevant. All the peripherals I checked were tolerant to the clock speeds that the existing MSX models can flip the pin-8 port state. Probably we would only have to care about timings if we had anything quite faster than the R800. And yes, I know about the mouse timings. But for its detection it's also not relevant. All the relevant timings are mentioned in the premises (i.e.: the device will auto-reset to the 1st byte after ~8ms without receiving clock pulses).

The first 2 bytes if the fingerprint form a unique ID that can be used for the "device mode" to select which driver it will call to talk with the device, or to just ignore it if it's not known. A higher level UI also can display the device name based on this ID. The 3rd byte is used only when relevant, to differentiate between variations of some devices and to detect PWM devices. There are where even more bytes can be read on detection, like the Megadrive 6-button joypad. But this can be done only when really necessary.

Note: It is very important that you read and understand the premises listed in the MSX-HID article.

This is all that there is. It's simple and it just works, if the premises are followed. The rest is implementation dependent. In example, for speed/memory reasons HIDlib will crunch the first 2 bytes of the device fingerprint into a single-byte hash using the "HIDID" formula mentioned in the article.

The touchpad is not emulated, so you can't check that in emulators.

For the lightguns, the emulation is probably uncomplete.

openMSX emulates the touchpad, but it still doesn't behave like the uPD7001 when clock pulses are sent to the pin-8 of the joystick port. This is why the detection fails.