How often is Linux used these days in embedded devices (non-android)? In the past Windows driver support was so much better that Linux generally didn't have much of a payoff.
Considering the convergence between tablet style devices and embedded devices (in car systems, in flight systems etc) and the fact the car industry seems to be standardizing towards Linux probably a lot more than it used to be.
Embedded stuff doesn't have the same life cycle turnover rate as consumer stuff though so the push will be fairly gradual.
Touchscreen drivers are pretty much a commodity now. You see a lot of the same manufacturers over and over (Atmel, eGalax/EETI, FocalTouch, TI, etc).
The problem is that every hardware designer hooks up a different GPIO line for the touch interrupt signal and so you're deep into the kernel to hook that all up.
Devicetree has made this lot easier now, though. Then you have smaller issues like setting up calibration and TSLIB/filtering files, but that's a lot easier than it was five years ago. Multitouch can still be hairy depending on the target O/S.
How far in the past are we talking? In the embedded devices I've worked on, Windows was never a consideration because trimming it down enough was a major concern, and as were licensing costs. Drivers, on the other hand, rarely came up as an objection to Linux - it doesn't take much volume before writing Linux drivers was the cheaper option, and if you have control of the hardware platform in the first place, picking options that worked well with Linux was easy enough.
That said, it's 16-17 years since I did much embedded work.
I always thought that Linux was actively avoided in embedded systems such as ATMs, Medical or Industrial Equipment, because the GPL forces you to release your source code.
That's a really old myth. Only if you intertwine your code with GPL code, use a GPL library, or modify GPL code do you need to release anything you write yourself. It is very very easy not to do any of those things.
One gray area (gray because two camps both think it's black and white in opposite directions) is writing any code that runs in kernel.
Very often. Vendors such as NXP/Freescale, TI, Intel (and Chinese manufacturers on top of MIPS) all tend to target Linux-first. For some drivers (e.g. wireless), you sometimes need to work directly with that vendor (Qualcomm/Broadcom/...). In my experience, it is almost the default except in cases where you need 1) Hard real-time, 2) Very low power (most battery applications), 3) Very low cost. Those still go to MCUs where life is more difficult for anything complex (e.g. requiring graphics, a network stack).
For most embedded use cases, Android is still not suitable as you have to jump through many hoops to get sufficient control over exactly how the device operates (you can make it work but the further away your device is from a phone/tablet, the harder it gets).
Source: Worked in embedded design services until recently.
Probably something you might want to check if you have the following tagline:
"A modern user interface that is beautiful on every screen
and performs perfectly on every platform is not an option,
it’s a necessity."
Their webpages are constantly moving, changing and breaking. The domain itself has moved 4 times in 4 years. There's just incredible churn on that side of the project, unfortunately.
Maybe they only tested it in the Qt WebBrowser (I'm only half-joking - it seems to work on "narrow windows", which would be in line with the type of devices on which this browser is supposed to work).
I can't believe the level of sarcasm and vitriol this is getting. Someone messed up! A bug that happens under specific circumstances that probably aren't being tested for (screen size above X) showed up. Happens to the best of us! The folks who work on the website probably aren't even the same folks who work on the toolkit. And what even if they were? Does that erase the awesome product they created? Sometimes the lazy negativity on the internet bothers me to no end.
IIRC Chromium still requires significant patchwork and build time flags to fully disconnect it from the mothership, the engine itself has no such dependencies
I use this humble little browser almost daily, to test that the web app I'm working on can run inside QtWebKit windows of desktop applications (mostly for making sure that I have all the necessary polyfills and vendor prefixes in place).
KDE was based around Qt and their rendering engine, KHTML became Webkit, which is a core part of Chromium. So Qt are using embedded Chromium, I wonder if there is any duplicated code in the repo now?
41 comments
[ 3.2 ms ] story [ 78.9 ms ] threadSo they have a partner using their technology, it is that weird that the browser works on that platform first?
Embedded stuff doesn't have the same life cycle turnover rate as consumer stuff though so the push will be fairly gradual.
I suppose this being qt, that's probably what you are talking about.
I haven't looked at the situation since 2011, so I'm not up to date.
Android has helped a lot in this regard. While still not perfect, it's definitely much more mature.
The problem is that every hardware designer hooks up a different GPIO line for the touch interrupt signal and so you're deep into the kernel to hook that all up.
Devicetree has made this lot easier now, though. Then you have smaller issues like setting up calibration and TSLIB/filtering files, but that's a lot easier than it was five years ago. Multitouch can still be hairy depending on the target O/S.
See also the members of https://www.automotivelinux.org/ and https://www.genivi.org/genivi-members
So, yes... its pretty popular. In fact, its the default choice for most things.
That said, it's 16-17 years since I did much embedded work.
One gray area (gray because two camps both think it's black and white in opposite directions) is writing any code that runs in kernel.
For most embedded use cases, Android is still not suitable as you have to jump through many hoops to get sufficient control over exactly how the device operates (you can make it work but the further away your device is from a phone/tablet, the harder it gets).
Source: Worked in embedded design services until recently.
The first step is the installer asks you to sign up or login. Thankfully there is a "skip" button.
Two are mildly sarcastic ("probably something you might want to check", "welcome to mobile first").
A handful that simply state "the site's broken".
The Internet can be a harsh place sometimes, but you should consider the possibility that you're being hyper-sensitive. There's really nothing here.
If so, why are you even asking the question?
http://www.qtweb.net/