Post Reply

eInk update modes

27th March 2012, 03:33 PM   |  #11  
Renate NST's Avatar
OP Recognized Contributor / Recognized Developer
Boston
Thanks Meter: 807
 
1,995 posts
Join Date:Joined: Feb 2012
The native Reader.apk uses GU, ONESHOT_ALL when turning pages.
Every 6th page it uses GC, ONESHOT_ALL.
The Following User Says Thank You to Renate NST For This Useful Post: [ View ]
28th March 2012, 12:38 PM   |  #12  
Junior Member
Thanks Meter: 3
 
26 posts
Join Date:Joined: May 2011
In an overnight test with the nook screensaver / lock screen mode inhibited by my application and no screen updates, I obtained power consumption of 0.75% / hour with ONESHOT mode. In a previous test with ACTIVE mode I got ~7% / hour with the same scenario(!)

With fast screen updates of ~ 1Hz ONESHOT does not appear to give any power saving benefit over ACTIVE mode, and a quiet hiss can be heard from the screen at all times in both modes at this refresh rate. I think this indicates the ONESHOT mode allows the screen to enter a power saving mode after a period of inactivity.

Neither of these were scientific tests but I strongly suggest trying ONESHOT mode in favour of ACTIVE whenever using A2 mode.
28th March 2012, 01:02 PM   |  #13  
Renate NST's Avatar
OP Recognized Contributor / Recognized Developer
Boston
Thanks Meter: 807
 
1,995 posts
Join Date:Joined: Feb 2012
Well, there must be some benefit sometime to the ACTIVE mode or they wouldn't have it.
It's hard to differentiate the different modes, but it seem that ACTIVE responds quicker with less delay.

I switch to ACTIVE_ALL, A2 for panning and switch back to ONESHOT_ALL, AUTO afterwards.
(I don't use full-time A2).

See my demo of panning: http://forum.xda-developers.com/show....php?t=1563645

I'm running about 7%/hour drain. My Nook is not suspending when I do a simple power button click. I don't know why.
25th April 2012, 03:12 PM   |  #14  
Renate NST's Avatar
OP Recognized Contributor / Recognized Developer
Boston
Thanks Meter: 807
 
1,995 posts
Join Date:Joined: Feb 2012
A few folks seem to be using EpdController in a useful manner.
Their use of Java reflection is clever, but it's not supposed to be that difficult.

I wrote a Java stub (basically declarations) for EpdController and wrapped it in a jar.
If you just put this jar in your compilation classpath with your normal android.jar
then you will be able to use the EpdController without all the fuss and muss.

For example, in my latest (unreleased) version of UsbMode I want the blinker to go on and off cleanly:

Code:
EpdController.setRegion("UsbMode", EpdController.Region.APP_3, blinker, EpdController.Wave.DU);
That's it, one line, no initialization.
The EpdController class was designed to handle such trivial uses.

Note: This jar itself has no functionality, all the method bodies are {}.
You will have to import android.hardware.EpdController
Last edited by Renate NST; 15th August 2012 at 06:13 PM.
21st December 2012, 12:54 PM   |  #15  
Renate NST's Avatar
OP Recognized Contributor / Recognized Developer
Boston
Thanks Meter: 807
 
1,995 posts
Join Date:Joined: Feb 2012
The 1.2 update uses a different EpdController and has a new EpdRegionParams.
This may or may not break code written for previous versions.

The best way to write code to use EpdController is to have it detect if there is no Epd
(i.e. for other devices), the old version or the new version.
Wrap a try/catch around a Class.forName("android.hardware.EpdController").
Wrap a try/catch around a Class.forName("android.hardware.EpdRegionParams").

The new epd.jar in the signature will allow you to compile without using redirection both the old and the new.

For details on the changes, see: http://forum.xda-developers.com/show...92&postcount=8
4th June 2013, 12:36 AM   |  #16  
Renate NST's Avatar
OP Recognized Contributor / Recognized Developer
Boston
Thanks Meter: 807
 
1,995 posts
Join Date:Joined: Feb 2012
Bump & additional info.

By experimenting and reading documentation for other eInk controllers I've figured out the following:

Controllers support different algorithms for updating the pixels depending on the precision of the gray scale required and the compensation for previous ghosting.
On the Nook, we have the choice of waveform modes:
  • GC
  • GU (gray update)
  • DU (direct update)
  • A2
  • GL16
  • AUTO (auto selection of algorithm)

The screen can be divided up into regions where different algorithms may be used.
Some controllers support 15 regions, ours supports 8.
4 of these regions are earmarked for system usage, specifically:
  • Toast (popups)
  • Keyboard (soft keyboard layout)
  • Dialog (popups)
  • Overlay
The remaining 4 regions are left for the user.
Note: "HwRegion" is an enum for the complete 8 regions, "Region" is an enum for the 4 user regions.

An example: In my audio recorder I have two regions set aside for the VU bar graphs.
By setting these two regions to DU I get rid of update clutter and the response is quicker.

Currently, the EpdController in the Nook only operates with portrait coordinates.
If you wish to use this while in landscape mode you will have to rotate the coordinates first yourself.

It's sometimes hard to see exactly what/if some EPD setting is doing.
A good way to check it is to set a region for one half the width of whatever active graphic element you are trying to improve.
The difference can be very clear.
The Following 3 Users Say Thank You to Renate NST For This Useful Post: [ View ]
7th June 2013, 11:45 PM   |  #17  
Junior Member
Flag Manchester
Thanks Meter: 18
 
24 posts
Join Date:Joined: May 2013
Quote:
Originally Posted by Renate NST

There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.

I'd like to start this thread on a discussion of the update modes.

You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.

  1. Name of entity requesting change (for logging purposes only)
  2. Region, one of enumRegion[] (Region 4-7)
  3. A rectangle, normally {0, 0, 600, 800}
  4. Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
  5. Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
  6. Threshold, an int 1-15, only applies to A2 mode

A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.

Code:
      configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
      configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)

Does anybody have any further insight into these values or suggestions for improving them?

Excellent work! Do you happen to understand/can write up what the various fast mode/no refresh hacks do/how they use these different modes?
I've had X 'running' on my nook but only by triggering a full refresh every few seconds, and wondered how I could be more selective.
My reading of Norefresh was that it was doing something like parsing android log structures for areas that have changed.

Is there an easy way to trigger a refresh of part of the display from userspace, preferably directly on the driver or fb?

As for where the dithering is done, my guesswork is this is done by a blob running on the DSP module within the OMAP (which is perhaps the only interesting use of it I've seen).

Dave
9th June 2013, 06:42 PM   |  #18  
Junior Member
Flag Manchester
Thanks Meter: 18
 
24 posts
Join Date:Joined: May 2013
Just done some playing writing directly to the entires in /sys/class/graphics/fb0 ; so for example:

echo -n 100,100,200,200,0,14 > epd_area
echo 2 > epd_refresh

causes the square 100,100->200,200 to be refreshed
the 14 being REGION(8)+CLEAR(4)+ONESHOT(2)
the 0 is wvfid+threshold*65536 I think.

I've put some code that runs under X to trigger updates; here (actually the comment is wrong, it's currently using oneshot+clear);
I never managed to get active to work.

http://forum.xda-developers.com/show...3#post42393733
Dave
Last edited by p42; 9th June 2013 at 08:47 PM.

Post Reply Subscribe to Thread

Tags
eink, epd, norefresh, refresh
Previous Thread Next Thread
Thread Tools
Display Modes


Top Threads in Nook Touch Android Development by ThreadRank