OpenTabletDriver / OpenTabletDriver/OpenTabletDriver
Exporting diagnostics with known conflicting drivers should warn user of potentially invalid diagnostic
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 4.1k
- Forks
- 534
- Avg merge
- 4d 20h
- Merged PRs (30d)
- 12
Description
Description
Current behavior if vendor driver is already installed:
- Helper requests diagnostics file
- User sends diagnostics file
- Helper tells user to uninstall vendor driver and send new diag (usually with TabletDriverCleanup)
- Diagnostics is ready to read
Instead, exporting diagnostics should tell the user that a known vendor driver is installed, and should be properly uninstalled first before providing the diagnostics file.
It also avoids helpers potentially missing the loaded vendor driver and then trying to implement a tablet configuration for the device based on an vendor-initialized state (which would then proceed to not work without the vendor driver installed).
This can either be solved daemon-side on export (e.g. via new property in diagnostics class) via the OpenTabletDriver.Desktop library, or can be manually checked for by consumers (e.g. GUI would check for presence of conflicting drivers and warning the user before presenting the file dialog).
Regardless, the consumer (GUI/CLI) is the one responsible for warning the user, so you could consider the latter obligatory in either way, but the former could allow for implementing an enumerable property containing known issues for additional useful known warnings down the line (Vanguard anti-cheat, etc) and avoiding duplicated code across CLI and GUI.
Acknowledgements
- I have searched the existing issues and this new issue is not a duplicate of any.
- I have written a concise and meaningful title.
- I am on the latest version of OpenTabletDriver.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing diagnostics export in the OpenTabletDriver.Desktop library and the GUI/CLI consumers mentioned in the issue. Review the diagnostics class and export flow to determine where known conflicting drivers can be exposed and where consumers should warn before presenting the file dialog. Done means the relevant consumers warn users that diagnostics may be invalid until the vendor driver is uninstalled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- cli, desktop
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100