Bug

On macOS, clicking inside the emulated display has no effect when using an absolute input device such as the 3M MicroTouch Serial touchscreen (mouse_input_mode >= 1). The mouse gets captured (cursor disappears) but all button press and release events are silently dropped.

Linux and Windows are unaffected.

Root Cause

mousePressEvent() and mouseReleaseEvent() in src/qt/qt_rendererstack.cpp each contain a platform-specific preprocessor block that guards the mouse_set_buttons_ex() call. The macOS (__APPLE__) branch had a uniquely broken condition:

```cpp

else // APPLE

    if ((m_monitor_index >= 1) && (mouse_input_mode >= 1) && mousedata.mouse_tablet_in_proximity)

endif

```

This requires both:

• m_monitor_index >= 1 — always false on a single primary monitor (index 0)
• mousedata.mouse_tablet_in_proximity — always false without physical tablet/stylus hardware in proximity

So the condition can never be true on a typical single-monitor macOS setup, and mouse_set_buttons_ex() is never called, meaning clicks are never forwarded to the emulated machine.

By contrast, Linux uses:
```cpp
if (((m_monitor_index >= 1) && (mouse_input_mode >= 1) && mousedata.mouse_tablet_in_proximity) || (m_monitor_index < 1))
```
and Windows uses:
```cpp
if (((m_monitor_index >= 1) && (mouse_input_mode >= 1) && mousedata.mouse_tablet_in_proximity) || ((m_monitor_index < 1) && (mouse_input_mode >= 1)))
```

Both of these correctly handle m_monitor_index == 0 (primary monitor).

How to Reproduce

1. Configure 3M MicroTouch Serial (or any other mouse_input_mode >= 1 device) as the mouse type in 86Box settings.
2. Run 86Box on macOS with a single monitor.
3. Start a machine — the cursor disappears (mouse is captured), but clicking anywhere inside the emulated display produces no response in the guest OS.

Fix

Remove the nested __APPLE__-specific branch and replace it with the same condition used on Windows — ((m_monitor_index >= 1) && (mouse_input_mode >= 1) && mousedata.mouse_tablet_in_proximity) || ((m_monitor_index < 1) && (mouse_input_mode >= 1)) — in both mousePressEvent() and mouseReleaseEvent().

This ensures absolute input button events are forwarded on the primary monitor (index 0) when mouse_input_mode >= 1, and retains the existing proximity guard for secondary monitors (m_monitor_index >= 1).

The change affects any absolute input device (mouse_input_mode >= 1) on macOS using the primary monitor. Multi-monitor secondary windows are not affected.

Tested

Verified working on a MacBook Pro (Apple M1 Pro) running macOS. The fix was confirmed by binary-patching the equivalent ARM64 instructions in the released 86Box 5.3 build 8200 universal binary and testing with a Megatouch Maxx arcade image that uses the 3M MicroTouch Serial touchscreen — clicks in the emulated display now correctly register as touch events in the guest OS.