It is, absolutely. I had long discussions with some stakeholders. There are two main reasons why QNX does not want to invest in Photon and corresponding graphics drivers any more:
almost none of QNX’ customers in the Automotive space is using Photon. But Automotive is one of the really important market segments for QNX
QNX isn’t in a position to compete with Photon against solutions like Qt. Qt is a “standard” while Photon is totally proprietary. One could argue that their microkernel is proprietary, too, but the API is POSIX so it’s a completely different thing.
Lack of Phindows capability bothered me aswell, however what I heard from QNX made sense to me. The recommendation was to refrain from trying to transfer draw streams or framebuffers like in the old days. With extremely big resolutions (no more 800x600, but more like 4k is coming soonish…), trying to transfer the whole GUI via the network just makes no sense.
The recommendation is to create an HTML5 HMI instead, that communicates e.g. via sockets with the main, headless application process(es). An HTML5 user interface can run natively on QNX 6.6, and can be run remotely using ANY device, like PC, Tablet, Phone. Something I always hated about Phindows was that it wasn’t available for my WiFi-enabled PDA (back in the days…) and that it wasn’t available for my Smartphone. HTML5 is available everywhere.
Yes, it means: Re-do the HMI, if you need remote access. Qt is not the way here. But to be honest, I am glad about it because it enforces change. Staying in the past and claiming “back then everything was better” is a very bad sign of getting old - and disconnected.
I agree that change is good and as an engineer I always welcome the new challenge and technology but I don’t think the upper managers feel the same about yet another big investment on technology when the current one is working just fine. I’m am working on industrial equipments that still run ISA boards and serial communication although we have moved to USB and ethernet, changes are much slower here than compare to consumer market.
Heu ? You mean vnc, remote desktop, teamviewer to name a few, those make no sense ?
So far photon works fine in 6.6, our design requires phindows without it we are f*d. We don’t even start a graphic driver, everything is virtual. Replacing this with html which we have started to do is a 1 year job…
Being a real-time guy, all this html stuff although interesting gives me the creep, talk about major overhead.
I totaly agree that Photon is somewhat of a dead-end but some sort of migration or porting kit should have been provided. I was told is was to much work and viable business wise, they thus decided to transfer the cost to their customers. Maybe a 3rd party with less overhead then QNX costwise or available resources is gonna jump on this. But given there is no window manager or anything alike it’s a LOT more then a porting kit…
But if you started from scratch today, wouldn’t HTML5 or Qt be the best solution? Yes I hate VNC, Citrix and the like. Today’s HMI’s are full of animations, and while I think they are useless, they are slowing down things when working remotely. The best approach in my humble opinion is Qt, with a clean separation of HMI and rest of (real time) application, with Qt front end being deployed natively under Windows, Linux, Mac, Android, etc. and run locally on QNX just fine.
Sooner or later you would have had to replace it anyway, so it’s good that you have started. Your customers
a) won’t accept the old fashioned Photon user interface, will expect modern look
b) will ask for access from mobile devices like smart phones, tablets…
c) may not be ready to install software to access your system (that would be an argument against Qt and for HTML)
Just my 2 cents.
Isn’t the overhead not very relevant as you can do it on a very low priority? And in your case, if you don’t even have a local display, with HTML5 you would be off-loading the HMI rendering to the remote end.
QNX has worked with KDAB to provide a Photon to Qt migration framework. That’s more than QNX had to do, as their big Auto customers don’t care about Photon anyway.
One important thing to add here, though. QNX had to heavily invest into Automotive to become big there. Usually it takes several years after such an invest pays off. In the meantime, how did QNX stay alive, where did they get their money from? Of course from those old trusty Industrial Automation customers using Photon and Phindows.
there doesn’t seem to be any straight forward way to create a QNX target file system from Momentics.
Checkout the new 6.6 commandline utilitity - mkqnx6fsimg
Does QNX 6.6.0 contine to support multiscreen applications (on multicards hardware) ? Like it was implemented on QNX 6.5.1 Photon GUI (shifted X,Y regions).
If it’s to be display natively the browswer add lots of overhead compare to simple draw request sent to screen or photon.
Furthermore all HTML applications develop with QNX tools (not sure it if included in 6.6 or separated product or not yet release) can only be displayed in Torch( the QNX browser) and NOT, yep NOT in any other browser.
All the HTML stuff I did so far I’ve done with Witty ( HTML library ) since QWindows was drooped i have avoided as much as possible to really on anything GUI related comming from QNX.
By the way QT stuff is probably ok if you’re are a big customer who will sell lots of unit, but I get the feeling that for smaller market the cost of going through a 3rd party solution is going to be prohibitive, but that’s just a guess, did check.
Qt is open source. There are two licenses. One is a commercial license that you pay for and presumably can get support from Digia with. The alternative is a GNU license. The GNU license lets you use Qt for free, however you must use external .so files or disclose your code. For most users this is just a technicality.
Yes, but because of the way we build our custom image for customers the way I did it doesn`t really apply to most people setup, it think.
I basically took our 6.5 build setup, then overwrote every executable one by one from the 6.6, release. That left Photon intact and I didn`t had to figure out which files were needed for Photon as that work was already done when we create our 6.5 build. It pretty much worked first time.
The only problem I have encountered so far is "on -f ‘localnode’ doesn’t work anymore
I see so basically, you are using 6.6 kernel and built 6.5.0 filesystem with photon lib and binaries (without recompiling) since they are compatible. Phrelay and Phindows work also as expected? This is promising, I will try it my self in the coming month as well.
In fact at one point I, by mistake, used a boot file (with proc/net/disk stuff) I created with 6.6, use it on our 6.5 custom distribution and it worked.
An update here is overdue. Unfortunately the mkqnx6fsimg utility does not work in the context I was looking for. It will not create a bootable x86 QNX partition image. .
So the only way to resolve my problem using only QNX 6.6 right now is to use the QNX provided VMWare target. This creates a chicken and egg problem, since there’s no way for a QNX user to create this VMware.
Today’s HMI’s are full of animations, and while I think they are useless, they are slowing down things when working remotely. The best approach in my humble opinion is Qt, with a clean separation of HMI and rest of (real time) application, with Qt front end being deployed natively under Windows, Linux, Mac, Android, etc. and run locally on QNX just fine.
.