Getting display and touchscreen to work

[VersusJH]

Hi and thanks in advance for the help! I saw you provided support for similar issues in the past so I figured I'd ask.

I'm trying to get this touchscreen display to work in PINN. It works on the installed Raspbian system after a bit of tinkering. I'd love to be able to use the touchscreen to choose which OS to boot into, since it'd save me from having to have a keyboard around but I cannot get the display to show the PINN UI, let alone taking touch input.

I have this overlay and the relative dtoverlay=mhs35:rotate=90 line in the config.txt and i have added the fbcon=map:10 fbcon=font:ProFont6x11 bit to the cmdline.txt, which seem to be the only applicable steps from the install script.

The script also installs some X11 configuration files (which I'm guessing are not applicable) and rpi-fbcp. I was thinking this may be part of the solution since I do have two framebuffers listed (dev/fb0 and dev/fb1) whose resolution correspond to the two displays, but I am unsure how to proceed.

I've been trying to play around in the recovery shell to see if I could solve it on my own, but I have too little knowledge of how video displays work, much less touch screens. I can provide any debug info / command output needed, but I need some pointers on what to look for.

Any advice would be appreciated

[procount]

At a guess, rpi-fbcp will copy the main framebuffer to your second framebuffer which is used by your screen, so you need to install this and get it to run. pinn_init.sh is the script you need to create to perform any such initialisation. Have a look at the hyperpixel initialisation which uses this approach and examine /init.
The touchscreen will probably need me to add a driver to PINN, if you can figure out which one it uses.

[VersusJH]

To do that I imagine I'll have to build PINN from source, adding rpi-fbcp myself, am I correct?
I'm looking at this pinn_init.sh, and I see that it looks in a couple different places to detect the various types of screen. I cannot find traces of my device in any of those outputs.

the command tvservice -l lists a second HDMI device (which I didn't think my screen was?) numbered 7 but when tvservice -n -v 7 is run as per the init script it outputs "No device present", so I think first in order would be how to detect the display in the first place. Any idea where to look? I'll post dmesg/debug as soon as I'm able.

As for the driver, the only other thing in the install script is the package "xserver-xorg-input-evdev", so I'd say that would be it.

EDIT: i also found googling it uses "Driver IC ILI9486", which sounds like a better answer that the previous Xorg related one, but also is an LCD only driver as far as i can find? Sorry, not an area of expertise of mine, clearly.

[VersusJH]

Here's the log made with your savelog script and dmsg output. I'm not sure why, but the dmsg has some unreadable bytes that are not present when reading it from the recovery shell.

log.txt
dmsg.txt

[procount]

I had a quick look at the MSH-show script.
You need to :

• Add the overlay file.
• Add the settings in config.txt to enable SPI and configure the display to the correct size etc.
• add the FBCP driver
• launch the FBCP driver at PINN startup from pinn_init.sh

You can forget all the other stuff you found in pinn_init.sh. That's a very general purpose implementation that will autodetect various displays and autoconfigure PINN to use them.
Since PINN does not have Xorg, It will probably need a separate driver for the touchscreen. But I would concentrate on getting the display working first.

[VersusJH]

Overlay and config.txt should be already in place, here's the checklist of what I've done:

• Added the overlay file even before PINN install and it's present in the recovery partition both at /overlays/mhs35.dtbo and at /mhs35-overlay.dtb (which I understand is an old fallback option, but it's in the script so I placed it in both locations).
• Here's my config.txt file, always in the recovery partition (from what I understand it would not boot if it didn't find the overlay file, am I correct?):

start_file=recovery.elf
fixup_file=fixup_rc.dat

[pi4]
start_file=recover4.elf
fixup_file=fixup4rc.dat
max_framebuffers=2


hdmi_drive=2
hdmi_cvt 480 320 60 6 0 0 0
hdmi_group=2
hdmi_force_hotplug=1

dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on
enable_uart=1

dtoverlay=mhs35:rotate=90

• Appended the aforementioned option to both recovery.cmdline.new and recovery.cmdline, so that this is my file:
  quiet ramdisk_size=32768 root=/dev/ram0 init=/init vt.cur_default=1 elevator=deadline repo_list=http://raw.githubusercontent.com/procount/pinn-os/master/os/repo_list.json loglevel=2 sdhci.debug_quirks2=4 fbcon=map:10 fbcon=font:ProFont6x11

So I should be clear on the first two points. These options are the one that worked for the Raspbian installation so they should be clear (I had to follow that script manually because the script itself overwrites stuff that it shouldn't so i'm very familiar with it).

Could you kindly give me directions to achieve the last two points? Is it possible to compile it or should I just drop in the binary? And if yes, at what location should I place that and the pinn_init script?

Thank you very much for your patience and your help :)

[procount]

The pinn_init.sh script goes in PINN's root directory with recovery.cmdline.
You can put your fbcp driver program in the same folder.
When you call it from pinn_init.sh, the root folder is mounted at /tmp/mnt, so call it as /tmp/mnt/rpi-fbcp

[VersusJH]

Done, but the program just returns -sh: /tmp/mnt/rpi-fbcp: Not found. I suspect from some quick googling that it cannot run without the stuff used to compile it.
Will probably try to import the various libraries used (like the last comment in that thread suggests, I suppose it will be glibc and some raspberry stuff) as next step. Is there any other way you can think of?

[procount]

you can try recompiling it with static libraries so that it is self-contained.

[lurch]

I also did a brief bit of googling last night - I found that there was an attempt several years ago to add rpi-fbcp to buildroot, but it got rejected by the buildroot maintainers as the upstream code didn't have an explicit license. The upstream rpi-fbcp has now been MIT-licensed, but there's been no further attempts to add it to buildroot. (buildroot is the base-OS that NOOBS and PINN are built on top of)

[VersusJH]

you can try recompiling it with static libraries so that it is self-contained.

I've tried briefly and failed, I'll get back to you as soon as I actually manage that - I'll try again in the weekend.

@lurch I actually hadn't found that out while searching - is there any way this could come in handy? It doesn't look like there's many details about it.

[procount]

juj/fbcp-ili9341#50 ?

[lurch]

That's different to the link I was looking at http://lists.busybox.net/pipermail/buildroot/2018-January/211684.html 😉 However I've no idea if this will actually help @VersusJH or not 🤷‍♂️

[VersusJH]

juj/fbcp-ili9341#50 ?

I found that and is on my list of things to try, but it appears that driver is incompatible with most touch drivers.

Found this other fork which has actually added touch support for the touch controller of my screen (XPT2046, I read the wiki better) but only still it does say the project as a whole requires some libraries in the README, would those be present or would I still need to figure out the static compilation? Here's the passage:

At the moment fbcp-ili9341 is only likely to work on 32-bit OSes, on Raspbian/Ubuntu/Debian family of distributions, where Broadcom and DispmanX libraries are available.

Edit: this PR too, but the last messages do not look too promising despite the amount of work put in it.

@lurch If all else fails I can try to go that way - although, would it be simpler to add this package and the libraries needed into build root and then rebuild PINN or just to rebuild PINN with make and the libraries needed installed?

[VersusJH]

Update: I built myself a cross-compile toolchain via buildroot and managed to compile the fbcp binary! Luckily the package that provides the needed libraries is used in PINN as well (rpi-userland).

Now it links all the correct libraries and runs, but it fails silently (Error code is 255, but it's probably the code -1 being turned around). A look at the /var/log/messages syslog tells me that the function vc_dispmanx_display_open(0) is unable to get the primary display handle and fails. I am still unsure of why this happens and I will keep looking. If you can conjure up any idea as to why that is, let me know.