[mmaher88]

Problem

Two bugs with one root cause: device work was aimed at whichever mouse is selected in the carousel, not the mouse it was for.

1. Profile not re-applied after wake / KVM switch (single mouse). On disconnect, DeviceModel hides the offline mouse's card. With one mouse the selection becomes -1. On reconnect PhysicalDevice emits transportSetupComplete before stateChanged re-adds the card, so applyProfileToHardware found no activeSession() and returned silently. The mouse stayed in firmware defaults (DPI reset, buttons undiverted, gestures dead, default SmartShift). The log read device transport ready, applying profile: "default" followed by nothing. This has been present since the PhysicalDevice refactor. In July it was misattributed to a connection race, and #147 only fixed the main-wheel symptom.

2. Two mice of the same model interfere with each other.

• Mouse B's profile was written to mouse A when B was set up and on every B reconnect.
• B's buttons, gestures and thumb wheel ran A's mappings against A's session.
• DPI/SmartShift changes made by B's buttons were saved to A's profile.
• Only the selected mouse followed window focus.
• The profile tab bar was one list shared by both mice. Each mouse's app tabs were merged in when it connected and never rebuilt, so tab clicks, adds and removes, and the highlights hit the wrong mouse's profiles.

Changes

fix(device): route device actions to the mouse they belong to

• Profile applies: ProfileOrchestrator::applyProfileToHardware(device, profile) writes to that device's transport using its own descriptor. It logs when it can't, instead of bailing silently. setupProfileForDevice and onTransportSetupComplete pass their device.
• Window focus: every connected mouse switches to its own app profile.
• Input events: ButtonActionDispatcher slots take the source PhysicalDevice (AppRoot tags each device's signals). Per-device state is keyed by serial. The by-button DPI/SmartShift signals carry the serial, so changes are saved to that mouse.
• Selection: DeviceModel keeps the same mouse selected when a row is inserted or removed in front of it.
• Unchanged: UI edits still act on the selected mouse.

fix(profiles): show each mouse's own app profile tabs

• ProfileModel::resetProfiles rebuilds the tab list in one reset, without emitting user-action signals.
• The tab list is rebuilt from ProfileEngine::appBindings(serial) on every carousel selection change, and when the selected mouse is set up. Connecting another mouse no longer touches the tab bar.

Tests

• 22 new tests, and every routing and tab test failed before the fix:
  • reconnect with a single mouse
  • reconnect of the other mouse
  • adding a second mouse
  • button / gesture / thumb-wheel routing per mouse
  • saving button-made changes to the right mouse
  • focus switching for every mouse
  • keeping the selection when rows are added or removed
  • per-mouse tabs, tab add/remove isolation and highlights
  • ProfileModel::resetProfiles unit tests
• CarouselSwitchSwapsButtonModel was rewritten: its precondition only passed because adding mouse B wrote B's profile onto A, which refreshed A's button list as a side effect.
• 774/774 C++, 9/9 tray, 72/72 QML; the pre-push gate is green. Each commit builds and passes on its own.

Hardware validation

Done with two MX Master 3S-family mice on two Bolt receivers.

• Power-cycling each mouse with its receiver attached (the path that failed): each got device transport ready, applying profile … to <its serial> followed by the full writes, and DPI went from the firmware's 1000 back to 1800.
• KVM switch that re-enumerated the receiver: the mouse was set up again with its own profile.
• Second mouse waking: it got its own profile; the selected mouse was untouched.
• Using both mice together: each thumb wheel used its own mouse's mode (zoom vs volume, interleaved in the log). Window focus switched only the mouse that has a profile for that app.
• Tabs: each mouse shows only its own app tabs; adding or removing a tab affects only that mouse.

Related

• fix(device): re-apply profile when a transport re-attaches #159 / fix: restore device settings after sleep/wake + home view UI polish #133 (re-apply after a re-attach / after resume): they add new triggers, but those still call the selection-based applyProfileToHardware. After this change those triggers should call applyProfileToHardware(device, …). fix(device): re-apply profile when a transport re-attaches #159's use-after-free fix and its no-0x41-on-resume handling are independent and still worthwhile.

Not in this PR

• Device name read with a two-byte index and descriptor matching by receiver PID, which make "MX Master 3S For Business" (WPID 0xB035) match the MX Master 3 descriptor. That will be a separate PR.

🤖 Generated with Claude Code