Hyperpixel Kernel driver !

[procount]

Hey @Gadgetoid - I now have a working kernel driver for the Hyperpixel 3.2 touchscreen. I also combined it with the hyperpixel-init utility, so now you just need to include the overlay and kernel driver to get it functional. This means I can finally get the touchscreen aspect of the HP3.2 functional in PINN, instead of just the screen display.

So far, I have only used it as a built-in driver for buildroot. It did compile as a module in buildroot but I haven't compiled it with the right kernel to test with Raspbian. I don't expect any problems with that though.

The DT overlay allows for all the same inversions and swappings as the hyperpixel4 - I just need to simplify them to the 4 rotate_n parameters instead.

My next step is to combine the initialisation code of the Hyperpixel4 with the rotation-supported goodix driver, so that also just has a single driver.

Are you interested in either of these?

[procount]

I've now completed the Hyperpixel4 driver with LCD init code, so I can detect either screen and initialise both of them within the driver now. I've also figured out how to configure the hyperpixel 3.2 to use interrupts instead of polling for better performance.

I have discovered, though, that if I connect a HDMI cable with a Hyperpixel attached and config.txt set up to select the hyperpixel, that it prevents the Pi from booting properly. No display on either screen, no ethernet (although the yellow ethernet LED flashes, the green one doesn't) and I can't connect over SSH. I can't use the serial cable to debug because most pins are used up by the DPI interface. But I think it only fails if the display is rotated in certain orientations :shrug: Maybe it's my driver because it obviously worked before for the HDMI/Hyperpixel switching code.

Talking of rotation, is it possible to initialise the Hyperpixel4 into a landscape orientation rather than in portrait mode? It would make them more consistent. Is there a datasheet listing the purpose of the commands that are sent to it?

Interestingly, if the Hyperpixel 3.2 is attached to the Pi when it is configured for the Hyperpixel 4, there is a display, but it is 90 degrees out with half of it cut off, which suggests it should be possible to initiliase them both in a common orientation.

[procount]

@Gadgetoid - Is there a way to reset the LCD controller on the Hyperpixel and Hyperpixel4?

If the wrong driver is used with the wrong display (Hyperpixel driver with Hyperpixel4 display, or vice versa), then reprogramming it with the correct driver after a reboot has no effect unless the display is physically powered down.

[Gadgetoid]

There's no hard reset line between the LCD controller and Pi, so I'd suspect it's not possible (unless there's some kind of soft reset function). While I've made some effort to support the original HyperPixel on Pi 4, it's been a long time since I've done anything much with it.

How have your init drivers shaped up, by the way? Pre Pi 4 I was using an "init" that's statically linked against libbcm2835, but it's not clear if/when that will be updated for Pi 4. I have been considering a move to libgpio so that hyperpixel4-init and hyperpixel-init can still run with minimal dependencies.

[procount]

I suppose if you don't know about any soft reset, then no-one will! ;)

My drivers are all Kernel mode, so I don't use the bcm2835 library. Mostly I just use the kernel i2c drivers. The drivers work very well pre-Pi4 with all 4 rotations available, although the Hyperpixel4 parameters are 90 degree rotated compared to the Hyperpixel3. I had to write the hp3 driver myself (mostly ported from your python code) and that works fine. The hp4 driver is a modified version of the goodix driver, and that works until you touch the very bottom right of the screen and then the display goes off (blank). I haven't had time to debug that yet. (Odd that it is in the driver based on goodix whereas mine is fine. Maybe it's in my modifications somewhere....)

I have now also built and tested them as proper kernel modules under Raspbian (stretch) and they work fine too (apart from the above mentioned problem).

Regarding Pi4 versions, I haven't started on those yet. I was waiting for you to do all the hard work first! :) So I guess from your comment that your pi4 branch is not quite working yet? Can you summarise what you have found necessary to get it working?

IIRC, there is some difference getting the dpi18 overlays working, maybe need to put ALL the pins in alt mode? And one of the registers seemed to have changed from 5D to 1A? Probably the pull-up/down changes have had an effect too? Last time I looked, my i2c interfaces weren't detecting the touchscreens, so I think something in the main Pi DT overlays has changed.

Not sure how far I will get with the HP3 driver because my display has developed some interesting black lines across it towards the bottom. Not sure where they came from or how it got damaged.

[rcrespir]

Hi,

I need an hyperpixel 4 Kernel driver to improve the splash screen benefits on my RPI 0 W application ( Initializing the hyperpixel4 by systemD is taking a lot of time and I was wondering if introducing it as kernel driver I could reduce this time)

Thanks,

Rafa

[Gadgetoid]

@rcrespir Possibly- but I wouldn't know where to start with writing one.

@procount regarding rotation on the Pi 4, it's currently impossible (due to a regression or hardware limitation) to rotate the display before X fires up- I'm tracking this issue at https://github.com/pimoroni/hyperpixel4/issues/39

I did eventually get HyperPixel working on the Pi 4- this mostly involved backporting code from HyperPixel4, and replacing hyperpixel-init with the old Python version - https://github.com/pimoroni/hyperpixel/commit/703adcc6a66cce23b891a336120e0b42d75d4f58

Back in Pi 4/HyperPixel 4 land I have a port of the init script to libgpiod, though, which could be applicable here, and guide the creation of a statically-compiled init for regular HyperPixel on the Pi 4 - https://github.com/pimoroni/hyperpixel4/blob/pi4-libgpiod/src/hyperpixel4-init.c

[procount]

@rcrespir - I wrote a kernel driver for the Hyperpixel4 for use in PINN. (see https://github.com/procount/pinn/tree/master/cypress3) It should work with all RPi before the PI4, although it does have one limitation (see my post above yours). It combines display initialisation with all 4 rotations, touchscreen interface and Hyperpixel4 detection code. Feel free to use it as you wish, but let me know if you find the source of the blanking bug!

to improve the splash screen benefits

Which splash screen? The kernel driver is loaded after the firmware has displayed the 4 square coloured splash screen, so that will never be displayed on the Hyperpixel. But if you mean the Linux splash screen after the boot text, then that should be displayable. Not sure if it will be any quicker to initialise the display via a kernel driver than by systemd, but worth a try. I needed the kernel driver to avoid having to include python within PINN.

@Gadgetoid - I'm so busy I still haven't got round to looking at a Pi4 version, but I appreciate all the hints you keep posting me. They will be very useful when I do get around to it.

[Gadgetoid]

@procount no worries! If you need any support in terms of hardware/tips then you know where to find me. I'll add porting to libgpiod to my TODO list but you might have to prod me when the time comes!

[rcrespir]

@procount Thanks a lot! I will take a look on the cypress3 and I will try to find the bug because I need it working at 100%

[procount]

@rcrespir - My hyperpixel3 driver (built from scratch) works flawlessly, so you can compare with that code if it helps. My hyperpixel4 driver is based off the original goodix touchscreen driver, so maybe I misunderstood something in it. Both drivers are setup to build as platform drivers in buildroot, but you should be able to build them as separate kernel modules in the right environment.

[rcrespir]

Hi @procount , I am trying to add your pimhyp4 driver to the kernel but I am not successful. I'm new on linux and buildroot and I don't know where I'm wrong:

1) For testing, I'm using a local linux source, downloaded from the raspberry's github: linux-rpi-4.19.y 2) I've added 'pimhyp4.c' to /drivers/input/touchscreen and I've edited the Kconfig and Makefile to get the 'pimhyp4.ko' 3) I've added 'pimhyp4-overlays.dts' to /arch/arm/boot/dts/overlays and I've edited the Makefile to get the .dtbo 4) Then I run $make menuconfig and select the pimhyp4 driver as . 5) Run make and I have no errors on building the kernel, and in /drivers/input/touchscreen I have 'pimhyp4.ko' 6) tar the linux source to be able to use it on Buildroot's 'Custom tarball' 7) I go into my project buildroot's dir , I run make menuconfig, using the PATH to my local linux tarball in kernel -> Custom tarball , and finally I run make. 8) I got the image, with no errors, I can boot rpi with no problems, but when I try to search the pimhyp4 driver in modules.dep, It does not appear.

I am missing something? Maybe some of the BR2_LINUXKERNEL parameters are incorrect? This is the _defconfig I am using in Buildroot.

rscr_defconfig.txt

I would be grateful on any help

Rafa

[procount]

In my buildroot, make menuconfig is used for the rootfs stuff. To actually change the kernel configuration, it is necessary to use make linux-menuconfig and enable the driver in there.

Please bear in mind that this driver is still not perfect and I am still working to improve it. Notably, I get a spurious unhandled interrupt occurring which blanks the screen and disables the touchscreen randomly, and I'm failing to get it working properly ont he Pi4 in FKMS mode.

But it's not really any different to the pimoroni driver, so I don't yet understand it, but I am getting closer.

[hoegge]

Hey @Gadgetoid - I now have a working kernel driver for the Hyperpixel 3.2 touchscreen. I also combined it with the hyperpixel-init utility, so now you just need to include the overlay and kernel driver to get it functional. This means I can finally get the touchscreen aspect of the HP3.2 functional in PINN, instead of just the screen display.

So far, I have only used it as a built-in driver for buildroot. It did compile as a module in buildroot but I haven't compiled it with the right kernel to test with Raspbian. I don't expect any problems with that though.

The DT overlay allows for all the same inversions and swappings as the hyperpixel4 - I just need to simplify them to the 4 rotate_n parameters instead.

My next step is to combine the initialisation code of the Hyperpixel4 with the rotation-supported goodix driver, so that also just has a single driver.

Are you interested in either of these?

Hi. Would it be possible to make Bullseye driver / DTC for the orginal hyperpixel display easily to support al the current Hyperpixel users?

[Gadgetoid]

Hi. Would it be possible to make Bullseye driver / DTC for the orginal hyperpixel display easily to support al the current Hyperpixel users?

Possible - maybe - but the driver referenced here is already 3 years old (going on 4) and probably doesn't resemble the latest and greatest DRM, 3D accelerated, wiz-bang drivers required by Pi 4 and modern Raspbian.

To get an idea of what might be involved to write and upstream one, see this PR for the HyperPixel4 driver - https://github.com/raspberrypi/linux/pull/4812

And this is assuming - since I don't recall exactly the pinout of O.G. HyperPixel - that the hardware will actually play nice with the Kernel's very strict view of pin allocations.

[hoegge]

Well / probably too much work then compared to just buying new displays :) Thanks for the answer.

[6by9]

Based on the sources in https://github.com/pimoroni/hyperpixel/tree/master/sources, it looks possible.

I see:

• DPI mode 6 (0-9, 12-17, and 20-25)
• Bitbashed I2C on 10 & 11
• Backlight on 19
• Bitbashed SPI on 18, 26, and 27. So no reuse of pins, and everything should be OK.

https://pinout.xyz/pinout/hyperpixel lists 27 as being touch interrupt, which would be an issue as it conflicts with the bitbashed SPI clock. Isn't that the same condition we looked at for one of the HyperPixel4 panels, and spi-gpio got amended to allow for an sck-idle-input flag?

I can have a quick punt at implementing a driver, but I don't have one to test against. It'd also be nice to know what model of panel it is so that the driver and compatible string can be appropriately set.

[hoegge]

@6by9 Cool - I'd be happy to test for you. I have attached two images of my display. It is the "original" 3.5" hyperpixel display

I can have a quick punt at implementing a driver, but I don't have one to test against. It'd also be nice to know what model of panel it is so that the driver and compatible string can be appropriately set.

[6by9]

The question over the appropriate display info was more aimed at @Gadgetoid as one of the people who originally designed the Hyperpixel boards. He must have information somewhere.

The programming sequence is very similar to ILI9806, and seems to follow some of the MIPI DCS standard commands, but not quite.

[6by9]

I can't easily identify the touchscreen controller from the Python source of https://github.com/pimoroni/hyperpixel/blob/master/requirements/usr/bin/hyperpixel-touch. Without that information it won't be possible to configure the touch side correctly. BU21013 looks the most likely based on those that exist in the kernel tree with device tree bindings saying they exist on a default I2C address of 0x5C.

Otherwise https://github.com/6by9/linux/tree/rpi-5.15.y-dpi has a driver and overlay that have an outside chance of working for the display only (touch disabled). I think I've converted the block of initialisation messages in hyperpixel-init.c to individual messages, but if not we can convert it back into a binary blob. You'll need to build the kernel (see https://www.raspberrypi.com/documentation/computers/linux_kernel.html), but also enable the module DRM_PANEL_PIMORONI_HYPERPIXEL35 after the make bcm..._defconfig step, as I haven't added it to the defconfigs.

[procount]

I believe it could be a Cypress Cy8c20466 Capsense Psoc