Add Linux support for illuminance sensors

[JesseTG]

Description

This pull requests implements support for illuminance sensors on Linux; the reading is exposed through retro_sensor_interface and RETRO_SENSOR_ILLUMINANCE. I used my Steam Deck to develop and test it, but this should work on any Linux device that has a light sensor.

Here's a video of it in action:

https://www.youtube.com/watch?v=0cCWS5X3Jcg

Some details about the implementation:

• This integration is available for all Linux-supported input drivers (including sdl2) except wayland. The implementation is orthogonal to the other controller drivers, as illuminance sensors use a different interface than gamepads.
• The solar sensor is polled on a separate thread, with the rate set by the rate parameter of retro_set_sensor_state_t. If the rate is zero, it defaults to 5 times a second. I don't use locks, as I'm assuming that aligned 4-byte reads and writes are atomic on the CPUs that would run this patch. If this assumption is incorrect, please let me know.
• This integration is primarily intended for melonDS DS and mGBA, as the games in the Boktai franchise (including Lunar Knights) used a built-in light sensor to grant buffs to the player. mGBA already supports retro_set_sensor_state_t, and I'm working on it for melonDS DS.

Related Pull Requests

#16188 touches the same interface (though not for illuminance), and will likely have to be updated to address merge conflicts.

[JesseTG]

Oh, one more thing; if the sensor is closed while the poll thread is in retro_sleep, the main thread will be blocked until the poll thread wakes up. Let me do something about that.

[JesseTG]

I think I'll use pthread_cancel and pthread_setcancelstate to allow the sensor polling thread to be canceled if (and only if) it's in the middle of retro_sleep; POSIX requires nanosleep (which retro_sleep uses) to be a cancellation point, so it should be okay.

[LibretroAdmin]

If you want to do any threading at all I'd have to suggest using rthreads instead, at least that way we are not tied/dependent on pthread. Anyway is this PR good to merge?

[JesseTG]

If you want to do any threading at all I'd have to suggest using rthreads instead, at least that way we are not tied/dependent on pthread.

Do we support any Linux environments that don't provide pthread? The functionality in this PR is fundamentally Linux-specific. Linux follows POSIX semantics about which of its library functions can be cancelled, and that includes the nanosleep(2) call within (the generic Unix version of) retro_sleep. See here for a list of functions that can be safely cancelled; nanosleep(2) is one of them.

I also use pthread_setcancelstate(3) to forbid cancellation while actually reading the sensor (lest the file handle be leaked).

The Windows implementation of rthreads is irrelevant here because this PR will never run on Windows. Same goes for the pthreads-styled wrappers around the native threading libraries for the PSP, 3DS, and Gamecube.

Having said that, I'm still evaluating whether this actually solves the problem; it's possible that I'll need to try something else.

Anyway is this PR good to merge?

Almost. First I want to solve the problem of blocking the thread when closing the sensor.

[JesseTG]

@LibretroAdmin All right, I'm good to go. Thanks for checking this out.

[LibretroAdmin]

Alright I'll give it a look over the next day or so.