on armv6hf?

Erik De Rijcke derijcke.erik at
Tue Mar 17 19:55:18 UTC 2015

Why didn't you target drm/kms gl  approach? I realise not all platforms
support this, but it would greatly extend the number of supported
(embedded) platforms in a generic way. A quick google search seems to
indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6).
An RPi drm/kms driver also seems to be in the works and a lot of upcoming
arm gpu's seem to be supported as well. By targeting kms/drm you'd be
supporting a lot of platforms with a single codepath now and in the future.

Unrelated, embedded jfx should use instead of it's own
bug-risky evdev/raw kernel input implementation. ;)

Now if just somebody would sponser me so I can work fulltime to implement
these things ;)

On Tue, Mar 17, 2015 at 7:39 PM, David Hill <David.Hill at> wrote:

> On 3/17/15, 8:04 AM, Erik De Rijcke wrote:
>> Why are there limitations on the "embedded" port of javafx to begin with?
>> Are there technical reasons for it?
> Quite a few actually....
> The "embedded" platforms have quite a few "features" that make them
> difficult. (and I have the bruises to prove it :-)
> To start with, an "embedded" application is usually a single purpose
> instead of a general purpose computing device. Think a kiosk for example.
> When I say general purpose devices - I mean classic desktops and now the
> mobile platforms, where the expectation is that the machine will be used
> for a number of application.
> Several of you will say that I am wrong, that a Raspberry Pi for example
> behaves just like a pokey "desktop" machine. This is a case where the lines
> have blurred and will continue to get more blurry. The Pi was one of a new
> generation of ARM platforms that have a community around them - a place
> where you can both buy a cheap board and get an OS and drivers without an
> NDA. So just as you can make a kiosk using a desktop machine, you can also
> use the PI with XMBC as a media center.
> As part of the "embedded" FX team, our design center was less the Pi
> running with X11, but rather a direct to framebuffer (without the overhead
> and limitations of X11). And the Pi was an after thought for us, a way to
> help out the community. We were targeting a more modern platforms liek the
> i.MX6.
> The problem with the direct to framebuffer, and to some extent with the
> rest of the ARM platforms - the platforms are really fractured and it is
> hard to build a working distro. I personally spend many a frustrating day
> trying to get some ARM platform to do something we take for granted on the
> desktop. Starting with.... OpenGLES drivers, especially ones that would
> talk to the framebuffer (and not X11). The Pi is one of the few examples
> out there of a port that has an easy download that contains most of the
> needed drivers already integrated (and documented). I spent almost a week
> fighting the Beagle Bone Black before getting up. Oh yes - and add on top
> of this all that GL initialization direct to framebuffer is non-standard
> API, so we ended up with 3 code paths for the platforms we were able to
> build.
> So in summary it is easy to download a Linux distro. The hardpart is right
> after you do that, and you want the proprietary hardware accelerated
> drivers. There are very few platforms that make this easy.
> And the Pi (version 1) is really too slow. The i.MX6 has enough power for
> a real application. The ODROID U3 and XU are also pretty spiffy, but I
> could not get direct to framebuffer working for either of those. If you
> want to use X11 - OpenJFX will probably work for you, and it might even
> have graphical acceleration if the drivers are present and integrated.
> Our Embedded team had ARM media as the next big thing to do, but ...
> So now we have all of the gstreamer code in the OpenJFX repo. I really
> expect that media on the Pi (1) will probably not work well due to the
> speed of the CPU and the memory bus. Maybe the Pi 2.....
> Again, you really need the right drivers in place to take advantage of
> hardware accelerated decoding of the media stream.
> With the right gstreamer libraries and drivers, I expect the media port
> would not take that long for someone that understands gstreamer.
> There might need to be some changes in Monocle to take the video stream
> hand off.
> I really would not expect that media would work without some debugging,
> and that after getting the build issues worked out.
>> If you think about it, "It's arm, so it's embedded. It's x86 so it's
>> desktop" doesn't make much sense... (atom is embedded, and there are arm
>> windows netbooks that are not).
>> Anyway, as a workaround, can't openjfx simply be compiled on an arm host
>> (so no cross compilation is required) and as such generate the missing
>> libraries? Qemu with an arm vm can be used to do that on an x86 host for
>> example.
>> On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici<
>> Fabrizio.Giudici at>  wrote:
>>  On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick<
>>> felix.bembrick at>  wrote:
>>>   I really admire guys like this and wish that my own personal
>>> circumstances
>>>> enabled me to get involved in a similar way but my main concern is that
>>>> the
>>>> "community" required to make JavaFX truly viable on iOS, Android and ARM
>>>> needs to be about 50-100 times bigger than it currently is.  Without an
>>>>  It's my concern too. At this point we're at 20 years of Java, and I
>>> lived
>>> them from the very beginning. The idea "the community will fix it" is a
>>> déjà vu that, unfortunately, says that in the past the thing didn't work
>>> many times.
>>> This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2
>>> arrives, I'll try the option you and others suggested.
>>> --
>>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
>>> "We make Java work. Everywhere."
>>> - fabrizio.giudici at
> --
> David Hill<David.Hill at>
> Java Embedded Development
> "A man's feet should be planted in his country, but his eyes should survey
> the world."
> -- George Santayana (1863 - 1952)

More information about the openjfx-dev mailing list