KlipperScreen can work with any display that will interact with a raspberry pi (HDMI, DSI, or GPIO). Feel free to post your success stories with hardware as other users may need help with figuring out which screen to buy.
I am currently running a screen very similar to this one on my printer. I say “similar” because you really can’t say “this exact one” since these generic screens come and go all the time on ali/amazon/banggood/wherever.
This particular touch screen has a single HDMI input, a micro USB connector for power, a micro USB connector to connect to a pi/pc/usb hub, and then two USB A connectors on board that you can connect thumb drives, mice, keyboards, whatever… into. The touch screen portion of it is pretty decent but it has issues on the corners picking up touches even after calibration.
I bench tested a Kuman 3.5" screen this weekend. It appears to be identical to the Elegoo linked above. It works, but with the small screen and low resolution text is a bit difficult to read in KlipperScreen.
I successfully run KlipperScreen with touch on the:
Waveshare 7inch HDMI LCD (B) 800x480 v 1.1. (with reflashed firmware)
Open firmware for Waveshare 7" capacitive touchscreen
I took a .bin file from promzona1 (see project issues) and flashed with ST-link V2 under Windows.
The chip on my board is GD32F103.
Then i using it as 1024x600 screen with Raspberry Pi.
overscan_right=225 // these may be different
overscan_bottom=105 // these may be different
hdmi_cvt 1024 600 60 0 0 0 0
At this point you get well adjusted screen but X for the touch was swapped. I not try recompile firmware.
Rotating the screen to the proper orientation proved challenging. The config.txt rotate commands don’t work with the raspberry pi4. I couldn’t get the xorg configuration to rotate the display. When I added kernel commandline parameters to rotate the display, that worked for the initial verbose boot screen… but once KlipperScreen loaded, it was the wrong orientation.
I ended up having to modify the init function in screen.py as below, but it’s pretty hacky. Not sure if there’s a better way on a raspberry pi 4. But… it works
These are useful and almost identical, but have subtle nuanced differences that could prove beneficial. The first, for example, helped me by pointing me to java - adb devices => no permissions (user in plugdev group; are your udev rules wrong?) - Stack Overflow which helped with getting ADB to recognize that I had my phone connected as an adb target and also pointed me to an old version of XSDL that was needed for my old Android v6 phone. The second has some pointers about wireless that I’ve yet to try. On my Note 10+ I was able to get wireless adb running and was able to have a wireless KlipperScreen UI for the printer. On the Note 10+ I was able to use the current release of XSDL, from the Google Play Store, and did NOT need to load the old version manually via adb install.
Of note: On the newer versions of XSDL, there is indeed a ‘Desktop No Emulation’ mode for mouse emulation (which is the appropriate selection to make use of). However, on the older v1.11.40 version, I needed to select tablet/laptop emulation, then turned off all of the config options on the mouse emulation submenu, and finally calibrated the lcd, so that my touches would be passed through to KS so it could do it’s thing. If it looks like it is not functional, it may very well be that the mouse emulation is jacked up.
Also, be advised that it might look like the Web UI (Mainsail in my case) was not operable when KS was working. I found that once KS got started, if you close the web UI and then reopen it, that Moonraker is indeed able to serve both Mainsail UI web clients concurrently with the KlipperScreen device hooked locally to the Klipper Host (and Telegram Bot too, btw). I can’t speak for other MR clients like Fluidd or Mooncord. Other useful and likely relevant guidance: