On the Topic " Display HAT Mini as Linux Console?" I first inquired and then came to a solution for using the Display HAT Mini as a Linux console. I’ve implemented this several times since then but every time the display shows a vibrating horizontal “tear line” near the bottom of the screen.
While this doesn’t stop the display from being used, it’s rather irritating as it vibrates rather rapidly and occurs right over top of the command line (see the photo). Other ST7789 displays I’ve used don’t seem to exhibit this problem.
Does anyone know of a way to eliminate the tear line?
Thanks
If you’re using fbcp, try killing the fbcp process and see if the line stops vibrating (it will also stop updating, but it’s just an experiment).
Thanks for the suggestion, but I’m not actually running fbcp. There is a “fbtft” overlay (see below) but I’m not seeing fbcp (or anything with “fb” in its name) showing up in either systemctl or via ps.
At the end of the /boot/firmware/config.txt file:
dtparam=spi=on
dtparam=i2c1=on
dtparam=i2c_arm=on
dtoverlay=fbtft,spi0-1,st7789v,dc_pin=9,width=240,height=320,led_pin=13,rotate=90,speed=40000000
dtparam=width=240,height=320
dtparam=dc-gpio=25,backlight-gpio=22
Noise can be analog in nature; you can try a lower (or higher) speed. It looks like the Pimoroni library sets it higher, at 60 Mhz but lower than the 40 Mhz you’ve set is worth trying too. I think the following dtparam= lines apply to the fbtft overlay? If so, they should be unnecessary and might cause problems…
I tried 16, 24, 60 and even 96Mhz and unfortunately none made any difference on the tear line.
To clarify, when you mention the dtparam= lines that are unnecessary and might cause a problem, which specifically do you mean? If you mean the last two lines containing width, height, dc-gpio and backlight-gpio, I have now commented them out, with no noticeable effect, so they clearly weren’t necessary.
Yep - those dtparam lines “pass upwards” (if I understand the RPi docs correctly).
You can install the “spi-tools” and “gpiod” packages with apt - they have command line tools to probe how the GPIO functions have been assigned by the kernel - they might help.
You could also try the display on another Pi or try the Pimoroni Python libraries which send pictures from userspace (not through a Linux FB). The libraries worked for me without any problems (so far, although I converted them to C and use them with a couple different st7789 based hats - but not for Linux console display though…).
Thanks - the photo I provided was actually running on a clean-build, second Raspberry Pi, a 3 B+. The normal place for this is on a Pi 4 on a robot. I’m pretty sure the display only has issues when used as a console, not for graphics. When changing config frequencies the tear line seemed to visually stay the same (at least so far as I could discern), which suggests it’s not related to display frequency.
Is there something I could be doing (that the code isn’t already doing) with the Tear Enable pin 25?
I was a bit surprised this is occurring since I have an older Rpi 3 B+ robot with a 320x240 TFT on it that works with no tearing. It’s also an ST7789 display, an Adafruit board. I don’t know what the difference might be, i.e., if this issue is due to hardware or software, and if there’s actually a solution available.
