Implementing AutoMouseLayer Feature in Keyball Firmware #454
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
0.22.3 (QMK version which Keyball using) has problem on auto mouse layer feature and it fixed with 0.22.11 |
|
I'll update QMK 0.22.14 which is last version 0.22.x. |
koron
reviewed
Mar 21, 2024
| @@ -127,6 +145,10 @@ void pointing_device_driver_init(void) { | |||
| if (keyball.this_have_ball) { | |||
| pmw3360_cpi_set(CPI_DEFAULT - 1); | |||
| pmw3360_reg_write(pmw3360_Motion_Burst, 0); | |||
|
|
|||
| #ifdef POINTING_DEVICE_AUTO_MOUSE_ENABLE | |||
| set_auto_mouse_layer(1); | |||
There was a problem hiding this comment.
Auto mouse layer should be changed for each keymaps.
Right now, all the keymaps happen to use layer 1 for the mouse, but essentially it should be able to be changed for each keymap.
I'll fix this.
|
I'm woking in #508 |
|
merged with #508 |
koron
added a commit
to koron/qmk_firmware
that referenced
this pull request
Mar 24, 2024
|
Hi guys! I am wondering if it's possible to enable the feature whenever it boots? As far as I can tell, this feature is disabled by default. I need to enable it by pressing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
https://docs.qmk.fm/#/feature_pointing_device?id=pointing-device-auto-mouse
AutoMouseLayer feature has been implemented in QMK. Keyball has a Pointing Device implemented, making it a perfect match for AutoMouseLayer. The implementation of AutoMouseLayer enables the automatic switching of layers after mouse movement, thus it simplifies the operation of a pointing device with one hand.
Design
In order to integrate the AutoMouseLayer into the firmware, it is necessary to have a mechanism to keep track of the use cases and configurations of the AutoMouseLayer. We will implement three types of custom keycodes:
The states will be saved in EEPROM. The items stored in the EEPROM are as follows:
Details of storing timeout time
For comfortable use of AutoMouseLayer, it becomes necessary to adjust the timeout based on personal preferences. This is because everyone has a unique response speed. If the timeout is too long, one might have to wait for the AutoMouseLayer to end before one can input keys. If it is too short, there might not be enough time to make use of AutoMouseLayer. Based on the QMK documentation, a possible timeout setting range is from 250 msec to 1000 msec. However, we consider that having control with granularity of 50 msec steps from 250 msec to 950 msec should be sufficient. Hence, a formula of "(n-1)*50+250", where 'n' is the number saved in EEPROM, is being used to calculate the actual timeout. This provides a mechanism to store the timeout state in 4 bits. This portion of the design is up for discussion, such as whether to widen the value range, or save bit count by having larger steps than 50 msec.
Firmware Size
Implementing these features will increase firmware size. However, even for Keyball61, it should fit if one LED effect is removed. In this patch, we have disabled
RGBLIGHT_EFFECT_KNIGHT.Placement of AutoMouseLayer
In the current firmware, mouse keys are set on Layer 1. Hence, we are using
set_auto_mouse_layer(1)for implementing AutoMouseLayer.OLED
To display the status of the AutoMouseLayer on the OLED, it might be necessary to free up existing areas. While it is possible to delete any content for displaying this feature, deciding what to remove proved to be rather challenging. Currently, a new method has been defined, for the display of this information. Integration into the current display by removing the Layer display or another existing component, is another possible approach.