support for HID monitors

[Agentry433]

Hi Matthieu Houdebine,

My name is Max. I made a small fork of your project, turing-smart-screen-python, and added support for HID monitors currently sold by Chinese vendors—specifically this model: https://spotpear.com/wiki/3.5inch-LCD-Computer-CPU-GPU-RAM-Monitor-PC-USB-TypeC-Secondary-Display-Screen.html.

They come with software called "3.5 Inch SmartMonitor.exe" (and similarly named software for other screen sizes). I reverse-engineered the EXE file and extracted everything I could to get themes running on Linux-based systems. I also played around with the theme editor for these screens, integrated it into your original GUI, and wrote a theme converter similar to the manufacturer's. Here is the reworked project for this vendor's HID devices: https://github.com/Agentry433/turing-smart-screen-python

I am not a professional programmer and I relied on AI assistance, so the result is functional but may contain bugs, and the code might not be perfectly clean (I'm learning). I asked QWEN to upload the project to my GitHub, and that "miracle" listed itself as the author lol.

Please take a look at my work; perhaps you will find it useful for the further development of your project.

Best regards,
Agentry433

[Agentry433]

The main project's functionality was supposed to be preserved, but I simply don't have the opportunity to test it. Everything works fine on my HID 3.5 monitor; I use configure.py. Newer Ubuntu versions require VENV and sudo permissions on the HID device, but I can't overcome this... But it's all solvable. I'm continuing to think and work on this project. Thank you so much for all the work you've done on older monitor versions. I would really like you to appreciate my efforts, you are the founder of the project (the father of the project).

[Agentry433]

command for device permissions sudo chmod 666 /dev/hidraw*

[c0ldJS]

Looks like portions of the fork need a little attention:

• The declared license is incomplete.
• A core configuration file hardcodes a path relevant to your localhost; it will break for all other end users.
• Are you sure that communication with the hardware is via YMODEM...?
• Documentation was lifted wholesale, providing links that will send end users to this project/repo instead of yours.
• The catalog of existing themes was cloned but all lack the required .dat file to be used; additionally, there appears to be a subdirectory that the project actually taps for themes, rendering the parent redundant redundant.

[mathoudebine]

Hello and thank you for sharing this work. We previously discussed on this screen that we called the Fuldho 3.5" IPS Screen because we did not have any other name for it: #298

Ideally I would add only the lcd_comm_rev_a_hid.py from your fork to this project but this file does not implement the DisplayPILImage() necessary for this program.

It seems this is because the Fuldho screen screen does not work like the other supported smart screens:
the turing-smart-screen fundamental logic is to compute and send bitmap chunks to the smart screen (background, text value, charts, bars...). The screen then display the bitmaps in a "dumb way".

In your fork, all this logic is unused or disabled by the _smartmonitor_runtime_enabled() function, and a complete different logic is created in all the tools/smartmonitor-*.py files.

This is because the Fuldho screen logic is reversed: the screen does the drawing at startup using an uploaded "theme" in a proprietary format, then you send periodically the sensors raw values to the screen that will compute and display them the way it wants. This means:

• you cannot use existing themes and fonts for this screen
• you cannot draw bars and graphs, only text
• the list of sensors you can send to the screen is hardcoded (in _collect_metric_value)

In the end, there are too much differences between the Fuldho implementation and logic for it to be integrated in the main program in a standard way. Also it would add too much new code that will need to be maintained separately.

I'm glad that you were able to reuse the turing-smart-screen base to work with your screen, and I can definitely add a link to your fork in the README for people using this screen!

[Agentry433]

Hi Matthieu Houdebine, and thank you for taking the time to review it so carefully.

Yes, I agree with your assessment. After reversing this screen further, it became clear that it does not fit the
standard turing-smart-screen model where the host renders bitmaps and the display acts mostly as a dumb target.

This device works in a different way:

• a proprietary theme bundle must be uploaded first
• the screen renders its own layout internally
• the host then sends raw metric values and time packets instead of bitmap updates

So in practice it is not just a new transport layer, but a different display model with its own theme format,
runtime protocol and editor workflow. That makes it a poor fit for upstream integration in the current architecture.

I reused a lot of your project as a base because the surrounding infrastructure is very solid, but I understand why
this should stay as a separate fork.

Thank you as well for offering to reference the fork in the README. I think that is the best outcome for users of
this screen.

[Agentry433]

new link - https://github.com/Agentry433/turing-smart-screen-python-HIDdev

[Agentry433]

Hi c0ldJS!
Thank you for the detailed review. I went through these points and cleaned up the fork accordingly.

Here is what has been fixed:

• The licensing issue was addressed by keeping the full GPL-3.0 license in the repository and preserving the
  original copyright / attribution notices.
• The machine-specific local path in the configuration was removed. The project now uses repository-relative paths
  for SmartMonitor themes instead of paths tied to my local system.
• The YMODEM point is now documented more precisely: theme upload uses YMODEM over HID, while live runtime updates
  use separate vendor HID packets for metric values and time updates.
• User-facing documentation and issue/discussion links were cleaned up so they no longer send end users to the
  upstream project for setup/help. The public-facing references now point either to this fork or to local repository
  documentation. I intentionally kept upstream attribution in source headers where appropriate.
• The SmartMonitor theme catalog was reworked. The repository now includes actual .dat theme files required by
  this screen, and I removed redundant / garbage subdirectories from the SmartMonitor theme tree so the remaining
  structure reflects only usable themes.

I also reduced the published package significantly by removing a lot of reverse-engineering/debug-only material and
unrelated heavy assets that were not required for normal use of the fork.

So these concerns were valid, and the fork is in a much cleaner state now.