A couple of days ago I purchased a HyperPixel monitor. Today I attempting an installation of the software.
I have a question, but perhaps the first thing I should note is that I do not run Raspbian on my RPi. The system I wish to port onto a small screen runs on Quirky Xerus 8.1.4.
I went to GitHub and downloaded the deb and dtbo files and the files for /usr/bin and /usr/lib/systemd/system. I also grabbed a copy of README.md.
Since an ‘easy installation script’ was advertised I decided to run it. The response was no data received or transfered and the following message:
curl: (77) Problem with the SSL CA cert (path? access rights?)
I’m initially assuming this could be related to the fact that I’m not running Raspbian.
I’m quite happy to make a manual install. It’s easy enough to install the deb, copy the other files to their respective directories and paste the configuration commands to config.txt.
However the readme file says:
Make sure you add uinput to /etc/modules
I have no idea what uinput is. It’s not one of the files on your GitHub page. What is uinput and where do I find it?
Looking ahead, It’s my intention to use the HyperPixel in portrait mode (if I can) with a display_rotate=3 configuration. I see from another thread here that a special version of hyperpixel-touch has been generated to facilitate this. If this alternative script is stable would it be possible to either put it up at GitHub so that people are forewarned that rotation requires something special, or build the alternative instructions into a single script on a conditional basis (i.e. if display rotate equal to 1 or 3 … etc.).
The bubble-bag containing my HyperPixel had an enigmatic circular sticker on it saying ‘42’, but it seems I still lack a few answers.
My Hyperpixel display also came with an enigmatic sticker. I presume it’s just something left over from manufacturing.
uinput is a Python module required by the Hyperpixel software in order to (I presume) use the touch functionality. There are plenty links to uinput; here’s the GitHub page: https://github.com/tuomasjjrasanen/python-uinput
And some example uses: http://tjjr.fi/sw/python-uinput/
Hope this helps!
Oh, and PS: The rotation of the screen is quite simple once you get your head around it. I’m sure once @Gadgetoid has gotten it looking lovely and proffesional he’ll add it to the official installer.
Thank you RaspberryPicardBox, now at least I know what uinput is.
That brings me to the next level of the issue. I followed the link, then made a web search for more information and checked out the Debian Jessie and Ubuntu Xenial repositories.
I have the source code from GitHub but it seems there is no Debian Jessie compatible binary deb available. If it’s not in Debian then I assume it’s not in Raspbian either. There may be rpm binaries available (fedora?).
There are web references to a utility called pip. But there is no pip in my system and again I cannot find binary deb packages for pip. It’s a little over 20 years since I last compiled any software.
So my current understanding is that Pimoroni have issued a hardware product requiring software support, but have omitted one of the essential components of the software from the installer sequence? If so, that does not sound like a route to commercial success.
The HyperPixel looks like a potentially useful device that might attract attention from a wider circle of people than just the do-it-yourself hobby project crowd. I’m trying to make a system I have built (from binary packages) portable. A tiny screen with touch input that clips on to an RPi looks very promising.
The overwhelming majority of people do not know how to compile software (I’ve never done it on a Linux system). And the RPi has evolved beyond it’s original niche and is now used by millions.
My suggestion to Pimoroni is: Put a Debian Jessie compatible armhf deb for python-uinput on your GitHub page. Otherwise there will be people who, finding they cannot cope with the installation, put the device in a box and forget about it. That doesn’t hurt your bottom line in the very short term but it does your reputation no favours and looses you potential return customers.
It’d certainly be nice is some more of the packages were included straight up with the source code, but the products Pimoroni offer are usually tailored to Raspbian users coming from the educational and hobbyist side of the Raspberry Pi domain, therefore it’s usually kept as simple as possible.
The “pip” function is the Python package manager, standing for “Pip Installs Packages”; the easy-installer works by using the pip function to install any necessary dependencies for Python based code, which is usually supported by the majority of Raspberry Pi users (using Raspbian). I’m afraid the support for those running it “free-style” per-say is a lot less extensive…
I myself have never compiled any software either, but I’m sure myself and many others will give you a hand where we can! @Gadgetoid is certainly the man to ask about all things software, but I’m afraid the Pimoroni support crew are a little run off their feet at the moment trying to sort out technical hitches with both the Hyperpixel and Inkyphat displays, so expect a slightly delayed visit. :)
When I get a moment I will take a look into finding out how to install uinput without pip for you and see if I can’t find a way to fix it.
Thank you RaspberryPicardBox and MarcJennings for your help. I think I’ve made progress … of a sort.
Python is functionality I have never used. Quirky Xerus 8.1.4 appears to have a basic Python 2.7 which is, of course, extendible. Using the information provided above I tracked down the module that would had added the PIP function to my system.
Attempting to install that module, I was told of a dependency:
python-pip-whl - ca-certificates
satisfied by the package
ca_certificates_20160104ubuntu1
When I attempted the install I was told that the CA certificates package was ‘unavailable’. This seems to be full circle. I started out on the manual install sequence because the ‘easy installation script’ failed due to a missing CA certificate.
The RPi is not a one trick pony. It runs dozens of different operating systems. Some (RiscOS for example) are not even Linux based. Raspbian and Quirky Xerus 8.1.4 are closely related, both being derivative of Debian Jessie. Yet the HyperPixel software installation is so tightly tied to Raspbian that even the minimal difference with Quirky is enough to throw the installation into disarray.
Had I succeeded in installing PIP the next question would have been: What is PIP going to install. There is no python-uinput in either the Debian Jessie or Ubuntu Xenial repositories. I’ve have rarely visited the Raspbian site and have no idea what may or may not be in the Raspbian repository. Maybe that’s where I should head next.
One of the advantages of Quirky Xerus (see http://www.murga-linux.com/puppy/viewtopic.php?t=108132) is that, while it treats the Ubuntu Xenial repository as it’s ‘native’ repository, it will accept packages from any compatible source. I run Debian Jessie applications on my system, use a Debian Sid version of QT5 and have Debian Strech applications using that QT5.
As of yesterday evening my game plan was to wait two months and see if anyone at Pimoroni could turn the current installation sequence into a silk purse.
Glad to see you’ve made some progress (sort of)!
I’m not familiar at all with “certificates” and until today I didn’t even know they existed… Compiling software for other OSs is certainly complex…
I’m afraid even the most minor of differences between OSs proves a much larger challenge when designing any sort of instillation script; in order to automate the decision making process associated between numerous different OS’ file systems is an enormous effort, one which I’m afraid would be an almost impossible task for a few tech-wizards at Pimoroni to complete for every new product (although it might make a fun challenge ;) ).
Quirky Xerus actually sounds like a pretty cool distro! Might have to take a look myself when I get a chance.
As for the Pimoroni crew - I’m afraid they look pretty busy fixing problems on Raspbian alone at the minute :/
As soon as they’re a little less swamped I’m sure the more adept folk than myself will give you a hand in porting it over. As you say though, it may be a while!
I certainly appreciate the point about the Pimoroni people being stretched. As already noted I’m perfectly happy to wait and see what revised installer they eventually decide upon.
Thanks to the replies here, my problem is ‘solved’ in the sense that I know exactly what I need to do. I need to build a brand new Quirky Xerus system which includes the development module and compile python-uinput myself, specifically for my system. That’s not beyond my capacity. It’s technically the best solution, but also the most time consuming.
But that does not solve Pimoroni’s problem. They have, by design or accident, developed a really cute little screen which will, I think, appeal to a much wider group than just their traditional client base. And it’s already on the market, internationally!
People like me, living outside the UK are already able to buy the device from local suppliers. It is rather unusual these days to put a hardware device on the market that is tied to a specific linux distribution and I’ve not seen any warning on either the Pimoroni site or my local distributor’s site saying ‘you may experience difficulties installing required software if you are not running Raspbian’. Software support is best tested before product release.
While I appreciate your concerns, the vast majority of Pi users are happy to run Raspbian and so the support route for products like these is likely to have to follow the 80/20 rule (probably closer to 95/5). Of course that doesn’t make it right but I assume the thinking is “if you are running a different distro, you are more likely to be able to solve your own issues”. Again not necessarily to everyone’s tastes but as a business you can’t cater for all eventualities.
I believe I recognise that philosophy: IBM in the 1970’s, Microsoft in the 1990’s. An arrogant philosophy suited to companies who, being already rich, want to stay rich despite having increasingly less to offer their customers. Becoming rich in the first instance requires a tad more flexibility and humility.
OK, enough teasing. I think there is one last technical question I should ask to wrap up my contribution to this discussion: Is the version of python-evdev you have posted at GitHub a standard evdev or is it a standard+, i.e. a module that includes all the standard functionality plus a little extra for HyperPixel? If the latter then that module may also need to be re-compiled by non-Raspbian users.
By the way this forum gets good marks for prompt and helpful answers.
Dankeschon! We try our best. :)
I’m afraid however I don’t think I’ll be able to help much with that… I myself have no real experience with those modules!
I’d recommend the long version of testing both outcomes!
I’m new here but since getting the hyperpixel a few weeks ago, I was able to get it running on the most recent Kali linux, not too sure about the OS but hopefully this helps.
I ran into similar problems as you with getting the touch service to start in kali at first.
Just a reminder that before you stick the config.txt in the boot folder, you will have to mount the boot partition to that folder. I’m not sure if that is automatic with your OS of choice.
As for uinput, you can install by this command assuming you have python and pip installed.
pip install python-uinput
Other dependencies that needed to be installed were:
followed by adding uinput and i2c-dev to /etc/modules
sudo nano /etc/modules
then add the following to the file:
i2c-dev
uinput
At this point you can go back to the direction from github after the ‘Make sure you add uinput to /etc/modules.’ direction. My hyperpixel touch started working on kali after the extra steps described above.
It’s standard, no funny business, we’re just shipping the binary package to avoid the need for a recompile and development headers on the user’s Pi. This may be a non-issue now that Python Wheels are being built en-masse for the Pi, but we haven’t had enough time to look into that yet.