1.14" PiTFT Kernel Module Display offset

[dzalnasky]

I have installed all of the drivers for the 1.14" PiTFT as instructed on the website. It is partially displayed in the top left corner, with most of the terminal being cut off. I have attached a picture of the issue to better illustrate what is happening.

Do I need to revert to an older version of the kernel? Or is there a way to modify one of the scripts so that the coordinates for the display are properly aligned to the screen?

[makermelissa]

Hi, could you provide more details to help us reproduce the issue? Such as if you installed in console or fbcp (hdmi mirroring) mode? Assuming Raspberry Pi, was it Desktop or Lite, etc. Thanks.

[dzalnasky]

I ran the following commands in terminal (as according to the guide) with the PiTFT connected to the headers of my Pi Zero. I did this through the desktop version of Raspbian, with mini HDMI from the Pi to HDMI port of a monitor. The picture does not show it as I had to exit tty1 to be able to use the terminal again, but I was able to see part of the "pi@raspberrypi:~ $".

sudo apt update -y
sudo apt-get update -y
sudo apt-get upgrade -y
sudo shutdown -h now
cd ~
sudo pip3 install --upgrade adafruit-python-shell click
sudo apt-get install -y git
git clone https://github.com/adafruit/Raspberry-Pi-Installer-Scripts.git
cd Raspberry-Pi-Installer-Scripts
sudo python3 adafruit-pitft.py --display=st7789_240x135 --rotation=270 --install-type=console

[makermelissa]

Awesome, thank you. I think that should be enough info.

[makermelissa]

By the way, I was hoping #233 had fixed this, but apparently it hadn't so it looks like additional testing is required.

[cajuncoder]

I have exactly the same problem... Is there any temporary solution for this?
PS. I first installed it via ssh and the hdmi plugged in.
Then I tried again via ssh without the hdmi plugged in.
Both times, it was installed with the pi booted up in console mode (no desktop)
FYI, the bootup sequence also isn't displayed.

There was one error when installing that read:
"PITFT Failed to disable unit: Unit file fbcp.service does not exist.
Configuring boot/config.txt for default HDMI
Set up main console turn on
/boot/cmdline.txt already updated
Turning off console blanking
Setting raspi-config to boot to console w/o login..."

I'm highly motivated to get this working. Can you elaborate on where and what the problem is so I can potentially look into it myself? Also can you make this a priority? I bought the 1.14" display specifically to use with the terminal...

[cajuncoder]

By the way, I was hoping #233 had fixed this, but apparently it hadn't so it looks like additional testing is required.

I was looking at this commit and it appears to only apply to the 240x240 pi tft, hence why we might be having problems with the 1.14" (which is 240x135)?

Granted, I really don't understand the code or how everything is supposed to piece together yet.

[cajuncoder]

Welp, I tried adding column and row offsets as per some old code in one commit related to all this, recompiled and reinstalled, and that still didn't work. I may have to resign to the fact that I have no clue what I'm doing and would need to spend considerable time to figure it all out...
Does this all work with the old buster image?

[makermelissa]

I was looking at this commit and it appears to only apply to the 240x240 pi tft, hence why we might be having problems with the 1.14" (which is 240x135)?

The minipitft114 in the commit you referenced is for the 1.14" miniPiTFT display.

Does this all work with the old buster image?

I'm not sure, but probably not. The script already makes it use the FKMS driver, which is essentially using the buster video driver. The issue stems from the fact that Raspberry Pi tends to make some breaking changes about every 6-12 months or so. They made a huge breaking change with video when Buster came out and much of this stuff has been running in an older compatibility mode which they seem to tweak every so often. Hopefully I should have some more time to be able to put into this soon.

[makermelissa]

Ok, so I'm making some progress on this. We had previously written a customized version of the fb_7789v driver at https://github.com/adafruit/Raspberry-Pi-Installer-Scripts/blob/main/st7789_module/fb_st7789v.c, but it had become obsolete (it was targeted for kernel version 5.10). The reason we had the custom driver is because the built-in one doesn't have an option to provide offsets, which causes the shifted display.

We were also recently having some trouble with Raspberry Pi updating the 32-bit kernel to 64-bit and I stopped compiling for newer kernels and started using the built-in one in #246. I found a better solution with #250 because it should compile in 32-bit user/32-bit kernel space and 64-bit user/ 64-bit kernel space and the fix forces you to use one or the other and not 32-bit user/64-bit kernel space. I intend to implement the same type of fix here.

I started by grabbing the source for the built-in one from https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/staging/fbtft/fb_st7789v.c for the current kernel branch (rpi-6.1.y). then I added in the customizations we made to the older driver. It compiled without issue, but when I tried to blindly replace the driver, the pi wouldn't boot. I attempted to remove the line from config.txt by plugging into my computer and editing, but that seems to have corrupted the boot partition. I did a clean reinstall (rpi 64 lite image, update, upgrade, driver install)

I'm still trying to remember how to load the driver from the command line without a reboot. I think it had something to do with using modprobe.

[makermelissa]

Apparently I was looking at https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7789v.c originally. https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/staging/fbtft/fb_st7789v.c has some code (which appears to be a slight variation of the code I wrote) in it to handle the offsets. This explains why the 240x240 1.3" MiniPiTFT isn't suffering from the same problem. So, if I can fix it for the 1.14" as well, I may just submit a PR to Raspberry Pi and fix the issue once and for all.

[makermelissa]

Starting out by testing the compiling and loading of the unmodified driver to begin with. Adding it here just so I don't forget in the future.

To load the module without adding to config.txt after compiling:

cd Raspberry-Pi-Installer-Scripts/st7789_module
sudo modprobe fbtft
sudo insmod ./fb_st7789v.ko
sudo dtoverlay drm-minipitft114

To Unload:

sudo dtoverlay -r drm-minipitft114
sudo modprobe -r fb_st7789v
sudo modprobe -r fbtft

[makermelissa]

As I'm digging in further, by printing debug messages, I'm finding minipitft13_set_addr_win isn't being called, which is responsible for setting making use of the offsets. It appears to only be used when using Framebuffer Copy (fbcp), so the console is a bit of a different beast even though it's using the same driver, so maybe updating the driver is the wrong approach.

This makes sense because the driver seems to work fine in fbcp mode and also aligns with my findings when I was working on trying to use the MIPI drivers. It appears on the surface that the console stuff may soon be obsolete, but I'll keep digging.

[makermelissa]

Ok, I just tried it in FBCP mode and it's doing the same thing, so at least we have consistency. I'll poke around at the driver some more. I also found something that may be useful later:

There's an option fbcon=rotate:<n> which allows rotating the console in software rather than setting the driver rotation. This may be useful if the offsets start misbehaving and we only have 1 good offset.

[makermelissa]

Ok, issue was the driver. After adding in my calculations, updating the device tree overlays, and updating the adafruit-pytft.py script, I have it working, but it needs a bit more testing...