OpenTabletDriver / OpenTabletDriver/OpenTabletDriver

Exporting diagnostics with known conflicting drivers should warn user of potentially invalid diagnostic

Open
#4,294 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

desktop enhancement gui
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:

  1. Helper requests diagnostics file
  2. User sends diagnostics file
  3. Helper tells user to uninstall vendor driver and send new diag (usually with TabletDriverCleanup)
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.