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

Add displays as types of readers #174

Open
wizzomafizzo opened this issue Jan 9, 2025 · 1 comment
Open

Add displays as types of readers #174

wizzomafizzo opened this issue Jan 9, 2025 · 1 comment
Assignees

Comments

@wizzomafizzo
Copy link
Member

Depend on #170

OLED displays etc

@wizzomafizzo
Copy link
Member Author

Why do we want this? Not just because I am mad and have no concept of scope:

  • Currently most of these display devices are Arduino powered which uses the same UART chip for communication as the most common NFC readers. This cheap chip confuses linux, and makes it difficult to tell between them. This means that the device's dev path may switch between reboots, which is causing bad conflicts between Zaparoo and the tty2* scripts who fight over serial communication (tty scripts use a static dev path).
  • A display is a very natural and fun extension of a custom NFC reader. Implementing this support for a standalone display could carry over cleanly when it's time to support displays on custom NFC reader devices.
  • It's very cool and cool things should be in Zaparoo.

I'm proposing that Zaparoo takes over the job of managing these tty devices, so that it can auto-detect and block connection conflicts much more effectively. I don't think it will actually be that much extra work to do, since almost all the screen drawing logic is on the firmware of the device. Fairly simple: connect, game has changed, send new picture data to device.

  • Right now I think the reader manager loop assumes all readers can read. Instead of making it a no-op, I think this would be a good chance to add capability tags to readers so the core logic can be a bit smarter with them Add capabilities to reader drivers #170
  • I don't believe there's currently and hook for readers to react to the game being changed. In fact I think the whole game tracking logic is still quite informal and mister-specific, so this might be the most complex part to fix up.

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

No branches or pull requests

2 participants