mathoudebine
Turing 8.8" New Hardware Revision v1.x not supported
Looks like there is an other hardware revision of the Turing Smart Screen 8.8". After i connect mine it will offer me two usb devices but none of them providing any serial interface. Either i do it completely wrong or there is for real a new hardware revision.
[ 2187.135120] usb 5-4.1.4.3: new full-speed USB device number 10 using xhci_hcd
[ 2187.254226] usb 5-4.1.4.3: New USB device found, idVendor=1cbe, idProduct=f00
0, bcdDevice= 0.01
[ 2187.254233] usb 5-4.1.4.3: New USB device strings: Mfr=1, Product=2, SerialNu
mber=3
[ 2187.254236] usb 5-4.1.4.3: Product: USB-Daemon
[ 2187.254239] usb 5-4.1.4.3: Manufacturer: turzx.com
[ 2187.254241] usb 5-4.1.4.3: SerialNumber: 0123456789
[ 2188.145129] usb 5-4.1.4.1: new high-speed USB device number 11 using xhci_hcd
[ 2188.241838] usb 5-4.1.4.1: New USB device found, idVendor=1cbe, idProduct=008
8, bcdDevice= 0.00
[ 2188.241842] usb 5-4.1.4.1: New USB device strings: Mfr=1, Product=2, SerialNu
mber=3
[ 2188.241844] usb 5-4.1.4.1: Product: TURZX1.0
[ 2188.241846] usb 5-4.1.4.1: Manufacturer: TURZX
[ 2188.241848] usb 5-4.1.4.1: SerialNumber: 051xxxxxxxxxxxxxx
Describe the bug
No connection possible with this display due to lack of serial port
Environment:
- Smart screen model [Turing 8.8"]
- Revision of this project [
mainbranch] - OS with version [Linux Arch]
- Python version [Python 3.13]
- Hardware [AMD Ryzen 9 3900XT]
Hi @ninharp @jurjevic It seems there is indeed a new generation of Turing 8.8" screens that do not communicate the same way as the previous gen. For now the new generation is not supported with this program ☹ Can you share where you bought yours? I would also be interested by the original software provided for it.
Hi @ninharp @jurjevic It seems there is indeed a new generation of Turing 8.8" screens that do not communicate the same way as the previous gen. For now the new generation is not supported with this program ☹ Can you share where you bought yours? I would also be interested by the original software provided for it.
I bought it on Aliexpress on the Elec Zone Store. Here is a link https://de.aliexpress.com/item/1005005538293555.html The original software provided for the display is the same as for the other devices, it just detects the display as 8.8"
I will try to capture the usb frames when the display is enabled in windows. Maybe the software captured frames are enough to reverse engineer the usb data used to drive the display. I also will dissassemble the device soonish to see if there are any other connectors which could be used, maybe a dedicated uart port or something similar.
Same here - I've a 3,5" version running and it works fine. I just wanted a bigger display, but the 8,8" seems to work completely different :-(
I too have recently purchased an 8.8" version from eBay : https://www.ebay.co.uk/itm/365422061073
The internal driver board states that it's a version 1.1
I just used Wireshark to dump the packets and had ChatGPT generate a sample code. Tested it on my Ubuntu machine, and replaying the previously dumped packets successfully updates CPU, GPU, and other metrics on the display.
Yesterday I tried analyzing the packets. It seems that part of the data is encrypted using DES, which makes it difficult to directly reuse the old data format.
Same problem here. I bought it on aliexpress on March 29 from electree store, the package is the same as in the picture, and it is not detected... Do you recommend to make the return? Or maybe support will be added in the future?
Thank you for your attention and the beautiful app
I’ve written a sample CLI tool that supports several commands for the Turing Smart Screen - TURZX 88inch V1.1:
- sync
- restart
- refresh-storage
- brightness
- save
Example usage:
python turing_screen_cli.py sync
python turing_screen_cli.py restart
python turing_screen_cli.py refresh-storage
python turing_screen_cli.py brightness --value 80
python turing_screen_cli.py save --brightness 90 --startup 0 --rotation 0 --offline 0
You can check it out here: 🔗 https://github.com/phstudy/turing-smart-screen-cli
I’ll continue adding more features when I have time.
I've added the send-image command, which allows sending 480x1920 PNG files to the device. I think this should be enough for the project to support the new revision.
Example usage:
python turing_screen_cli.py send-image --path ./102_25011_payload.png
I also just got the send-video command working. Here's an example that plays a video in loop mode:
python turing_screen_cli.py send-video --path ./AMD.mp4 --loop
So far, it works well on the new screen version.
I tried porting the current command implementation into the project. It's not fully polished yet, but it works properly on my Mac. Feel free to fork the branch and adjust it as needed.
Repo link: https://github.com/phstudy/turing-smart-screen-python/tree/feature/support-8.8-v1.1
I've added the
send-imagecommand, which allows sending 480x1920 PNG files to the device. I think this should be enough for the project to support the new revision.Example usage:
python turing_screen_cli.py send-image --path ./102_25011_payload.png
Firstly, many thanks for the great work you've done in getting this far, really appreciated.
However, I am having a problem sending large PNG files, either from the CLI tool or via my own code which converts a PILLOW Image to a PNG file as implemented in your latest update. Small size files work fine. Its as if the data needs to be chunked and sent in parts.
Have you experienced this? Have you tried sending a large PNG file to the display?
Many thanks, Lee
Hi @loonatic-lee,
Thanks for your detailed feedback and kind words!
I've tested this on my side and noticed that even the original Theme Editor fails to properly display PNG files larger than 1MB. So it seems like there might be a firmware or memory limitation on the device itself when handling large image payloads.
I haven't found a reliable way to chunk and send the PNG in parts yet. However, I did come up with a potential workaround — converting the image into a 1-second video and sending it using the send-video command instead. This method seems to work consistently, even with large files.
I just bought this not realising it was for windows only. great you got it working on mac. is it possible to display a web browser on it, that's what i bought it for not realising it was so limited?
@yes-captain-75 From a purely technical point of view, you could display a screenshot of the web browser on it, but anything more (changes on the webpage or animations) would be impractical. So no, I don't think that this display fits your use case.
Hi @loonatic-lee,
Thanks again for your input earlier! I've implemented a new approach to reliably send complex PNG images via send-image.
The image is dynamically split into multiple parts based on its actual compressed file size. Each part is a 480xH transparent-background PNG that contains the corresponding lower portion of the original image. The first part is a full 480x1920 canvas with only the bottom region filled, and each subsequent part reveals more of the image above.
By layering these transparent patches from bottom to top, we can successfully transmit and display highly complex images, even when they exceed size limits or rendering constraints on the device.
@yes-captain-75 From a purely technical point of view, you could display a screenshot of the web browser on it, but anything more (changes on the webpage or animations) would be impractical. So no, I don't think that this display fits your use case.
thanks for your helpful reply 👍
Hi @loonatic-lee,
Thanks again for your input earlier! I've implemented a new approach to reliably send complex PNG images via
send-image.The image is dynamically split into multiple parts based on its actual compressed file size. Each part is a 480xH transparent-background PNG that contains the corresponding lower portion of the original image. The first part is a full 480x1920 canvas with only the bottom region filled, and each subsequent part reveals more of the image above.
By layering these transparent patches from bottom to top, we can successfully transmit and display highly complex images, even when they exceed size limits or rendering constraints on the device.
Hi @phstudy,
That works great, what a sneaky workaround, very inventive.
I prefer setting the opacity of the layer_img to 255 to blackout the underlying image.
I have tried to implement something similar using transparency previously but without success.
For example, if I send a full background image and subsequently send another image (generated via PILLOW not from a PNG) that has a transparent background. Then rather than seeing the previously sent image through the transparent sections of the new image I see the original TURXZ background image.
Am I missing something? As being able to layer images would be great.
Hallo,
first of all, thank you for the work of everyone involved in this project! Since I use Linux (Windows can stay stolen from me as far as it goes) I was very happy to have found this project, with my 5 “display it worked great, but now I have the problem with the 8.8” version that I got the newer version. I use Nobara Linux 42 and had to fight with the revised version to get rid of all the bugs, starting with the fact that I had to adjust the provider and product identifier up to several problems to get the Python modules running. But now I can't get any further, I suspect it has something to do with authorizations but when I want to send the data to the display via the configurator I get the following feedback.
09.05.2025 19:40:46 [INFO] Loading theme Cyberpunk 2077 from res/themes/Cyberpunk 2077/theme.yaml Warning: set_configuration() failed: [Errno 16] Resource busy 09.05.2025 19:40:46 [DEBUG] Using Python 3.12.10 (main, Apr 22 2025, 00:00:00) [GCC 15.0.1 20250418 (Red Hat 15.0.1-0)] 09.05.2025 19:40:46 [WARNING] Tray icon is not supported on your platform 09.05.2025 19:40:46 [INFO] Initialize display Sending Sync Command (ID 10)... Traceback (most recent call last): File "/home/daniel/turing-smart-screen-python/main.py", line 202, in <module> display.initialize_display() File "/home/daniel/turing-smart-screen-python/library/display.py", line 100, in initialize_display self.lcd.InitializeComm() File "/home/daniel/turing-smart-screen-python/library/lcd/lcd_comm_rev_c_usb.py", line 292, in InitializeComm send_sync_command(self.dev) File "/home/daniel/turing-smart-screen-python/library/lcd/lcd_comm_rev_c_usb.py", line 114, in send_sync_command return write_to_device(dev, encrypt_command_packet(cmd_packet)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/daniel/turing-smart-screen-python/library/lcd/lcd_comm_rev_c_usb.py", line 91, in write_to_device assert ep_out is not None and ep_in is not None, "Could not find USB endpoints" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: Could not find USB endpoints 09.05.2025 19:40:46 [INFO] Program will now exit 09.05.2025 19:40:46 [INFO] Waiting for all pending request to be sent to display (5s max)...
If I then search for the USB device under /dev I can no longer find ttyACM1, there is only ttyACM0. If I unplug the display and plug it back in, the device is there again. I have also created a rule under udev/rules.d.
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", ATTRS{idProduct}=="a4a7", MODE="666" SUBSYSTEM=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="ca88", MODE="666"
It seems to me that the device cannot be added again via the USB module with the appropriate drivers. Running the whole thing as root, which I also don't want to do, doesn't help either, I just get the message that the USB module was not found.
Does anyone have any ideas what else I can try?
Best regards Daniel
Hello,
thanks for the feedback, I have also tested this and also made an adjustment to the udev rule but basically get the same feedback as before.
2025-05-11 18:51:41,520 - WARNING - set_configuration() failed: [Errno 16] Resource busy 2025-05-11 18:51:41,521 - INFO - Sending Sync Command (ID 10)... 2025-05-11 18:51:41,521 - ERROR - Unexpected error: Could not find USB endpoints
I think that my problem has nothing to do with the script but with my system.
Hi @dhegi-lab,
Could you please try the CLI tool first? It works well on my Ubuntu environment, and I haven’t been maintaining the porting branch lately. If the CLI runs successfully on your Linux setup, I’ll update the porting branch to support for it.
Thanks!
Hello @phstudy,
thanks in advance for your support! This is the script I tried last time, you had linked it yesterday, but unfortunately it doesn't work, even with root rights it doesn't work.
Before I run the script, for example with restart or sync, it disconnects one of the two USB devices and that's it, according to my understanding it should then reconnect the device, but that doesn't happen.
The display is shown with the following information before the script is executed.
Gadget Serial v2.4 Hersteller: Linux 5.4.61 with sunxi_usb_udc Anbieter-Kennung | 0x0525 | (Netchip Technology, Inc.) Produkt-Kennung | 0xa4a7 | (Linux-USB Serial Gadget (CDC ACM mode))
UsbMonitor Hersteller: Turing Seriennummer: CT88INCH Anbieter-Kennung | 0x1a86 | (QinHeng Electronics) Produkt-Kennung | 0xca88
I have already tested it with both vendors and product IDs as I am not sure which one it needs to address.
Best regards!
Hi @dhegi-lab,
Thanks for the detailed USB info and for testing!
Based on the details you shared, your device appears to be an older version that uses:
- Gadget Serial v2.4 (0x0525:0xa4a7)
- USB-Serial interface (0x1a86:0xca88)
The CLI I implemented was designed specifically for the v1.1 model, which expose itself as a single USB HID-like device with:
- VENDOR_ID: 0x1cbe
- PRODUCT_ID: 0x0088
These newer device does not use a serial interface at all. Communication is done purely through USB bulk and control transfers. My script directly sends packets via ctrl_transfer and write(), so it won’t work with Gadget Serial or USB CDC devices.
Unfortunately, I don’t have access to the older hardware and can't confirm if the protocol or packet format is even compatible. So at the moment, only v1.1 device is supported.
Sorry I can’t be of more help with this older model.
@dhegi-lab Your 8.8 Inch is the Rev 1.0 which works over a usb-to-serial adapter. You can use the main branch of this project. I believe that your udev rules are breaking everything. The 8.8/1.0 exposes two serial ports, but you register both of these ports for the usb instead of the serial subsystem. I suggest you remove the rule and try again with the main branch.
Any chance to merge to main and get a new release with this fix for Rev 1.1?
Hello,
thanks @phstudy and @nreinartz for the information.
The reason why I came to the conclusion that my version is also a newer one is that I have the same behavior as described here. https://github.com/mathoudebine/turing-smart-screen-python/issues/724
But maybe I just got something mixed up.
I have also just tested this again with the original version, which worked with my 5.5" screen, for example, I get no errors reported and it also transmits the image, but I see no values on the display and with image errors just as can be seen in the link above on the photos of other users.
@nreinartz Without the udev rules I got even more errors, but that doesn't matter here anyway, I took them out again during the test.
@dhegi-lab Yeah you got that mixed up. There is a new firmware version (1.90) and a new hardware revision (Rev 1.1). You have the "old" hardware revision (1.0) with the new firmware. The new firmware isn't currently supported by this project. So following #724 is your best bet.