Q Light Controller+

First and foremost: if you use my image as it is and don't need/plan any customization, you can just ignore the rest of this post.

I was pretty happy of the results achieved on Raspbian Jessie. Good boot time, small footprint, a single Qt build that did everything we needed (EGLFS without Xorg, XCB with Xorg)
Then Stretch came...and ruined (almost) everything

As you might already know, QLC+ relies entirely on the Qt framework, so it is essential to have a flawless Qt. And here we go.

Short story: Qt on Stretch is broken, and at present I'm not able to provide a solution to run QLC+ on Xorg.

Long story:
When I started to port QLC+ back in 2013 there was only the Raspberry Pi 1 on the market.
I have 15+ years of embedded development experience, so I know every bit counts on limited devices, therefore I decided to go straight to the point by opting for EGLFS, a way to render graphics on a OpenGL surface.
I didn't even consider running QLC+ on a Xorg desktop enviroment (like on a regular Linux PC) cause that would have meant to wait minutes before seeing any DMX running.
Being QLC+ a desktop application though, my goal was to show up the interface in as less time as possible. And I did it.

More Raspberries were made, and the usability of QLC+ on Xorg started to become interesting, for example on a Raspberry Pi 3.

As you probably know, the RPi is based on a Broadcom chipset, which has a graphics processor called VideoCore IV (VC4).
The libraries used to control VC4 was provided by Broadcom as close source, even though they did the job, either with EGLFS or Xorg.
At some point, the Raspberry Pi foundation decided they wanted an open source solution, so Broadcom hired a person (Eric Anholt) to do the job, without knowing nothing about the close source one. (weird ? yes, but it happens kinda frequently cause of intellectual properties)
So Anholt (who is a damn good developer, btw) integrated VC4 on Mesa 3D, and the driver is now stable and production ready.

So, the RPi geniuses, started to make a mess on Stretch. They kept the close source driver (in /opt/vc) and they renamed the OpenGL libraries by prefixing them with 'brcm' (e.g. libbrcmGLESv2.so), therefore breaking all the softwares out there relying on VC4, including Qt.
Then, they added Mesa and created even more mess, since there are header files with the same name (and different code) in /usr/include and in /opt/vc/include.
Not considering the fact that Mesa depends on Xorg, so the EGLFS usage case QLC+ relies upon got broken.

I spent a ridiculous amount of time trying to find the proper combination of libraries. I built Qt like 10 times, either by cross compiling or with the Raspberry itself (which takes HOURS)
Today I did the last test, and I gave up.

To make things even more ridiculous, on Stretch you can install Qt 5.7.1. Great, you think ! No ! Launch QLC+ with those libraries and there will be no icons all over the UI. Why ? Because the RPi geniuses had to customize the DE (their damn Pixel), and Qt doesn't know what to do with it.
I tried all the possible flags and read all the possible discussions, and I had to give up on that too.

I am quite upset about this situation.
I submitted the topic to the Qt bug tracking system, and they closed it the same day, pointing the finger to the Raspberry guys.
I will try to open a discussion with the RPi guys too, but at the moment, the only thing I have is an image working only on EGLFS.
Forget QLC+ on Xorg, until this situation is resolved by someone.

The only good news is that I've been able to keep the boot time low, and the image works on all Raspberries, including 3B+.

I'm sorry if some of you will be disappointed, but I tried my best, I swear, and I failed.

Massimo -

I begin, as always, with a huge thank you for all you do!

My question is what are the implications for VNC and/or RDP support? I've wrestled with this in the past, and was coming to the conclusion that the path of least resistance would be a full desktop install. Clearly that's not the way to go with QLC+ and Stretch…

Thanks again,
Peter

Hi Massimo,
great work, just testetd on RPI 3 b+, everything's fine. My Waveshare-touchscreen worked out of the box (like in previous version, only had to adjust the screen size).

Thank you very much!

Helmet

PeterD wrote: ↑Sun Apr 22, 2018 3:57 pm My question is what are the implications for VNC and/or RDP support? I've wrestled with this in the past, and was coming to the conclusion that the path of least resistance would be a full desktop install. Clearly that's not the way to go with QLC+ and Stretch…

Actually, there is a QPA (Qt platform abstraction) called qvnc, which I included in the image.
If you launch qlcplus -platform vnc it will start a VNC server.
I've tested it. It works, but it's REALLY slow, for the simple reason that it's not hardware accelerated. I guess they render every frame in software and then send them via VNC.
You might want to read this: http://www.jumpnowtek.com/rpi/Running-Q ... r-VNC.html

As for desktop VNC....pure sadness for now....

QLC+ on Raspbian Strech work very fine.
At http://demaus.de/projekte/lichtanlage you can find a installation guide at german.

I recently bought a RPi 3 B+ and started playing around with it, using the QLC+ image as well as a current Raspbian Stretch.

QLC+ image is awesome, with ssh access, webui. config pages and autoload workspace. Fantastic work!

My only concern is the big fontsize, I'm using a 1920*1080 HDMI monitor, got rid of overscan and now I have the feeling the screen space could be used more efficiently. I haven't tried yet but I'm confident I'll find out how to tweak fontsize / dpi for GL...

Then I went on to trying Raspbian. I installed and tried to run the .deb that was linked from Massimo's donation mail, but couldn't make it start. As I couldn not find any other source for a QLC+ RPi .deb on the web, as next step I set up and compiled an Armv7 Stretch .deb in my OBS area, and I can report that the resulting binary just works. I don't want to mess with Massimo's income, so for now I thought I better don't allow the built binary deb packages to be published.

I'm not sure how relevant the Info from the original post above still is at this time, maybe some Qt update or similar has fixed the issues meanwhile? Anyway, for my setup using an Enttec USBDMX pro MkII it just works, and apart from an occasional short lag/unresponsiveness ( like around 0.5 secs when changing tabs or similar) it runs smoothly, and seems powerful enough to not just run playback, but also use it during creation. I'm planning to try that for my next job in November, but will take my laptop as a backup solution with me, just in case...

I'd be interested in hearing from other people using such a system and their experiences (and will continue searching this subforum for such stories).

Thanks again, this is just so nice.

@Edgar: the problem is not in the QLC+ Debian package. It is in the Qt libraries. Before Stretch I was able to build Qt to work on EGLFS (without Xorg) and on XCB seamlessly.
Now Stretch is so messed up in terms of OpenGL support that the above has become impossible.

In other words:
- build QLC+ on top of Stretch's Qt version (ancient 5.7.1) -> works on Xorg but not without it
- build Qt on your own -> works on EGLFS but not on Xorg

Since I aim for a headless solution, I opted for the second solution, which boots lighting fast and still provides some graphics (with windowing limitations)

I just made a quick test on Raspbian Buster and it's seems that QLC+ RPi deb package works as expected. Now the menu icons are visible. I'll do more test today. Qt5 version is 5.11.3