Option to disable rumble connection notification #149
Labels
Milestone
Comments
|
Good idea and should be super easy to implement. I am open to PR's :) I am too busy a.t.m |
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 3, 2020
According to hid-microsoft.c, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 3, 2020
According to hid-microsoft.c, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 4, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 4, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 5, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 5, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 5, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 5, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 6, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 6, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 6, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 6, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 7, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 7, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 7, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
to kakra/xpadneo
that referenced
this issue
May 7, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: atar-axis#154 Affects: atar-axis#149 Maybe-related: atar-axis#171 Maybe-related: atar-axis#122 Signed-off-by: Kai Krakow <[email protected]>
kakra
added a commit
that referenced
this issue
May 8, 2020
According to `hid-microsoft.c`, the device supports magnitudes in the range of 0..100. This commit scales the magnitudes correctly from 0..65535 to 0..100 and also uses a finer scale for the pre-calculated cosine table to have more than 4 steps on each trigger. Additionally, it considerably reduces the strength of the connection notification rumble. The controller no longer tends to hop down the table. I don't have any specs of this but sending too high values may affect the stability of the firmware thus this may reduce connection losses observed in some issue reports. This also removes the over-use of blank lines: It confuses git during rebase as it allows splitting logical self-contained hunks into seemingly unrelated blocks on too many opportunities. Closes: #154 Affects: #149 Maybe-related: #171 Maybe-related: #122 Signed-off-by: Kai Krakow <[email protected]>
ghost
mentioned this issue
|
This has been implemented. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Please provide option do disable rumble effect that notifies you about successful connection to the device.
Describe the solution you'd like
An additional option in configuration menu to disable rumble connection notification (as opposed to disabling rumble altogether)
Describe alternatives you've considered
NA
Additional context
NA
The text was updated successfully, but these errors were encountered: