-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Make extended controller information available for device selection #13896
base: main
Are you sure you want to change the base?
Make extended controller information available for device selection #13896
Conversation
…1.2 copy in the lib directory.
Refactor: Use getters and improve protocol handling
…worthy than the human-readable VendorString and ProductString provided by the device driver
… JSON attachment from HID Usage Table 1.5 PDF file)
Refactored recognizeDevice to be a member of HidEnumerator
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.
thank you very much for this valuable PR. I only have one high-level complaint. Codestyle nitpicks follow in a separate review.
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.
couple nitpicks
<item row="0" column="0"> | ||
<widget class="QGroupBox" name="groupBoxDeviceInfo"> | ||
<property name="sizePolicy"> | ||
<sizepolicy hsizetype="Preferred" vsizetype="Preferred"> | ||
<horstretch>0</horstretch> |
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.
are these device infos visible all the time? Are the relevant to all users all the time? Would it make sense to hide it behind --developer
or --controller-debug
?
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.
--controllerDebug and later an always visible, collapsible region?
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.
This informaton is also intended for the end-user! An end-user needs it to identify the correct device out of many with similar names. It should be visible for the end-user by default therefore.
But once the end-user identified the correct device, and the mapping is successful loaded and working, he no longer needs these details.
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.
right, but how user friendly is that? In the long-term we probably need a different mechanism for identifying devices...
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.
Yes, the long term target is Plug&Play. That is why I make the device data accessible in this first step.
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.
nice. So leave like this for now and --developer
once plug'n'play is achieved?
…esdata.h. Added hid_usagepages_json2cppheader.py script to create C++ header from official JSON source Modified related classes accordingly.
d74a1c5
to
84eed81
Compare
…num into a utility function and call it n ctor init list Reordered the member initializations in the constructor to match the order of their declarations
f73b245
to
3882a86
Compare
static const QMap<PhysicalTransportProtocol, QString> protocolMap = { | ||
{PhysicalTransportProtocol::USB, QStringLiteral("USB")}, | ||
{PhysicalTransportProtocol::BlueTooth, QStringLiteral("Bluetooth")}, | ||
{PhysicalTransportProtocol::I2C, QStringLiteral("I2C")}, | ||
{PhysicalTransportProtocol::SPI, QStringLiteral("SPI")}, | ||
{PhysicalTransportProtocol::FireWire, QStringLiteral("Firewire - IEEE 1394")}, | ||
{PhysicalTransportProtocol::UNKNOWN, tr("Unknown")}}; | ||
|
||
return protocolMap.value(protocol, tr("Unknown")); |
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.
why the map over a switch-case
?
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.
It doesn't matter here, but in general, a map scales better in lookup performance. So it's just use of the common pattern.
|
||
enum class PhysicalTransportProtocol : uint8_t { |
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 the explicit type necessary for ABI compatibility?
bool isValid() const { | ||
return !getProductString().isNull() && !getSerialNumber().isNull(); | ||
} |
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.
are you sure all hid devices have a productstring and serial number they report? Why do exactly these attributes make the device "valid"? What does valid mean in this context? Usually objects that are not valid result in UB if you call most member functions on them, but thats not the case here, afaict.
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 didn't touch this line in this PR - and do not plan to.
But I can tell you, that only USB HID devices can store a product string. But the numeric VID & PID exist for all HID devices. This is because the HID descriptors are not specified with fields for strings. They just contain the numerical index of a string in the USB String Descriptor. And non-USB devices simply have no USB String Descriptor to reference.
But it seems the fields are always filled by the OS, in case of my Lenovo Thinkpad with an I2C Touchpad from Elan, Windows reports "Microsoft" "HIDI2C Device" with S/N 9999.
class HidUsageTables { | ||
public: | ||
HidUsageTables() = default; | ||
static QString getUsagePageDescription(uint16_t usagePage); | ||
static QString getUsageDescription(uint16_t usagePage, uint16_t usage); | ||
}; |
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.
convert to namespace instead? There is no member data.
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.
empty file?
This is the first PR, where I make use of new hidapi capabilities. It provides all available information that is useful for device selection to the user/mapping developer. In follow-ups I will use this foundation to dig deeper in the provided Plug&Play information about collections and report data structures.
This PR:
Note: