-
Notifications
You must be signed in to change notification settings - Fork 58
Bottom edge button zones feature (to emulate traditional trackpad) #110
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
Open
ijackson
wants to merge
6
commits into
rynbrd:master
Choose a base branch
from
ijackson:for-upstream.button-zones
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or 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
These are going to be needed to cope properly with pads whose origins are not at (0,0). Signed-off-by: Ian Jackson <[email protected]>
On a trackpad whose ymin is not zero, this calculation was wrong. My trackpad has ymin==0, but another I have access to does not. The latter was fixed by this change. Signed-off-by: Ian Jackson <[email protected]>
When button zones are in use, the code attempts to calculate which zone the finger is in. The left and right edges of the zones are calculated according the nths of pad_width, where n is the number of zones. These left and right sides are compared with `pos', and the zone is the one where left<=pos<=right. This would all be correct if pos were the touch's x coordinate measured from the pad minimum. However, inexplicably, pad_width/2 is used instead of the pad minimum x coordinate. The git history does not reveal an explanation for this. I guess it must have been empirical. Using the xmin value makes the button zone code work on the two laptops I have to test, here, one with xmin==0 and the other with xmin=1200,xmax=4600. Signed-off-by: Ian Jackson <[email protected]> --- v2: This patch redone in the light of the fact that the origin is not always (0,0)
I intend to add a new feature BottomEdgeZones which reuses the Zone machinery, but is going to use a different source for the effective X coordinate which selects the zone. Break out the computation of `pos'. pos==-1 means the zone feature is not in use or not applicable to the event. No functional change in this commit. Signed-off-by: Ian Jackson <[email protected]> --- v2: Cope properly with negative "pos" values.
Many modern laptops have a clickpad, with some faint legend on the surface suggesting that the bottom portion is a pair (usually) of buttons. Some users who are used to laptops which had separate physical buttons below the trackpad have developed the habit of putting one finger on the physical button, and using another finger to mouse. This user behaviour can be supported if we: - ignore touches in the "button" area for all purposes, except - decide which button was pressed, if the user clicks the clickpad, by looking at which touch(es) are present in the button area This is a novel combination of the behaviours of the BottomEdge and ButtonZones options. Provide a new BottomEdgeZonesEnable option, (including documentation and static configuration). The current code does not support users who have a habit of generating and using chorded button events on mice with physical buttons. (That is, users who have configured application(s) to process simultaneous clicks of different buttons meaningfully differently to single-button clicks.) I think this should be regarded as a bug in the implementation I am introducing in this patch. Fixing this would be feasible without new config options or changes to other semantics but would involve more rework of the zone processing in gestures.c than I currently have time for. Signed-off-by: Ian Jackson <[email protected]> --- v2: Cope with negative "pos" values.
…SETTINGS For backward compatibility this property can now be either 3 or 4 items. When we generate it, we generate 4 items, but we accept setting only 3 items. Signed-off-by: Ian Jackson <[email protected]>
2c69580
to
853b5fb
Compare
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.
With these patches, xf86-input-mtrack can be used to get a clickpad to more closely emulate a traditional trackpad with separate buttons, by setting BottomEdge, BottomEdgeZonesEnable, and disabling ButtonZones.
Also, some anomalies in pad xmin and ymin offset handling are fixed. (v2 of this series)