You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Depend on #170
OLED displays etc
The text was updated successfully, but these errors were encountered: