RGBController_UpdateCallback sent the SignalUpdate packet synchronously
via SendRequest_RGBController_SignalUpdate, which runs inside
RGBController::SignalUpdate. A blocking send there (slow client) keeps
SignalCalls > 0, so WaitSignalCalls -- the callback drain that
Unregister/ClearCallbacks/Shutdown run while tearing callbacks down on a
rescan -- waits forever. That is the client/server rescan deadlock.
Each client now owns an outbound queue and a dedicated send thread. The
signal path builds the packet (brief AccessMutex, as before) and queues
it; the client's own thread does the blocking send. A slow client backs
up only its own queue and blocks only its own thread, so the signal path
and the callback drain are never blocked.
UPDATELEDS packets coalesce per controller (a newer frame replaces the
pending one), so a stalled client's queue stays bounded to one packet
per controller instead of growing without bound; non-coalescable events
fall back to a hard cap with drop-oldest. The client destructor stops
the thread with shutdown(SD_BOTH), which unblocks an in-flight send, so
the join at teardown cannot hang. A queue entry owns its packet header
and data buffer; the send thread frees the buffer after the send, so
there is no copy and the packet outlives the controller safely.
Follow-up: the send still takes the shared send_in_progress, so a slow
client can still stall sends to others; routing response sends through
the same per-client path would make that a per-client lock.
net_port: add SD_BOTH (SHUT_RDWR) for the POSIX socket shims.
* Add JSON string configuration field to RGBController to store device-specific configurations
* This JSON string holds both configuration and schema
* Add settings schema tracking to SettingsManager
* Implement dynamic settings widget that generates a settings UI based on a JSON schema
* Implement SettingsManager callback for notifying of settings changes and settings schema updates
* Always enable Entire Device zone option and use it to enable Edit Device
* Rename SaveSizes to SaveConfiguration in ProfileManager and Sizes.json to Configuration.json
* Add zone flag for indicating that a zone's geometry may change, informing profile manager to ignore this check
* Remove Theme setting and Theme Manager, as this didn't work on most setups anyways and Qt6 has proper Windows dark theming
* Add zone flags to indicate if fields are manually configurable and if they have been manually configured
* Add flags field to segment type
* Add segment flags for group start and group member
* Add color mode support flags to zone (RGB, RBG, GRB, GBR, BRG, BGR)
* Add color mode enum to zone
* Update zone and segment description functions to support new fields
* Rename the effects-only configurable size flag
* Remove zone type and matrix map configuration from E1.31 manual configuration, use zone editor instead
* Rework DeviceResizeZone to DeviceConfigureZone
* Rework most ARGB controllers to allow zone customizations
* Rework DRGBController to define devices in DRGBDevices list (similar to RazerDevices)
* Rework NollieController to define devices in NollieDevices list (similar to RazerDevices)
* SDK Protocol
* Server sends its name to client
* ProfileManager
* Rename existing profile commands
* Add Upload Profile, Download Profile, and Get Active Profile commands
* SettingsManager
* Add Get, Set, and Save Settings commands
* Add zone::active_mode, zone::mode fields for zone-specific modes
* Add NET_PACKET_ID_RGBCONTROLLER_UPDATEZONEMODE packet for updating zone modes
* Add segment::matrix_map to segment packet
* Add NET_PACKET_ID_RGBCONTROLLER_SIGNALUPDATE packet for passing SignalUpdate signal from server to clients
* NetworkServer
* Formatting cleanup
* Use per-controller threads for handling NetworkServer controller-specific packets to avoid delays from controller mutexes
* NetworkClient
* Formatting cleanup
* RGBController
* Clean up and modularize descriptor functions
This patch resolves several bugs:
* NetworkServer would allocate various instances of `NetworkClientInfo`.
This is patched by deallocating the NetworkClientInfo when it's
listening thread ends in the `listen_done` section.
* Memory would be allocated for threads that wouldn't be freed. This
is resolved by detaching from the threads, so they no longer need to
be joined to be freed, and then freeing the memory as they finish.
* Thread-Safety issues involving `ServerClients` would result in stray
`NetworkClientInfo`'s not being removed from the list in certain
situations. This is resolved by used a mutex to lock access to this
from different threads.
Adam Honse