diff --git a/Documentation/Compiling.md b/Documentation/Compiling.md
new file mode 100644
index 00000000..dc9a745d
--- /dev/null
+++ b/Documentation/Compiling.md
@@ -0,0 +1,71 @@
+# Compiling
+
+This document details the process to compile OpenRGB from source on supported operating systems.
+
+## Windows
+
+ * You will need the **Microsoft Visual 2019 C++ runtime** installed. You can get it [here](https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)
+ * To build the application yourself on Windows:
+ 1. Download the latest [Visual Studio Community Edition](https://visualstudio.microsoft.com/thank-you-for-downloading-visual-studio-for-cplusplus/?sku=Community) and [Qt Creator](https://www.qt.io/download-thank-you).
+ 2. When [installing the QT toolset](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/Downloading%20Qt%20and%20building%20OpenRGB.md) select the latest revision of Qt 5.15.x as OpenRGB is not yet compatible with QT6.
+ 3. Optionally [install Git](https://git-scm.com/download) if you intend to [contribute your changes](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/CONTRIBUTING.md) to the mainline codebase.
+ 4. Open the OpenRGB.pro project in Qt Creator.
+ 5. Use the MSVC compiler kit, either 32- or 64-bit, to build the application.
+ 6. Run the project from Qt Creator. If you want to use your custom build standalone, download the latest matching Release package and replace the OpenRGB.exe in it with your new build.
+
+## Linux
+
+ 1. Install build dependencies
+ - Debian/Ubuntu: `sudo apt install git build-essential qtcreator qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools libusb-1.0-0-dev libhidapi-dev pkgconf libmbedtls-dev qttools5-dev-tools`
+ - Fedora: `sudo dnf install automake gcc-c++ git hidapi-devel libusbx-devel mbedtls-devel pkgconf qt5-qtbase-devel qt5-linguist`
+ 2. `git clone https://gitlab.com/CalcProgrammer1/OpenRGB`
+ 3. `cd OpenRGB`
+ 4. `mkdir build`
+ 5. `cd build`
+ 4. `qmake ../OpenRGB.pro`
+ 5. `make -j$(nproc)`
+ 6. You can then run the application from the compile directory with `./openrgb` or install with `make install`
+ 7. You will also need to [install the latest udev rules](UdevRules.md).
+
+#### Packaging
+
+You can also build OpenRGB generic AppImage packages and distribution-specific packages for Debian-based and Fedora-based distros. Install the build dependencies from the section above for your distribution before proceeding.
+
+ * AppImage:
+
+ * Debian/Ubuntu:
+ * Make sure OpenRGB is cloned in ~/OpenRGB before proceeding. Output .deb is in ~/.
+ 1. `sudo apt install debhelper`
+ 2. `cd ~/OpenRGB`
+ 3. `scripts/build-package-files.sh debian/changelog`
+ 4. `dpkg-buildpackage -us -B`
+
+ * Fedora:
+ * Make sure OpenRGB is cloned in ~/OpenRGB before proceeding. Output .rpm is in ~/rpmbuild/RPMS/.
+ 1. `sudo dnf install rpmdevtools dnf-plugins-core`
+ 2. `cd ~/`
+ 3. `rpmdev-setuptree`
+ 4. `tar -cf rpmbuild/SOURCES/OpenRGB.tar.gz OpenRGB/`
+ 4. `cd OpenRGB`
+ 5. `./scripts/build-package-files.sh fedora/OpenRGB.spec`
+ 6. `cd ~/`
+ 7. `cp OpenRGB/fedora/OpenRGB.spec rpmbuild/SPECS/`
+ 8. `sudo dnf builddep rpmbuild/SPECS/OpenRGB.spec -y`
+ 9. `cd rpmbuild/SOURCES`
+ 10. `tar -xf OpenRGB.tar.gz`
+ 11. `cd ~/`
+ 12. `rpmbuild -ba rpmbuild/SPECS/OpenRGB.spec`
+
+## MacOS
+
+ 1. Install build dependencies with Homebrew
+ - Install Homebrew by following the instructions at https://brew.sh/
+ - `brew install git qt5 hidapi libusb mbedtls@2`
+ - `brew link qt5`
+ 2. [Create a local certificate](https://support.apple.com/guide/keychain-access/create-self-signed-certificates-kyca8916/mac) called OpenRGB with code signing capability
+ 3. git clone https://gitlab.com/CalcProgrammer1/OpenRGB
+ 4. cd OpenRGB
+ 5. qmake OpenRGB.pro
+ 6. make -j8
+ 7. macdeployqt OpenRGB.app -codesign=OpenRGB
+ 8. Copy the OpenRGB.app application package to Applications
diff --git a/Documentation/Images/OpenRGB.png b/Documentation/Images/OpenRGB.png
new file mode 100644
index 00000000..8c6ec366
Binary files /dev/null and b/Documentation/Images/OpenRGB.png differ
diff --git a/Documentation/Images/OpenRGB_Screenshot.png b/Documentation/Images/OpenRGB_Screenshot.png
new file mode 100644
index 00000000..6d408cf1
Binary files /dev/null and b/Documentation/Images/OpenRGB_Screenshot.png differ
diff --git a/Documentation/KernelParameters.md b/Documentation/KernelParameters.md
new file mode 100644
index 00000000..b9a0e035
--- /dev/null
+++ b/Documentation/KernelParameters.md
@@ -0,0 +1,17 @@
+# Kernel Parameters
+
+ * To resolve an ACPI conflict add the `acpi_enforce_resources=lax` kernel parameter.
+ * If you want to check if the kernel was loaded with this option you can execute this command from the terminal once you've rebooted: `cat /proc/cmdline`.
+
+### Arch Linux
+
+ * Please see [the Arch wiki](https://wiki.archlinux.org/title/kernel_parameters) for details on how to update your bootloader.
+
+### Debian/Ubuntu
+
+ * Please see [the Ubuntu Documentation](https://wiki.ubuntu.com/Kernel/KernelBootParameters) for Kernel Parameters for more information on updating your boot parameters.
+
+### Fedora
+
+ * On Fedora, install `grubby` and then following command: `grubby --update-kernel=ALL --args="acpi_enforce_resources=lax"`.
+ * For more information please refer to the Fedora docs for [grubby](https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool).
diff --git a/Documentation/OpenRGBSDK.md b/Documentation/OpenRGBSDK.md
new file mode 100644
index 00000000..8b3d0459
--- /dev/null
+++ b/Documentation/OpenRGBSDK.md
@@ -0,0 +1,286 @@
+# OpenRGB SDK Documentation
+
+OpenRGB provides a network-based Software Development Kit (SDK) interface for third-party software applications to integrate with OpenRGB to control lighting on OpenRGB-supported devices. This protocol is a binary, packet-based protocol designed for efficient, lightweight transfer of lighting data over a TCP/IP connection. It may be used locally or over a physical network between computers. The protocol is versioned. Client and server must negotiate a minimum supported protocol version upon connection. The selected protocol version determines what capabilities are available and can change packet format for certain packets as new information is added to the protocol.
+
+The protocol mimics the [RGBController API](The-RGBController-API) closely. It can be thought of as "RGBController over IP" in that the protocol is designed so that a network RGBController object can be created on the client that is a direct copy of the real RGBController object on the server. Calls to the network client RGBController object send packets to the server which trigger calls to the real object, updating the necessary object data before the call.
+
+# Protocol Versions
+
+| Version | Release | Description |
+| ------- | ------- | --------------------------------------------- |
+| 0 | 0.3 | Initial (unversioned) protocol |
+| 1 | 0.5 | Add versioning, add vendor string |
+| 2 | 0.6 | Add profile controls |
+| 3 | 0.7* | Add brightness field to modes, add SaveMode() |
+
+\* Denotes unreleased version, reflects status of current pipeline
+
+# Protocol Basics
+
+The default port for the OpenRGB SDK server is 6742. This is "ORGB" on a telephone keypad.
+
+Each packet starts with a header that indicates the packet is an OpenRGB SDK packet and provides the device and packet IDs. The header format is described in the following table.
+
+### NetPacketHeader structure
+
+| Size | Format | Name | Description |
+| ---- | ------------ | ----------- | ------------------- |
+| 4 | char[4] | pkt_magic | Magic value, "ORGB" |
+| 4 | unsigned int | pkt_dev_idx | Device Index |
+| 4 | unsigned int | pkt_id | Packet ID |
+| 4 | unsigned int | pkt_size | Packet Size |
+
+`pkt_magic`: Always set this to the literal value "ORGB".
+
+`pkt_dev_idx`: The device index that the command is targeting.
+
+`pkt_id`: The command ID, see IDs table below
+
+`pkt_size`: The size, in bytes, of the packet data
+
+### Packet IDs
+
+The following IDs represent different SDK commands. Each ID packet has a certain format of data associated with it, which will be explained under each ID's section of this document. Gaps have been left in the ID values to allow for future expansion. The same ID values are often used for both request and response packets.
+
+| Value | Name | Description |
+| ----- | ------------------------------------------------------------------------------------------- | ------------------------------------------------ |
+| 0 | [NET_PACKET_ID_REQUEST_CONTROLLER_COUNT](#net_packet_id_request_controller_count) | Request RGBController device count from server |
+| 1 | [NET_PACKET_ID_REQUEST_CONTROLLER_DATA](#net_packet_id_request_controller_data) | Request RGBController data block |
+| 40 | [NET_PACKET_ID_REQUEST_PROTOCOL_VERSION](#net_packet_id_request_protocol_version) | Request OpenRGB SDK protocol version from server |
+| 50 | [NET_PACKET_ID_SET_CLIENT_NAME](#net_packet_id_set_client_name) | Send client name string to server |
+| 100 | [NET_PACKET_ID_DEVICE_LIST_UPDATED](#net_packet_id_device_list_updated) | Indicate to clients that device list has updated |
+| 150 | [NET_PACKET_ID_REQUEST_PROFILE_LIST](#net_packet_id_request_profile_list) | Request profile list |
+| 151 | [NET_PACKET_ID_REQUEST_SAVE_PROFILE](#net_packet_id_request_save_profile) | Save current configuration in a new profile |
+| 152 | [NET_PACKET_ID_REQUEST_LOAD_PROFILE](#net_packet_id_request_load_profile) | Load a given profile |
+| 153 | [NET_PACKET_ID_REQUEST_DELETE_PROFILE](#net_packet_id_request_delete_profile) | Delete a given profile |
+| 1000 | [NET_PACKET_ID_RGBCONTROLLER_RESIZEZONE](#net_packet_id_rgbcontroller_resizezone) | RGBController::ResizeZone() |
+| 1050 | [NET_PACKET_ID_RGBCONTROLLER_UPDATELEDS](#net_packet_id_rgbcontroller_updateleds) | RGBController::UpdateLEDs() |
+| 1051 | [NET_PACKET_ID_RGBCONTROLLER_UPDATEZONELEDS](#net_packet_id_rgbcontroller_updatezoneleds) | RGBController::UpdateZoneLEDs() |
+| 1052 | [NET_PACKET_ID_RGBCONTROLLER_UPDATESINGLELED](#net_packet_id_rgbcontroller_updatesingleled) | RGBController::UpdateSingleLED() |
+| 1100 | [NET_PACKET_ID_RGBCONTROLLER_SETCUSTOMMODE](#net_packet_id_rgbcontroller_setcustommode) | RGBController::SetCustomMode() |
+| 1101 | [NET_PACKET_ID_RGBCONTROLLER_UPDATEMODE](#net_packet_id_rgbcontroller_updatemode) | RGBController::UpdateMode() |
+| 1102 | [NET_PACKET_ID_RGBCONTROLLER_SAVEMODE](#net_packet_id_rgbcontroller_savemode) | RGBController::SaveMode() |
+
+# Packet-Specific Documentation
+
+## NET_PACKET_ID_REQUEST_CONTROLLER_COUNT
+
+### Request [Size: 0]
+
+The client uses this ID to request the number of controllers on the server. The request contains no data.
+
+### Response [Size: 4]
+
+The server responds to this request with the number of controllers in the device list. The response contains a single `unsigned int`, size 4, holding this value.
+
+## NET_PACKET_ID_REQUEST_CONTROLLER_DATA
+
+### Request [Protocol 0 Size: 0] [Protocol 1+ Size: 4]
+
+The client uses this ID to request the controller data for a given controller. For protocol 0, this request contains no data. For protocol 1 or higher, this request contains a single `unsigned int`, size 4, holding the highest protocol version supported by both the client and the server. The `pkt_dev_idx` of this request's header indicates which controller you are requesting data for. Upon connecting, the client should request controller data from 0 to [controller count], where [controller count] is the value from NET_PACKET_ID_REQUEST_CONTROLLER_COUNT.
+
+NOTE: Before sending this request, the client should request the protocol version from the server and determine the value to send, if any. If the server is using protocol version 0, even if the SDK implementation supports higher, send this packet with no data.
+
+### Response [Size: Variable]
+
+The server responds to this request with a large data block. The format of the block is shown below. Portions of this block are omitted if the requested protocol level is below the listed value. The receiver is expected to parse this data block using the same protocol version sent in the request (or protocol 0 if the request is sent with no data).
+
+| Size | Format | Name | Protocol Version | Description |
+| ------------------- | ------------------------- | ------------------- | ---------------- | ---------------------------------------------------------------------------- |
+| 4 | unsigned int | data_size | 0 | Size of all data in packet |
+| 4 | int | type | 0 | RGBController type field value |
+| 2 | unsigned short | name_len | 0 | Length of RGBController name field string, including null termination |
+| name_len | char[name_len] | name | 0 | RGBController name field string value, including null termination |
+| 2 | unsigned short | vendor_len | 1 | Length of RGBController vendor field string, including null termination |
+| vendor_len | char[vendor_len] | vendor | 1 | RGBController vendor field string value, including null termination |
+| 2 | unsigned short | description_len | 0 | Length of RGBController description field string, including null termination |
+| description_len | char[description_len] | description | 0 | RGBController description field string value, including null termination |
+| 2 | unsigned short | version_len | 0 | Length of RGBController version field string, including null termination |
+| version_len | char[version_len] | version | 0 | RGBController version field string value, including null termination |
+| 2 | unsigned short | serial_len | 0 | Length of RGBController serial field string, including null termination |
+| serial_len | char[serial_len] | serial | 0 | RGBController serial field string value, including null termination |
+| 2 | unsigned short | location_len | 0 | Length of RGBController location field string, including null termination |
+| location_len | char[location_len] | location | 0 | RGBController location field string value, including null termination |
+| 2 | unsigned short | num_modes | 0 | Number of modes in RGBController |
+| 4 | int | active_mode | 0 | RGBController active_mode field value |
+| Variable | Mode Data[num_modes] | modes | 0 | See [Mode Data](#mode-data) block format table. Repeat num_modes times |
+| 2 | unsigned short | num_zones | 0 | Number of zones in RGBController |
+| Variable | Zone Data[num_zones] | zones | 0 | See [Zone Data](#zone-data) block format table. Repeat num_zones times |
+| 2 | unsigned short | num_leds | 0 | Number of LEDs in RGBController |
+| Variable | LED Data[num_leds] | leds | 0 | See [LED Data](#led-data) block format table. Repeat num_leds times |
+| 2 | unsigned short | num_colors | 0 | Number of colors in RGBController |
+| 4 * num_colors | RGBColor[num_colors] | colors | 0 | RGBController colors field values |
+
+## Mode Data
+
+The Mode Data block represents one entry in the `RGBController::modes` vector. Portions of this block are omitted if the requested protocol level is below the listed value.
+
+| Size | Format | Name | Protocol Version | Description |
+| ------------------- | ------------------------- | ------------------- | ---------------- | ------------------------------------------------------ |
+| 2 | unsigned short | mode_name_len | 0 | Length of mode name string, including null termination |
+| mode_name_len | char[mode_name_len] | mode_name | 0 | Mode name string value, including null termination |
+| 4 | int | mode_value | 0 | Mode value field value |
+| 4 | unsigned int | mode_flags | 0 | Mode flags field value |
+| 4 | unsigned int | mode_speed_min | 0 | Mode speed_min field value |
+| 4 | unsigned int | mode_speed_max | 0 | Mode speed_max field value |
+| 4 | unsigned int | mode_brightness_min | 3 | Mode brightness_min field value |
+| 4 | unsigned int | mode_brightness_max | 3 | Mode brightness_max field value |
+| 4 | unsigned int | mode_colors_min | 0 | Mode colors_min field value |
+| 4 | unsigned int | mode_colors_max | 0 | Mode colors_max field value |
+| 4 | unsigned int | mode_speed | 0 | Mode speed value |
+| 4 | unsigned int | mode_brightness | 3 | Mode brightness value |
+| 4 | unsigned int | mode_direction | 0 | Mode direction value |
+| 4 | unsigned int | mode_color_mode | 0 | Mode color_mode value |
+| 2 | unsigned short | mode_num_colors | 0 | Mode number of colors |
+| 4 * mode_num_colors | RGBColor[mode_num_colors] | mode_colors | 0 | Mode color values |
+
+## Zone Data
+
+The Zone Data block represents one entry in the `RGBController::zones` vector.
+
+| Size | Format | Name | Protocol Version | Description |
+| ---------------------- | --------------------------------- | ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------ |
+| 2 | unsigned short | zone_name_len | 0 | Length of zone name string, including null termination |
+| zone_name_len | char[zone_name_len] | zone_name | 0 | Zone name string value, including null termination |
+| 4 | int | zone_type | 0 | Zone type value |
+| 4 | unsigned int | zone_leds_min | 0 | Zone leds_min value |
+| 4 | unsigned int | zone_leds_max | 0 | Zone leds_max value |
+| 4 | unsigned int | zone_leds_count | 0 | Zone leds_count value |
+| 2 | unsigned short | zone_matrix_len | 0 | Zone matrix length if matrix_map exists: (matrix_map width * height * 4) + 8 OTHERWISE 0 if matrix_map NULL |
+| 4* | unsigned int | zone_matrix_height | 0 | Zone matrix_map height (*only if matrix_map exists) |
+| 4* | unsigned int | zone_matrix_width | 0 | Zone matrix_map width (*only if matrix_map exists) |
+| (zone_matrix_len - 8)* | unsigned int[zone_matrix_len - 8] | zone_matrix_data | 0 | Zone matrix_map data (*only if matrix_map exists) |
+
+## LED data
+
+The LED Data block represents one entry in the `RGBController::leds` vector.
+
+
+| Size | Format | Name | Protocol Version | Description |
+| ------------------- | ------------------------- | ------------------- | ---------------- | ------------------------------------------------------ |
+| 2 | unsigned short | led_name_len | 0 | Length of LED name string, including null termination |
+| led_name_len | char[led_name_len] | led_name | 0 | LED name string value, including null termination |
+| 4 | unsignd int | led_value | 0 | LED value field value |
+
+## NET_PACKET_ID_REQUEST_PROTOCOL_VERSION
+
+### Request [Size: 4]
+
+The client uses this ID to request the server's highest supported protocol version as well as to indicate to the server the client's highest supported protocol version. The request contains a single `unsigned int`, size 4, containing the client's highest supported protocol version.
+
+### Response [Size: 4]
+
+The server responds to this request with a single `unsigned int`, size 4, containing the server's highest supported protocol version.
+
+## NET_PACKET_ID_SET_CLIENT_NAME
+
+### Client Only [Size: Variable]
+
+The client uses this ID to send the client's null-terminated name string to the server. The size of the packet is the size of the string including the null terminator. In C, this is strlen() + 1. There is no response from the server for this packet.
+
+## NET_PACKET_ID_DEVICE_LIST_UPDATED
+
+### Server Only [Size: 0]
+
+The server uses this ID to notify a client that the server's device list has been updated. Upon receiving this packet, clients should synchronize their local device lists with the server by requesting size and controller data again. This packet contains no data.
+
+## NET_PACKET_ID_REQUEST_PROFILE_LIST
+
+### Request [Size: 0]
+
+The client uses this ID to request the server's profile list. The request contains no data.
+
+### Response [Size: Variable]
+
+The server responds to this request with a data block. The format of the block is shown below.
+
+## NET_PACKET_ID_REQUEST_SAVE_PROFILE
+
+### Client Only [Size: Variable]
+
+The client uses this ID to command the server to save the current configuration to a profile. It passes the name of the profile to save as a null-terminated string. The size of the packet is the size of the string including the null terminator. In C, this is strlen() + 1. There is no response from the server for this packet.
+
+## NET_PACKET_ID_REQUEST_LOAD_PROFILE
+
+### Client Only [Size: Variable]
+
+The client uses this ID to command the server to load the given profile. It passes the name of the profile to load as a null-terminated string. The size of the packet is the size of the string including the null terminator. In C, this is strlen() + 1. There is no response from the server for this packet.
+
+Calling this function will not actually update the controllers. Instead, the controller states will be updated from the profile on the server side. After sending this request, the client should re-request all controller states from the server so that the client controller states match the server states loaded from the profile. After requesting all of the controller data, the client shall call UpdateMode() on all controllers to apply the updated state.
+
+## NET_PACKET_ID_REQUEST_DELETE_PROFILE
+
+### Client Only [Size: Variable]
+
+The client uses this ID to command the server to delete the given profile. It passes the name of the profile to delete as a null-terminated string. The size of the packet is the size of the string including the null terminator. In C, this is strlen() + 1. There is no response from the server for this packet.
+
+## NET_PACKET_ID_RGBCONTROLLER_RESIZEZONE
+
+### Client Only [Size: 8]
+
+The client uses this ID to call the ResizeZone() function of an RGBController device. The packet data contains a data block. The format of the block is shown below. The `pkt_dev_idx` of this request's header indicates which controller you are calling ResizeZone() on.
+
+| Size | Format | Name | Description |
+| ---- | ------ | -------- | -------------------- |
+| 4 | int | zone_idx | Zone index to resize |
+| 4 | int | new_size | New size of the zone |
+
+## NET_PACKET_ID_RGBCONTROLLER_UPDATELEDS
+
+### Client Only [Size: Variable]
+
+The client uses this ID to call the UpdateLEDs() function of an RGBController device. The packet data contains a data block. The format of the block is shown below. The `pkt_dev_idx` of this request's header indicates which controller you are calling UpdateLEDs() on.
+
+| Size | Format | Name | Description |
+| -------------- | -------------------- | ---------- | ----------------------------------- |
+| 4 | unsigned int | data_size | Size of all data in packet |
+| 2 | unsigned short | num_colors | Number of color values in packet |
+| 4 * num_colors | RGBColor[num_colors] | led_color | Color values for each LED in device |
+
+## NET_PACKET_ID_RGBCONTROLLER_UPDATEZONELEDS
+
+### Client Only [Size: Variable]
+
+The client uses this ID to call the UpdateZoneLEDs() function of an RGBController device. The packet data contains a data block. The format of the data block is shown below. The `pkt_dev_idx` of this request's header indicates which controller you are calling UpdateZoneLEDs() on.
+
+| Size | Format | Name | Description |
+| -------------- | -------------------- | ---------- | --------------------------------- |
+| 4 | unsigned int | data_size | Size of all data in packet |
+| 4 | unsigned int | zone_idx | Zone index to update |
+| 2 | unsigned short | num_colors | Number of color values in packet |
+| 4 * num_colors | RGBColor[num_colors] | led_color | Color values for each LED in zone |
+
+## NET_PACKET_ID_RGBCONTROLLER_UPDATESINGLELED
+
+### Client Only [Size: 8]
+
+The client uses this ID to call the UpdateSingleLED() function of an RGBController device. The packet data contains a data block. The format of the data block is shown below. The `pkt_dev_idx` of this request's header indicates which controller you are calling UpdateSingleLED() on.
+
+| Size | Format | Name | Description |
+| ---- | -------- | --------- | ----------- |
+| 4 | int | led_idx | LED index |
+| 4 | RGBColor | led_color | LED color |
+
+## NET_PACKET_ID_RGBCONTROLLER_SETCUSTOMMODE
+
+### Client Only [Size: 0]
+
+The client uses this ID to call the SetCustomMode() function of an RGBController device. The packet contains no data. The `pkt_dev_idx` of this request's header indicates which controller you are calling SetCustomMode() on.
+
+## NET_PACKET_ID_RGBCONTROLLER_UPDATEMODE
+
+### Client Only [Size: Variable]
+
+The client uses this ID to call the UpdateMode() function of an RGBController device. The packet contains a data block. The format of the data block is shown below. The `pkt_dev_idx` of this request's header indicates which controller you are calling UpdateMode() on.
+
+| Size | Format | Name | Protocol Version | Description |
+| ------------------- | ------------------------- | ------------------- | ---------------- | ------------------------------------------------------ |
+| 4 | unsigned int | data_size | 0 | Size of all data in packet |
+| 4 | int | mode_idx | 0 | Mode index to update |
+| Variable | Mode Data | mode | 0 | See [Mode Data](#mode-data) block format table. |
+
+## NET_PACKET_ID_RGBCONTROLLER_SAVEMODE
+
+### Client Only [Size: Variable]
+
+The client uses this ID to call the SaveMode() function of an RGBController device. The packet contains a data block. The format of the data block is the same as for [NET_PACKET_ID_RGBCONTROLLER_UPDATEMODE](#net_packet_id_rgbcontroller_updatemode). The `pkt_dev_idx` of this request's header indicates which controller you are calling SaveMode() on.
diff --git a/Documentation/RGBControllerAPI.md b/Documentation/RGBControllerAPI.md
new file mode 100644
index 00000000..c58c6c33
--- /dev/null
+++ b/Documentation/RGBControllerAPI.md
@@ -0,0 +1,183 @@
+# RGBController API
+
+Device support in OpenRGB can be broken down into three major components.
+
+* Controller
+* Detector
+* RGBController
+
+## **Controller**
+
+A device's Controller class is a free-form class that provides whatever functionality is necessary to communicate with a device. This class should implement functions to send control packets to a device and receive information packets from a device. It should provide the capability to set device colors and modes. The Controller header file should provide defined constants for mode, speed, and other control values specific to the device's protocol. If possible, this class should provide the capability to retrieve firmware version and serial number information from the device. This class can also provide additional device protocol functionality even if it goes unused in OpenRGB currently. For instance, you may provide functions for controlling mouse DPI, polling rate, fan speed, or any other device-specific capability you want. If OpenRGB ever implements these extra functions in the future, having them implemented already in the Controller will make that easier.
+
+The Controller class files are kept in the Controllers/ folder.
+
+## **Detector**
+
+A device's Detector function scans the attached devices to see if a particular device (Controller/RGBController) exists. At the moment, two types of detectors exist - I2C and non-I2C. Both detector types are passed (by reference) a vector of RGBController pointers in which to add newly detected controllers. Detectors for I2C devices are also passed a vector of I2C bus pointers to scan. Non-I2C detectors rely on other methods of detection, usually hidapi to scan for USB devices. The REGISTER_DETECTOR macros are used to register a detector function with the OpenRGB Resource Manager which is responsible for calling detector functions at detection time.
+
+```C++
+REGISTER_DETECTOR("Detector Name", DetectDevicesFunction);
+REGISTER_I2C_DETECTOR("I2C Detector Name", DetectI2CDevicesFunction);
+```
+
+The Detector files are kept in the Controllers/ folder.
+
+## **RGBController**
+
+OpenRGB uses an internal API called RGBController to standardize the interface to RGB devices from multiple vendors and categories. This API uses vectors to describe each device. This API is implemented as an RGBController class that is inherited by each implementation, for example the RGBController_CorsairPeripheral is defined like so:
+
+```C++
+#include "RGBController.h"
+
+class RGBController_CorsairPeripheral : public RGBController
+{
+```
+
+The RGBController files for a controller implementation are kept in the Controllers/ folder alongside the Controller and Detector files.
+
+The RGBController class specification contains the following:
+
+* Device Name
+* Device Description
+* Device Version
+* Device Serial
+* Device Location
+* Vector of LEDs
+* Vector of Zones
+* Vector of Modes
+* Vector of Colors (32-bit 0x00BBGGRR format)
+* Device Type (enum)
+* Active mode index
+
+### Device Type Values
+
+| Device Type Value | Description |
+| ----------------- | ------------- |
+| 0 | Motherboard |
+| 1 | DRAM |
+| 2 | GPU |
+| 3 | Cooler |
+| 4 | LED Strip |
+| 5 | Keyboard |
+| 6 | Mouse |
+| 7 | Mousemat |
+| 8 | Headset |
+| 9 | Headset Stand |
+
+## LEDs
+
+The LED structure contains information about an LED.
+
+* LED Name
+* LED Value
+
+The Value has no defined functionality in the RGBController API and is provided for implementation-specific use. You can use this field to associate implementation-specific data with an LED.
+
+## Zones
+
+The Zone structure contains information about a zone. A zone is a logical grouping of LEDs defined by the RGBController implementation. LEDs in a zone must be contiguous in the RGBController's LEDs/Colors vectors.
+
+* Zone Name
+* Zone Type
+* LED pointer
+* Color pointer
+* Start Index
+* LED Count
+* Minimum number of LEDs
+* Maximum number of LEDs
+* Matrix map pointer
+
+The LED pointer and Color pointer point to the first LED/Color in the RGBController's LEDs/Colors vector associated with this zone. The Start Index is the index to the same LED/Color in the vectors.
+
+The LED count is the number of LEDs in the zone. For zones with a fixed number of LEDs, the count, min, and max values should all be equal. For zones with a user-adjustable number of LEDs, the count should be between the min and max values, inclusively. User-adjustable zones are most commonly used to represent addressable RGB (ARGB) controllers as the number of LEDs depends on what strips/devices are attached to the ARGB headers. The ResizeZone function in the RGBController API is used to resize the number of LEDs in the zone.
+
+### Zone Types
+
+The zone type enum defines the zone type. This describes the physical layout of the zone and can be used by software to generate appropriate effects for the zone.
+
+| Zone Type Value | Description |
+| --------------- | ----------- |
+| 0 | Single |
+| 1 | Linear (1D) |
+| 2 | Matrix (2D) |
+
+### Matrix Map
+
+Each zone has a matrix map pointer which allows an optional matrix map to be associated with the zone. The matrix map is used to provide positioning information about LEDs in a 2D grid. If a matrix map is not provided for a zone, the zone's matrix map pointer must be set to NULL.
+
+A matrix map has the following:
+
+* Height
+* Width
+* Map data pointer
+
+The height and width determine the size of the map data. The map data pointer should point to a data block of (Height * Width) unsigned 32-bit integers. This data can be accessed as if it were a Map[Y][X] 2D array. The values of the map are LED index values in the zone (so offset by Start Index from the RGBController's LEDs vector). If a spot in the matrix is unused and does not map to an LED, it should be set to 0xFFFFFFFF.
+
+## Modes
+
+Modes represent internal effects and have a name field that describes the effect. The mode's index in the vector is its ID. The Active Mode variable in the RGBController class specifies which mode is currently selected. A mode contains the following:
+
+* Mode Name
+* Mode Value
+* Mode Flags
+* Minimum Speed
+* Maximum Speed
+* Minimum number of colors
+* Maximum number of colors
+* Speed Value
+* Direction
+* Color Mode
+* Colors Vector
+
+The mode value is field is provided to hold an implementation-defined mode value. This is usually the mode's value in the hardware protocol.
+
+The mode flags field is a bitfield that contains information about what features a mode has.
+
+| Mode Flags Bit | Description |
+| -------------- | ------------------------------------------------ |
+| 0 | Mode has speed parameter |
+| 1 | Mode has left/right direction parameter |
+| 2 | Mode has up/down direction parameter |
+| 3 | Mode has horizontal/vertical direction parameter |
+| 4 | Mode has brightness parameter |
+| 5 | Mode has per-LED color settings |
+| 6 | Mode has mode specific color settings |
+| 7 | Mode has random color option |
+
+The mode minimum and maximum speed fields should be set to the implementation-specific minimum and maximum speed values for the given mode if the mode supports speed control. The mode speed value field will be set between the minimum and maximum value, inclusively. The minimum speed may be a greater numerical value than the maximum speed if your device's speed adjustment is inverted (usually because the device takes a delay period rather than a speed value).
+
+The mode minimum and maximum number of colors fields should be used if the mode supports mode-specific color settings. These determine the size range of the mode's Colors vector. If the mode has a fixed number of colors, the minimum and maximum should be equal. Mode-specific colors are used when a mode has one or more configurable colors but these colors do not apply directly to individual LEDs. Example would be a breathing mode that cycles between one or more colors each breath pulse. A mode may have multiple color options available, for instance a breathing mode that can either use one or more defined colors or just cycle through random colors. The available color modes for a given mode are set with the flags. The selected color mode is set using the color mode field, which can be one of the following values.
+
+| Color Mode Value | Description |
+| ---------------- | ------------------------------------------------------------------------------------------------- |
+| 0 | None - this mode does not have configurable colors |
+| 1 | Per-LED - this mode uses the RGBController's colors vector to set each LED to its specified color |
+| 2 | Mode Specific - this mode has one or more configurable colors, but not individual LED control |
+| 3 | Random - this mode can be switched to a random or cycling color palette |
+
+## Functions
+
+### `int GetMode()`
+
+Returns the currently enabled mode of the device. The returned int should line up with the Modes vector.
+
+### `void SetMode(int mode)`
+
+Sets the mode of the device. The mode should be the index in the Modes vector of the mode you wish to set.
+
+### `void SetCustomMode()`
+
+When called, the device should be put into its software-controlled mode. This differs between devices, but generally devices have a direct control or static effect mode. Ideally, this mode should not save to the device's internal Flash. This function sets up a device for software effect control.
+
+### `void UpdateLEDs()`
+
+Update all LEDs based on the device's `colors` vector.
+
+### `void UpdateZoneLEDs(int zone)`
+
+Update all LEDs in the given zone based on the device's `colors` vector.
+
+### `void UpdateSingleLED(int led)`
+
+Update a single LED based on the device's `colors` vector.
diff --git a/Documentation/SMBusAccess.md b/Documentation/SMBusAccess.md
new file mode 100644
index 00000000..70a2cc66
--- /dev/null
+++ b/Documentation/SMBusAccess.md
@@ -0,0 +1,44 @@
+# SMBus Access
+
+This document details the process to set up SMBus/I2C access on supported operating systems.
+
+SMBus, or [System Management Bus](https://en.wikipedia.org/wiki/System_Management_Bus), is a low-level interface present on most PC motherboards. Some RGB control devices are attached via SMBus. These include all DDR4 and DDR5 RAM modules with integrated RGB lighting as well as the onboard lighting on several motherboards, mostly from the X370/Z270 and X470/Z370 generations.
+
+If you are not using RGB RAM and you are not using a motherboard from the X370/Z270 or X470/Z370 generation you can skip these steps and ignore the SMBus warning if it appears.
+
+SMBus is generally not meant to be accessed by user applications, but RGB software creates an exception to this rule. This means that some steps may be necessary to allow OpenRGB permission to access the SMBus interface. These steps are listed below.
+
+## Windows
+
+ * On Windows, OpenRGB uses the [WinRing0](https://github.com/GermanAizek/WinRing0) driver to access the SMBus interface.
+ * **You must run the application as Administrator the first time to allow WinRing0 to set up. It can be run as a normal user afterwards**
+ * Early versions of OpenRGB used [InpOut32](https://www.highrez.co.uk/downloads/inpout32/). This is no longer needed and should be removed to avoid warnings by some anti-cheat software. You can uninstall Inpout32 by following the instructions [here](https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/669#note_461054255).
+
+## Linux
+
+ 1. Install the `i2c-tools` package.
+ 2. Load the i2c-dev module: `sudo modprobe i2c-dev`
+ 3. Load the i2c driver for your chipset:
+ * Intel
+ * `sudo modprobe i2c-i801`
+ * `sudo modprobe i2c-nct6775` - Secondary controller for motherboard LEDs (requires [kernel patch](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/OpenRGB-Kernel-Patch.md))
+ * AMD
+ * `sudo modprobe i2c-piix4`
+
+ * If you want the i2c modules to load automatically at boot, run the following:
+ 1. `sudo touch /etc/modules-load.d/i2c.conf`
+ 2. `sudo sh -c 'echo "i2c-dev" >> /etc/modules-load.d/i2c.conf'`
+ 3. Run the following based on which i2c drivers you loaded in the previous section:
+ * `sudo sh -c 'echo "i2c-i801" >> /etc/modules-load.d/i2c.conf'`
+ * `sudo sh -c 'echo "i2c-piix4" >> /etc/modules-load.d/i2c.conf'`
+
+ * You will have to enable user access to the i2c devices if you don't run OpenRGB as root.
+ 1. List all SMBus controllers: `sudo i2cdetect -l`
+ 2. Note the number(s) for piix4 or i801 controllers.
+ 3. Give user access to those controllers. If you have not installed OpenRGB from a distribution package then most likely you need to install the udev rules manually.
+
+ * Some Gigabyte/Aorus motherboards have an ACPI conflict with the SMBus controller. You can bypass this conflict by adding the `acpi_enforce_resources=lax` kernel parameter to your kernel command line. See the [Kernel Parameters](Documentation/KernelParameters.md) page for more information.
+
+## MacOS
+
+ * For Intel devices using a controller in the i801 family you have to download and install the [macUSPCIO driver](https://github.com/ShadyNawara/macUSPCIO/releases)
diff --git a/Documentation/USBAccess.md b/Documentation/USBAccess.md
new file mode 100644
index 00000000..d8462dfd
--- /dev/null
+++ b/Documentation/USBAccess.md
@@ -0,0 +1,23 @@
+# USB Access
+
+This document details the process to set up USB access on supported operating systems.
+
+USB, or [Universal Serial Bus](https://en.wikipedia.org/wiki/USB) is the most common interface used to connect RGB devices to a PC. It can be used both externally, where a device has a cable which plugs into a USB port or motherboard header, or internally, where a device such as an RGB controller chip built into a motherboard is wired directly to the processor or chipset's USB interface.
+
+USB access permissions vary based on the type of device and the operating system. Some steps may be necessary to allow OpenRGB permission to access these devices.
+
+## Windows
+
+ * Windows should not need any special setup to access USB devices.
+ * If a device does not get detected, try running OpenRGB as Administrator.
+ * Early versions of OpenRGB used the WinUSB driver, installed using Zadig. This is no longer required, and you need to uninstall the WinUSB driver if you previously installed it. You can uninstall the WinUSB driver by following [this guide](https://gitlab.com/CalcProgrammer1/OpenRGB/-/wikis/Frequently-Asked-Questions#i-installed-the-winusb-driver-for-a-device-and-i-wish-to-uninstall-it).
+
+## Linux
+
+ * USB devices require [udev rules](Documentation/UdevRules.md) to access as a normal user.
+ * Alternatively you can run OpenRGB as root to detect all USB devices. (Not recommended)
+ * USB based Gigabyte AORUS motherboards may also have an ACPI conflict. Please [add a kernel parameter](#kernel-parameters) to resolve this conflict.
+
+## MacOS
+
+ * USB devices may require the Input Monitoring permission. You can add OpenRGB in System Preferences > Security & Privacy > Privacy.
diff --git a/Documentation/UdevRules.md b/Documentation/UdevRules.md
new file mode 100644
index 00000000..d6360486
--- /dev/null
+++ b/Documentation/UdevRules.md
@@ -0,0 +1,16 @@
+# Udev Rules
+
+On Linux, OpenRGB provides a udev rules file to configure access permissions to supported devices.
+
+If you install OpenRGB through a distribution-specific package, whether provided by your distribution's official repositories, from packages downloaded from OpenRGB's website or GitLab CI, or from building packages yourself, the udev rules should be installed as part of that package. You should not need to manually install them.
+
+If you are using OpenRGB compiled from source (not as part of a package), using OpenRGB as an AppImage, or using OpenRGB from Flatpak, you will need to install the udev rules manually.
+
+## Installation
+
+ * If you have installed OpenRGB from a package then latest udev rules are installed locally at `/usr/lib/udev/rules.d/60-openrgb.rules`
+ * Udev rules are built from the source at compile time. When building locally they are installed with the `make install` step to `/usr/lib/udev/rules.d/60-openrgb.rules`
+ * If you need to install the udev rules file manually you can also download the [latest compiled udev rules](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/raw/60-openrgb.rules?job=Linux+64+AppImage&inline=false) from Gitlab.
+ - Copy this 60-openrgb.rules file to `/usr/lib/udev/rules.d/`
+ - Then reload rules with `sudo udevadm control --reload-rules && sudo udevadm trigger`
+ * There is also a [udev rules installation script available at openrgb.org](https://openrgb.org/udev.html).
diff --git a/README.md b/README.md
index 12fcd54e..1133d5eb 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,9 @@
-## 
+## 
- 
+
One of the biggest complaints about RGB is the software ecosystem surrounding it. Every manufacturer has their own app, their own brand, their own style. If you want to mix and match devices, you end up with a ton of conflicting, functionally identical apps competing for your background resources. On top of that, these apps are proprietary and Windows-only. Some even require online accounts. What if there was a way to control all of your RGB devices from a single app, on both Windows and Linux, without any nonsense? That is what OpenRGB sets out to achieve. One app to rule them all.
-[[_TOC_]]
-
## Features
* Set colors and select effect modes for a wide variety of RGB hardware
@@ -18,6 +16,8 @@ One of the biggest complaints about RGB is the software ecosystem surrounding it
* No official/manufacturer software required
* Graphical view of device LEDs makes creating custom patterns easy
+
+
## Website
* Check out our website at [openrgb.org](https://openrgb.org)
@@ -26,225 +26,31 @@ One of the biggest complaints about RGB is the software ecosystem surrounding it
* See the [Supported Devices](https://openrgb.org/devices.html) page for the current list of supported devices.
-## Wiki
-
-* More information is available on the [OpenRGB Wiki](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/home.md)
-
## WARNING!
-This project interacts directly with hardware using reverse engineered protocols. While we do our best to make sure we're sending the right data, there is always some risk in sending data to hardware when we don't understand exactly how that hardware works.
+This project interacts directly with hardware using reverse engineered protocols. While we do our best to make sure we're sending the right data, there is always some risk in sending data to hardware when we don't understand exactly how that hardware works. There have been issues in the past with certain hardware getting damaged/bricked and we have either disabled or fixed the offending code. That said, with OpenRGB always changing and the landscape of RGB devices being of widely varying quality, we can't guarantee it won't happen again. By installing and using OpenRGB you accept this risk.
-There have been two instances of hardware damage in OpenRGB's development and we've taken precautions to prevent it from happening again.
+## Download OpenRGB
- * The Mystic Light motherboard code bricked the RGB controller of some MSI motherboards. The code was disabled and reworked. We have been re-adding these motherboards to the support list as we verify that the new code works with them. Affected boards can be unbricked with a Nuvoton Nu-Link adapter.
- * There were reports of bricked Gigabyte Aorus Z390 motherboards caused by dumping SMBus address 0x68 in an attempt to reverse engineer the RGB. Due to this, the SMBus Tools page on OpenRGB is hidden by default now as it has no real use to non-developers.
+ * Pre-built binaries are available for the following platforms:
+ * Windows
+ * Linux (AppImage, .deb, and .rpm)
+ * MacOS
+ * Released versions are available to download on [OpenRGB.org](https://openrgb.org/releases.html) or under [Releases](https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/permalink/latest).
+ * Experimental (aka Pipeline) versions are available to download on [OpenRGB.org](https://openrgb.org/index.html#pl).
+ * On Windows, you will need the **Microsoft Visual 2019 C++ runtime** installed. You can get it [here](https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads).
+ * An unofficial Flatpak release is [available on Flathub](https://flathub.org/apps/details/org.openrgb.OpenRGB)
+ * Note: If using the AppImage or Flatpak versions, ensure you [install the latest udev rules](Documentation/UdevRules.md).
+ * Released versions are officially packaged for various distributions including Alpine, Fedora, and Arch.
+ * Arch users can also install from the AUR for both the [release](https://aur.archlinux.org/packages/openrgb/) and [pipeline](https://aur.archlinux.org/packages/openrgb-git/) versions.
-
+## Compile OpenRGB
-## Windows
+ * Instructions for compiling from source are [available here](Documentation/Compiling.md).
- * You will need the **Microsoft Visual 2019 C++ runtime** installed. You can get it [here](https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)
- * Pre-built Release binaries are available for Windows 10 / 11 64bit under the [Releases section](https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/permalink/latest#Windows-64-bit) on GitLab.
- * If you want to test the latest (potentially unstable) code you can also get the Windows package from [the pipeline builds](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/download?job=Windows+64).
+## Setup Device Access
-
- Compiling
-
- * To build the application yourself on Windows:
- 1. Download the latest [Visual Studio Community Edition](https://visualstudio.microsoft.com/thank-you-for-downloading-visual-studio-for-cplusplus/?sku=Community)
- and [Qt Creator](https://www.qt.io/download-thank-you).
- 2. When [installing the QT toolset](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/Downloading%20Qt%20and%20building%20OpenRGB.md)
- select the latest revision of Qt 5.15.x as OpenRGB is not yet compatible with QT6
- 3. Optionally [install Git](https://git-scm.com/download) if you intend to
- [contribute your changes](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/CONTRIBUTING.md)
- to the mainline codebase.
- 4. Open the OpenRGB.pro project in Qt Creator.
- 5. Use the MSVC compiler kit, either 32- or 64-bit, to build the application.
- 6. Run the project from Qt Creator. If you want to use your custom build standalone, download the latest matching Release package and replace the OpenRGB.exe in it with your new build.
-
-
-
- ----
-
-### SMBus Access
- * **You must run the application as Administrator the first time to allow WinRing0 to set up. It can be run as a normal user afterwards**
- * Early versions of OpenRGB used InpOut32. This is no longer needed and should be removed to avoid warnings by some anti-cheat software. You can uninstall Inpout32 by following the instructions [here](https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/669#note_461054255).
-
-### USB Access
-
- * Early versions of OpenRGB used the WinUSB driver, installed using Zadig. This is no longer required, and you need to uninstall the WinUSB driver if you previously installed it. You can uninstall the WinUSB driver by following [this guide](https://gitlab.com/CalcProgrammer1/OpenRGB/-/wikis/Frequently-Asked-Questions#i-installed-the-winusb-driver-for-a-device-and-i-wish-to-uninstall-it).
-
-## Linux
-
- * Pre-built binaries in AppImage format are available under the [Releases](https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/permalink/latest#Linux-64-bit) section on GitLab.
- * There is also a unofficial universal Flatpak build [available on Flathub](https://flathub.org/apps/details/org.openrgb.OpenRGB). Note: To ensure you have device permissions please [install the latest UDEV rules](#installing-udev-rules-manually).
-
-
- Arch
-
-##### Binaries
-
- * OpenRGB is available in the AUR for both the [release](https://aur.archlinux.org/packages/openrgb/) and [pipeline](https://aur.archlinux.org/packages/openrgb-git/) builds
-
-
-
- Debian / Ubuntu
-
-##### Binaries
-
- * OpenRGB builds an official Debian package for Bullseye and Ubuntu 21.04 onwards for both the 64bit [release](https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/permalink/latest#Debian-Bullseye-amd64) and [pipeline](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/download?job=Linux+64+.deb+%28Debian+Bullseye%29) builds
- * There is also a legacy package for Debian 64bit Buster and it's derivatives (Ubuntu prior to 21.04) with [release](https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/permalink/latest#Debian-Buster-amd64) and [pipeline](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/download?job=Linux+64+.deb+%28Debian+Buster%29) builds
-
-##### Compiling
-
- 1. Install build dependencies
- - `sudo apt install git build-essential qtcreator qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools libusb-1.0-0-dev libhidapi-dev pkgconf libmbedtls-dev qttools5-dev-tools`
- 2. git clone https://gitlab.com/CalcProgrammer1/OpenRGB
- 3. cd OpenRGB
- 4. qmake OpenRGB.pro
- 5. make -j$(nproc)
- 6. You can then run the application from the compile directory with `./openrgb` or install with `make install`
- 7. You will also need to [install the latest UDEV rules](#installing-udev-rules-manually).
-
-##### Packaging
-
- * You can also build a Debian package (.deb) from this source code with:
- - `sudo apt install debhelper`
- - `/scripts/build-package-files.sh debian/changelog`
- - `dpkg-buildpackage -us -B`
-
-
-
- Fedora
-
-##### Binaries
-
-* OpenRGB builds an official Fedora package for the latest [release](https://gitlab.com/CalcProgrammer1/OpenRGB/-/releases/permalink/latest#Linux-64-bit) of OpenRGB
-* There are also pipeline builds for both [Fedora 35](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/download?job=Linux+64+f35+rpm) and
- [Fedora 36](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/download?job=Linux+64+f36+rpm) available
-
-##### Compiling
-
- 1. Install build dependencies
- - `sudo dnf install automake gcc-c++ git hidapi-devel libusbx-devel mbedtls-devel pkgconf qt5-qtbase-devel qt5-linguist`
- 2. git clone https://gitlab.com/CalcProgrammer1/OpenRGB
- 3. cd OpenRGB
- 4. qmake-qt5 OpenRGB.pro
- 5. make -j$(nproc)
- 6. You can then run the application from the compile directory with `./openrgb` or install with `make install`
- 7. You will also need to [install the latest UDEV rules](#installing-udev-rules-manually).
-
-
-
- ----
-
-### SMBus Access
-
- * SMBus access is necessary for controlling RGB RAM and certain motherboard on-board LEDs.
- * If you are not trying to use OpenRGB to control RGB RAM or motherboard LEDs, you may skip this section.
- * ASUS and ASRock motherboards have their RGB controller on a secondary SMBus interface and requires a Linux kernel > 5.7 [commit](https://github.com/torvalds/linux/commit/f27237c174fd9653033330e4e532cd9d153ce824)
- * Allowing access to SMBus:
- 1. Install the `i2c-tools` package.
- 2. Load the i2c-dev module: `sudo modprobe i2c-dev`
- 3. Create the i2c group if it does not already exist: `sudo groupadd --system i2c`
- 4. Add yourself to the i2c group: `sudo usermod $USER -aG i2c`
- 5. If you want you can load the i2c-dev module at boot: `sudo touch /etc/modules-load.d/i2c.conf && sudo sh -c 'echo "i2c-dev" >> /etc/modules-load.d/i2c.conf'`
- 6. Load the i2c driver for your chipset:
-
- Intel
-
- * `sudo modprobe i2c-i801`
- * `sudo modprobe i2c-nct6775` - Secondary controller for motherboard LEDs (requires [kernel patch](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/OpenRGB-Kernel-Patch.md))
-
-
-
- AMD
-
- * `sudo modprobe i2c-piix4`
- * Unmodified kernel will have one interface, patched kernel will have two. The first at 0x0B00 and the second at 0x0B20. The 0x0B20 interface is for motherboard LEDs.
-
-
-
- * If RGB RAM or certain motherboard on-board LEDs are not loading the profile on startup, you need to add the loading entries to: `/etc/modules-load.d/`
- - i2c-dev
- - i2c-i801 or i2c-piix4 (according to your chipset)
-
- ----
-
- * You'll have to enable user access to your SMBus if you don't run as root.
- - List all SMBus controllers: `sudo i2cdetect -l`
- - Note the number for PIIX4, I801, and NCT6775 controllers.
- - Give user access to those controllers. If you have not installed OpenRGB from a package (e.g. deb, RPM or from the AUR) then most likely you need to [install the UDEV rules](#installing-udev-rules-manually).
- * The i2c-nct6775 kernel module requires patching, please refer to [instructions here](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/OpenRGB-Kernel-Patch.md)
- * Some Gigabyte/Aorus motherboards have an ACPI conflict with the SMBus controller. Please [add a kernel parameter](#kernel-parameters) to resolve this conflict.
-
-### USB Access
-
- * USB devices require [udev rules](#installing-udev-rules-manually) to access as a normal user.
- * Alternatively you can run OpenRGB as root to detect all USB devices. (Not recommended)
- * USB based Gigabyte AORUS motherboards may also have an ACPI conflict. Please [add a kernel parameter](#kernel-parameters) to resolve this conflict.
-
-### Installing UDEV rules manually
-
- * If you have installed OpenRGB from a package then latest UDEV rules are installed locally at `/usr/lib/udev/rules.d/60-openrgb.rules`
- * Flatpak and Appimage "packages" will need to install this file manually.
- * Udev rules are built from the source at compile time. When building locally they are installed with the `make install` step to `/usr/lib/udev/rules.d/60-openrgb.rules`
- * If you need to install the UDEV rules file manually you can also download the [latest compiled udev rules](https://gitlab.com/CalcProgrammer1/OpenRGB/-/jobs/artifacts/master/raw/60-openrgb.rules?job=Linux+64+AppImage&inline=false) from Gitlab.
- - Copy this 60-openrgb.rules file to `/usr/lib/udev/rules.d/`
- - Then reload rules with `sudo udevadm control --reload-rules && sudo udevadm trigger`
-
-### Kernel Parameters
-
- * To resolve an ACPI conflict add the `acpi_enforce_resources=lax` kernel parameter.
- * If you want to check if the kernel was loaded with this option you can execute this command from the terminal once you've rebooted.
- * `cat /proc/cmdline`
-
-
- Arch
-
- * Please see [the Arch wiki](https://wiki.archlinux.org/title/kernel_parameters) for details on how to update your bootloader.
-
-
-
- Debian / Ubuntu
-
- * Please see [the Ubuntu Documentation](https://wiki.ubuntu.com/Kernel/KernelBootParameters) for Kernel Parameters for more information on updating your boot parameters.
-
-
-
- Fedora
-
- * On Fedora, install `grubby` and then following command:
- `grubby --update-kernel=ALL --args="acpi_enforce_resources=lax"`
- * For more information please refer to the Fedora docs for [grubby](https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool).
-
-
-
- ----
-
-## MacOS
-
- * Pre-built binaries in zipped application package format are available under the Releases section on GitLab.
- * You can build the project using Qt Creator or on the command line.
- 1. Install build dependencies with Homebrew
- - Install Homebrew by following the instructions at https://brew.sh/
- - brew install git qt5 hidapi libusb mbedtls@2
- - brew link qt5
- 2. [Create a local certificate](https://support.apple.com/guide/keychain-access/create-self-signed-certificates-kyca8916/mac) called OpenRGB with code signing capability
- 3. git clone https://gitlab.com/CalcProgrammer1/OpenRGB
- 4. cd OpenRGB
- 5. qmake OpenRGB.pro
- 6. make -j8
- 7. macdeployqt OpenRGB.app -codesign=OpenRGB
- 8. Copy the OpenRGB.app application package to Applications
-
-### SMBus Access
-
- * For Intel devices using a controller in the I801 family you have to download and install the [macUSPCIO driver](https://github.com/ShadyNawara/macUSPCIO/releases)
-
-### USB Access
-
- * USB devices may require the Input Monitoring permission. You can add OpenRGB in System Preferences > Security & Privacy > Privacy.
+ * After installing OpenRGB, please see the [SMBus Access](Documentation/SMBusAccess.md) and [USB Access](Documentation/USBAccess.md) pages for instructions on setting up access to your RGB devices.
## Join Our Discord
@@ -272,9 +78,9 @@ There have been two instances of hardware damage in OpenRGB's development and we
## Contributing
-* Want to contribute support for a new device? Check out the [RGBController API](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/Developer-Documentation/The-RGBController-API.md) page for documentation of how OpenRGB implements device control.
-* Want to create a new OpenRGB SDK client implementation? Check out the [OpenRGB SDK Documentation](https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/Developer-Documentation/OpenRGB-SDK-Documentation.md) page for documentation of how the OpenRGB SDK network protocol functions.
-* Please read the [Contributing Guidelines](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/CONTRIBUTING.md) before starting work on your new changes.
+* Want to contribute support for a new device? Check out the [RGBController API](Documentation/RGBControllerAPI.md) page for documentation of how OpenRGB implements device control.
+* Want to create a new OpenRGB SDK client implementation? Check out the [OpenRGB SDK Documentation](Documentation/OpenRGBSDK.md) page for documentation of how the OpenRGB SDK network protocol functions.
+* Please read the [Contributing Guidelines](CONTRIBUTING.md) before starting work on your new changes.
## OpenRGB SDK