-
-
Notifications
You must be signed in to change notification settings - Fork 40.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding the Ploopy Thumb #14668
Adding the Ploopy Thumb #14668
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.noci
file can be deleted, as Travis isn't running anymore.
I'm having an issue where the up / down axis of the ball is reversed when building a firmware using this PR. The left / right axis is fine. The default keymap also doesn't work properly on Linux (haven't tried other operating systems). The default keymap is That puts the DPI on left side small lower button, the back button on the left side small top button and the forward button on the 3rd rightmost button. This works as intended : |
Setting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting
mouse_report.y
to-mouse_report.y
inpointing_device_task_kb()
fixes the inverted trackball y axis, although I've not tested if it interferes with the drag scroll conditional block since I'm not using that.
Sounds like it needs POINTING_DEVICE_INVERT_X
defined in the keyboard's config.h file then.
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Will squash...this is getting a bit out of hand. |
No need, we squash when merging, so won't matter either way. |
Co-authored-by: Ryan <fauxpark@gmail.com>
Trying to build this PR and it's not happy - what am I doing wrong here (I haven't even got to making changes)?
|
Looks like the most recent commit (dd28d4c) broke it, as the previous commit builds just fine for me. Shouldn't CI have picked that up? I found all of the DPI settings too sensitive for my liking, and have seen other reports in reddit like this, so perhaps it's worth adding another value or two at the lower end as part of this PR. |
Sorry, that was my bad. I have pushed a fix for it. |
We don't have CI anymore, unfortunately. travis-ci.org is defunct, and the replacement doesn't really work for our needs. |
Co-authored-by: Nick Brassel <nick@tzarc.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is the correct place for this, but I own one of the devices and thought I'd be able to contribute my findings.
If you prefer an issue in your fork, I'll happily move my comments there.
# define OPT_THRES 150 // (0-1024) Threshold for actication | ||
#endif | ||
#ifndef OPT_SCALE | ||
# define OPT_SCALE 1 // Multiplier for wheel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OPT_SCALE
doesn't seem to do anything right now. Is this meant as a placeholder?
Same goes for OPT_THRES
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the scale used to do something, but that has changed, andt he code needs to be cleaned up (all of the ploopy devices need to be)
#ifdef PLOOPY_DRAGSCROLL_FIXED | ||
pointing_device_set_cpi(is_drag_scroll ? PLOOPY_DRAGSCROLL_DPI : dpi_array[keyboard_config.dpi_config]); | ||
#else | ||
pointing_device_set_cpi(is_drag_scroll ? (dpi_array[keyboard_config.dpi_config] * PLOOPY_DRAGSCROLL_MULTIPLIER) : dpi_array[keyboard_config.dpi_config]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't recognize any difference in speed while dragscrolling. Whatever values I set for PLOOPY_DRAGSCROLL_FIXED
, PLOOPY_DRAGSCROLL_DPI
or PLOOPY_DRAGSCROLL_MULTIPLIER
, the dragscroll speed always seems to be the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this fixed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No.
But I was able to integrate the changes from https://gist.github.com/patm1987/4ee78e8727bb4c5a1bbd5f2279b4e79d
into my Fork
Look at the _dragscroll_accumulator_x
and _dragscroll_accumulator_y
variables and how they are used.
This way I was able to set the dragscroll speed to my liking.
I'd be up to create a pull request to ploopyco if wanted. But I don't think the current state (of my changes) is remotely production ready, so I'd have to put in some work to make it cleaner and configurable for the user.
Thank you for your contribution! |
Thank you for your contribution! |
@ploopyco would you mind if I take over this PR? |
closing in favor of #18214 |
Added an implementation for the upcoming Ploopy Thumb.
Description
Just a bit of configuration stuff. Nothing new or groundbreaking; most of the code is a straight duplicate from the Ploopy Classic (keyboards/ploopyco/trackball).
Types of Changes
Issues Fixed or Closed by This PR
Checklist