Ask HN: GUIs on embedded linux, oh my
By day I am not an embedded developer; by night I'm trying to be. I have an i.MX6 (solo) based device that I ultimately intend to sell in [very] small quantities for a niche market. In other words, this is closer to a hobby than an actual business.
One of the requirements is a very attractive and responsive UI. Based on my research Qt seems the best fit, but its LGPL restrictions and very expensive commercial license makes it almost impossible for me to choose. Qt wants $6,600 up front plus royalties and afterwards a subscription for support. I'm just a guy trying to build a thing... I can't afford that!
Trying to look for alternatives has been frustrating. The practicality of HTML5 on my platform isn't sure to me. To real embedded linux developers out there, please tell me what you use for your GUIs? It needs to be something of similar quality to a car infotainment system.
9 comments
[ 3.2 ms ] story [ 30.7 ms ] threadYou can use the LGPL version of Qt as long as you use dynamic linking to the Qt libraries and provide for the other things in the agreement (like letting users access the Qt source code, provide a way to update libs, etc). I haven't had a need to modify the libraries at all, I'm using a vanilla build for ARM right from the Yocto output.
In my opinion (been doing this for 25 years) Qt is the only embedded UI that's worth using these days. I stick with 4.8 and don't use Qt5 or QML, although you probably get a lot more performance out of the system that way and get to harness the accelerator under OpenGL.
Qt4 on 6Solo works fine enough for me and it's dead simple to do stuff like talk to lower-level drivers or make a Windows version for demonstration. Freescale supports enough of the backend stuff to use gStreamer and ALSA. I like that.
I recently tore down a car infotainment system that used iMX6 and Opera as the UI. The backend was all in Javascript. It looks like hell to develop for, but then again I don't work in Javascript all day.
Also I was hoping to use Qt5 if that makes a difference (QML seems nice..).
But I also think you're not obligated to provide as much as you think. You have to provide source (easy enough), but you really don't have to actually give them all the tools to build it do you? Be nice and point to the Yocto build you used and say you got your gcc toolsuite from there.
As for installation, all you really need to do is provide a way to replace the libraries. I wouldn't give out an entire rebuild/reflash suite or anything. Make a hidden screen in the program somewhere to let you mount a USB drive and replace the libQt?.so.4 files. And that's it. If they brick it, you shrug and say "not my deal".
In all my time I've never encountered anyone that actually wanted to do any of this. It's all a formality, especially when Qt literally does everything you need. I'm not even really sure what you would want to hack on Qt in the first place.
Then I would make the method accessible, but behind some kind of authentication method. User mails you and asks for the way to install it, once you've verified it's really them you provide the unique backdoor to that machine. Might be one way to approach it.
You can burn a unique serial number or whatever directly into the IMX6, there's a eFuse/OTP driver that lets you access it from the filesystem.
Great tip on the eFuse and an authentication method! Have you ever released a product built with Qt under the LGPL?
Installation of a modified library would seem (to me at least) to be a method you can share only with authorized owners.
I've released Qt products under LGPL, but they're all industrial equipment and I've never had a customer give any of this a second glance. They just want their shit to work.
Also depending on how complex your UI is going to be you can always take the crazy route and roll your own. If your scope is very specific and limited, it wouldn't be that bad.