What is the current compatibility of the Hyperpixel? about hyperpixel

[pwr33]

seems to work ok on buster after sussing out what version of evdev to install, not actually using an x desktop just buster light and pygame.

the screen works ok but some issues with the touch functions and evdev

the latest evdev that pip installs is 1.6 but somewhere along the chain they dropped support for python2 I think, and the old hyperpixel is python2 code, so buster is latest with python2 as default python. So at least rpi foundation still supporting buster, as debian do a hyper long-term security patches fix thing for old debians.

as for evdev, 0.8.1 was released to fix the bug that 1.6 currently exhibits and now the touch driver loads at least, not tested in pygame yet.

force pip to install a version

sudo pip install -I evdev==0.8.1

I noticed the only "release" evdev have was 0.7.0, one of those things, later versions may be bug fixes you will never encounter with hyperpixel and added features hyperpixel doesn't use... and of course the added "feature" that it now dnfw with the hyperpixel/python2!

UPDATE:

Thought it was not working, after a few more hours faffing around there are still a few more frigs required

1. change the triggerhappy socket type

/usr/lib/systemd/system/triggerhappy.socket

[Socket]
remove ListenStream=/run/thd.socket
replace with ListenDatagram=/run/thd.socket

2 in hyperpixel-touch script

for some unknown reason the i2c bus of the touch chip is now 11 on buster
in script change to
bus = smbus.SMBus(11)

so now in pygame getting good data from mouse test,

with a bit of luck, it may even work on bullseye with python3 now I have discovered these stumbling blocks with version problems.

UPDATE 2:

yes, it works with python3 on bullseye if you apply the change posted by gadgetoid on my other issue thread, and maybe a few other silly python2 to python3 changes

obviously a problem with posting a change request to this library as it will no longer work on jessie/stretch without a version check to select correct bus number.

anyway for my purposes can just not even use the driver, just hack out the direct i2c touch stuff from the driver and do direct i2c calls each time round the pygame loop. as I do not need events posting to X or buffering.

Those capacitive touch drivers are massive functionality, kind of full finger configuration image available, massive library needed to get full functionality, multi touch, could possibly write a good musical interface surface with it as also supports pressure by the looks of it. though any documentation of the i2c interface to it seems lacking, but the pimoroni code is not bad and the actual driver is quite efficient considering it's python, only 1% on a pi3 while idle.