Skip to content

Instantly share code, notes, and snippets.

@akarnokd
Created November 26, 2025 09:20
Show Gist options
  • Select an option

  • Save akarnokd/3a1fa11e0d7764214be5ca6da0403e2a to your computer and use it in GitHub Desktop.

Select an option

Save akarnokd/3a1fa11e0d7764214be5ca6da0403e2a to your computer and use it in GitHub Desktop.

Grok Prompt

I'm using CrossOver on an Apple M4 machine. A Unity game I'm playing just got updated from engine version 6000.0.49f1 to 6000.0.59f2. After I launch the game, I lose the ability to interact with the game via mouse and keyboard. If I roll back to 6000.0.49f1, everything works. What could be the problem or settings I need to investigate?

Potential Causes

Based on known issues with Unity on Apple Silicon (including M4), CrossOver (which relies on Wine for translating Windows inputs to macOS), and recent Unity 6000.x updates, the loss of mouse/keyboard interaction after the game update is likely tied to how the new Unity version handles input—specifically the Input System package. Unity 6000.0.59f2 (part of the 6000.2 tech stream) includes refinements to input detection, device polling, and event handling that can conflict with CrossOver's input bridging on ARM-based Macs. Earlier versions like 6000.0.49f1 may have used less strict detection or fallback behaviors that worked better with Wine's emulation layer.

Key factors:

  • Unity Input System Changes: Unity's modern Input System (default in 6000.x) polls devices more aggressively and can fail to detect emulated inputs from CrossOver/Wine, treating them as missing hardware. This has been reported in Unity 6000.x upgrades where keyboard/mouse events stop registering entirely, while legacy input (if used) might still work partially. Similar detection failures occur natively on macOS with Apple Silicon, but CrossOver exacerbates it due to input translation delays or incomplete HID (Human Interface Device) passthrough.
  • CrossOver/Wine Input Emulation: CrossOver maps macOS mouse/keyboard events to Windows APIs, but M4's USB-C/Bluetooth stack has known quirks (e.g., lag or non-detection with non-Apple peripherals via hubs/KVMs). Games using raw input or exclusive mouse capture (common in Unity for FPS/3D games) can "lock" these emulated inputs, causing total unresponsiveness.
  • M4-Specific Hardware Issues: Early M4 reports highlight USB/Bluetooth input instability, especially with third-party devices, which could compound after a game update that increases input polling frequency.
  • Game Update Side Effects: The patch from 49f1 to 59f2 might enable stricter input validation, switch to the new Input System without backward compatibility, or alter fullscreen/mouse confinement, breaking CrossOver's interception.

Less likely but possible: DXVK/Vulkan renderer conflicts in CrossOver (if the update uses updated graphics calls) or macOS Sonoma/Ventura power management suspending inputs in emulated environments.

Settings to Investigate and Fixes to Try

Start with quick CrossOver/macOS tweaks, then escalate to game/Unity-specific workarounds. Test after each change by relaunching the game. If possible, create a fresh CrossOver bottle for the updated game to isolate variables.

1. macOS System-Level Input Permissions (Most Common Fix for CrossOver)

CrossOver games often need explicit access to monitor your inputs, especially post-update when the game requests more direct hardware access.

  • Go to System Settings > Privacy & Security > Input Monitoring.
  • Quit the game and CrossOver completely.
  • Add (or verify) CrossOver and Wine (or the bottle name) to the list. If not listed, launch the game once—it may prompt you.
  • Toggle the permission off/on, then relaunch.
  • Why? This grants emulated Windows apps access to macOS HID events. It's a frequent culprit for mouse/keyboard blackouts in CrossOver on M-series chips.
  • Bonus: Also check Accessibility permissions for CrossOver (for mouse control) and Screen Recording (if fullscreen capture is involved).

2. CrossOver Bottle Configuration

  • Open CrossOver > Right-click your bottle > Control Panel (or Wine Configuration via Run Command).
    • Graphics Tab:
      • Set "Emulate a virtual desktop" to a resolution matching your game (e.g., 1920x1080). This confines mouse input to the window, preventing escape/loss.
      • Try toggling "Use Mac Driver instead of X11" off/on—X11 can lag inputs on M4.
      • If using DXVK (for DirectX), switch to "Builtin" or test Vulkan—updates might expose renderer bugs.
    • Input Tab (if available) or via wine regedit:
      • Run wine regedit in the bottle, navigate to HKEY_CURRENT_USER\Software\Wine\DirectInput, and set MouseWarpOverride to 1 (forces mouse warping for games).
      • Add a DWORD UseRawInput under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdclass\Parameters set to 0 (disables raw input if the game enforces it).
    • Advanced Tab: Enable "High DPI scaling" if the update changed UI scaling, as it can interfere with mouse coords.
  • Create a new bottle with Windows 10/11 64-bit (not 7/Server) for better ARM compatibility.
  • Update CrossOver to the latest (24.x as of late 2025) via the app—newer versions improve M4 input passthrough.

3. Hardware/Peripheral Tweaks (M4-Specific)

  • Test with a wired USB keyboard/mouse directly in a front USB-C port (avoid hubs/KVMs initially).
  • If Bluetooth: Forget/re-pair devices in System Settings > Bluetooth. Disable "Allow Bluetooth devices to wake this computer" temporarily.
  • Run Apple Diagnostics (restart holding D key) to rule out M4 hardware faults.
  • As a workaround, use macOS's built-in AssistiveTouch (System Settings > Accessibility > Pointer Control) to simulate inputs, but this is clunky for gaming.

4. Game/Unity Input Workarounds

Since rollback works, the update likely enforces the new Input System. If you can access game files/settings:

  • Input Settings: Edit inputactions or .inputactions files (if moddable) to use "Dynamic" update mode instead of "Fixed"—this syncs input polling with frame rate, reducing lag/dropouts on emulated setups.
  • PlayerPrefs or Config Files: Look for UserSettings or GameUserSettings.ini in the game's install folder (e.g., ~/Library/Application Support/CrossOver/Bottles/[bottle]/drive_c/users/crossover/My Documents/My Games/[Game]). Set:
    • ExclusiveFullscreen=0 (prevents input lock).
    • RawMouseInput=0 or bRawInput=0.
    • VSync=1 (stabilizes timing).
  • Launch with args (via CrossOver Run Command): Add -window-mode exclusive or -screen-fullscreen 0 to force windowed mode.
  • If the game has a launcher: Disable "Raw Input" or "Borderless Window" options.
  • Unity-Specific: If community patches exist (search game name + "Unity input fix CrossOver"), apply them. Otherwise, report to the game's forums with your setup—mention the exact versions for dev awareness.

5. Testing and Escalation

  • Isolate: Run a simple Unity test project (download from Unity Hub, build a Windows exe with basic input script) in a new CrossOver bottle. If inputs fail there, it's purely CrossOver/M4.
  • Logs: Check CrossOver's debug logs (Bottle > Advanced > Create Debug Log) for errors like "input device not found" or "HID translation failed." Unity console (if accessible) might show Input System warnings.
  • Community/Support: Post on CodeWeavers forums (with logs) or Unity Discussions (tag as "Input System + macOS + Wine"). Search Reddit's r/macgaming for your game + "CrossOver M4."
  • If nothing works, stick with the rollback or consider Parallels/VMware (better input on M4 but paid) or dual-booting Windows via Boot Camp (if your M4 supports it).

This should resolve it in 80% of similar cases—start with Input Monitoring permissions. If you share game name, exact CrossOver version, or logs, I can refine further!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment