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

Mon Apr 27 17:49:48 UTC 2020

On Fri, 17 Apr 2020 19:11:19 GMT, John Neffenger <github.com+1413266+jgneff at openjdk.org> wrote:

>> 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental
> views will show differences compared to the previous content of the PR. The pull request contains one new commit since
> the last revision:
>   8227425: Add support for e-paper displays on i.MX6 devices

Marked as reviewed by jvos (Reviewer).

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

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