Add support for styli from vendors other than Wacom #759
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
whot
force-pushed
the
wip/vendor-styli
branch
from
a5ac3bd to
173b144
Compare
This is preparation work to add a vendor ID for styli in the future. Rename the current single-item "id" to "tool_id" for a future vid/tool_id pair.
whot
force-pushed
the
wip/vendor-styli
branch
2 times, most recently
from
568ade6 to
545ea96
Compare
We need to free the list returned
The current API uses tool IDs that are bound to Wacom devices (currently only wacom devices use those). If we have styli from other vendors that use the same tool ID we cannot currently express this without having duplicates. This patch introduces an internal WacomStylusId struct with vid and tool_id and switches the internal code over to use that. It deprecates the current stylus id functions and replaces them with a set that returns the WacomStylus pointer to the caller instead of just the id. Where the id is actually used, the caller can then query that struct. A special case are the @Generic styli which are assigned a VID of zero. Internal behaviour treats Wacom styli still special: styli with the 0x56a vendor id will not have a vid prefix but just the default tool id. Likewise, the legacy functions libwacom_get_supported_styli() only returns Wacom and the generic styli.
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.
This adds support for styli that aren't implicitly wacom styli.
Right now our API supports two types of styli: the few generic ones with IDs that wacom doesn't (hopefully won't ever) use. And all other real styli with actual ids but those are assumed to be Wacom styli - if any other vendor starts using IDs (possibly the one in #636 but it's not fully clear whether it is a true stylus id) we are running into issues because we won't be able to differentiate.
This patch adds a vendor id to the
WacomStylusand the associated APIs. The generic pens have a vendor id of 0, everything else defaults to 0x56a unless explicitly specified otherwise.The current set of APIs is deprecated and replaced with an API that returns a
WacomStylusinstead of just an id, e.g.const int * libwacom_get_supported_styli()is superseded byconst WacomStylus ** libwacom_get_styli()and the same approach for theget_pairedAPI.Unlike the previous APIs the return value is an allocated list that must be freed by the caller (but not the list contents). It's IMO the better API and clients should switch to that because "here is $thing" is a lot more sane than "here's a magic number, now look it up so I can give you $thing" even if the actual functionality doesn't matter for now :)
Closes #639
Not 100% if returning this as
const WacomStylusis the right idea, it effectively prohibits us from ever doing anything with the stylus in the future, even if it's justwacom_stylus_ref()(if we add this). OTOH doing even that would require a major rework of libwacom's internals and the use of that is quite limited - callers can copy the few properties that they need.