Skip to content
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

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

JoergAtGithub
Copy link
Member

@JoergAtGithub JoergAtGithub commented Nov 17, 2024

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:

  • Show the physical transport protocol if available USB, Bluetooth, Firewire, ...
  • Shows different icons for MIDI, HID and USB Bulk-Controllers
  • Clearly seperates device properties and mapping poperties in the controller preferences
  • Replaces the hardcoded constant for HID Usages by the official JSON reference file provided on usb.org
  • Hides all properties, where no data are available (e.g. USB Interface-No. for a Portmidi-Controller).
  • All Properties have human readable labels now, instead of the old concatenated device category string
  • Devendored the outdated hidapi 0.11.1 copy in the lib folder - which is much older than required by now.

Note:

  • The number of lines changed lines looks much bigger as it is, due to devendoring hidapi and adding the Usage JSON file from usb.org.
  • I grouped the changes in seperated commits for easier review

grafik
grafik
grafik

Copy link
Member

@Swiftb0y Swiftb0y left a 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.

src/controllers/hid/hidusagetables.h Outdated Show resolved Hide resolved
Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple nitpicks

src/controllers/dlgprefcontrollers.cpp Show resolved Hide resolved
src/controllers/dlgprefcontroller.cpp Outdated Show resolved Hide resolved
src/controllers/dlgprefcontroller.cpp Outdated Show resolved Hide resolved
src/controllers/hid/hiddevice.cpp Outdated Show resolved Hide resolved
src/controllers/hid/hiddevice.cpp Outdated Show resolved Hide resolved
src/controllers/hid/hiddevice.cpp Outdated Show resolved Hide resolved
Comment on lines +57 to +61
<item row="0" column="0">
<widget class="QGroupBox" name="groupBoxDeviceInfo">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Preferred">
<horstretch>0</horstretch>
Copy link
Member

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?

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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...

Copy link
Member Author

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.

Copy link
Member

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.
Comment on lines +41 to +49
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"));
Copy link
Member

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?

Copy link
Member Author

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.

Comment on lines 11 to +12

enum class PhysicalTransportProtocol : uint8_t {
Copy link
Member

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?

Comment on lines +104 to +106
bool isValid() const {
return !getProductString().isNull() && !getSerialNumber().isNull();
}
Copy link
Member

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.

Copy link
Member Author

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.

Comment on lines +9 to +14
class HidUsageTables {
public:
HidUsageTables() = default;
static QString getUsagePageDescription(uint16_t usagePage);
static QString getUsageDescription(uint16_t usagePage, uint16_t usage);
};
Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

empty file?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants