[Rev 01] RFR: 8227425: Add support for e-paper displays on i.MX6 devices

[John Neffenger]

> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements
> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx*
> repository. Some of the changes were made to support the new device models, while others are minor changes to the
> existing support in JavaFX 13.  The following changes were made to support the new device models.
> * Work around problems on the Kobo Glo HD Model N437.
> 
>     Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is
>     ignored by the driver on the Kobo Glo HD where the error occurs, anyway.
> 
>     Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of
>     the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame
>     buffer device driver can be an incorrect value.
> 
> * Work around problems on the Kobo Clara HD Model N249.
> 
>     The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the
>     normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The
>     work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*.
> 
> The following changes were made to the existing code that supports e-paper displays in JavaFX 13.
> 
> * Use the correct constant for the number of bytes per pixel.
> 
>     Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when
>     calculating the capacity of the 32-bit off-screen byte buffer.
> 
> * Do not round the luma value to the nearest integer.
> 
>     Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of
>     rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10
>     percent and doesn't seem worth it for a display with just 16 levels of gray.
> 
> * Change camel case of system property *y8inverted*.
> 
>     Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it
>     is consistent with the other system properties containing Y1, Y4, and Y8 in their names.
> 
> * Improve error handling when mapping the frame buffer.
> 
>     Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a
>     `null` return value from `EPDFrameBuffer.getMappedBuffer`.
> 
> * Replace non-ASCII characters with their ASCII equivalent.
> 
>     Replace non-ASCII characters in comments and log messages as follows:
> 
>     * "×" with "x" for display resolution and color depth,
>     * "×" with "*" for multiplication,
>     * "→" with "to" for transition, and
>     * "°C" with "degrees Celsius" for temperature.
> 
> * Add descriptions to Monocle EPD system properties.
> 
>     Add Javadoc comments to each constant that defines a Monocle EPD system property.
> 
> * Rename `IntStructure.getInteger` to `IntStructure.get`.
> 
>     Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method
>     `Integer.getInteger`, which gets the integer value of a system property.
> 
> Below are some of the more interesting test results.
> 
> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray
>   values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16.
> 
> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black
>   for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that
>   displays black for values `0x7F` or less and white for values `0x80` or greater.
> 
> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the
>   tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame
>   buffer. I plan to investigate the cause of the performance difference.
> 
> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold
>   increase in the number of pixels in their displays. The table below shows the animation speed of each model in
>   milliseconds per frame and frames per second.
> 
>     | Product Name  | Speed (ms) | Rate (fps) |
>     | ------------- |:----------:|:----------:|
>     | Kobo Touch B  | 125        | 8.0        |
>     | Kobo Touch C  | 130        | 7.7        |
>     | Kobo Glo HD   | 140        | 7.1        |
>     | Kobo Clara HD | 145        | 6.9        |

John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since
the last revision:

 - Merge branch 'master' into monocle-epd-imx6
 - 8227425: Add support for e-paper displays on i.MX6 devices

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/60/files
  - new: https://git.openjdk.java.net/jfx/pull/60/files/aa335246..f7028e89

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/60/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/60/webrev.00-01

  Stats: 322794 lines in 6225 files changed: 185606 ins; 92697 del; 44491 mod
  Patch: https://git.openjdk.java.net/jfx/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60

PR: https://git.openjdk.java.net/jfx/pull/60