PRS-500 Compiling for the Reader

[alex_d]

wow... it's got more free ram than a nintendo wii >=)

[NormB]

Thats great that the Reader has more free RAM than the wii. It is also great that so far I have not noticed any of the newly diagnosed medical condition wiiitis.
Norm

[alex_d]

ok, I got 1bit mode working. Turns out you also have to call ERASE_DISP after SET_DEPTH.

unfortunately, there was no speedup in the eink whatsoever. Turns out the 1s vs 0.5s isn't true at all except that Sony probably enables the black flashing for 2 bit and disables it for 1 bit.

I'll post the full results in the RasterReader thread

[NatCh]

Originally Posted by alex_d

...except that Sony probably enables the black flashing for 2 bit and disables it for 1 bit.

Does that mean you've got a non-black-flashing page change working?

If so, how's the ghosting on it?

[alex_d]

Yup, no flashing. I haven't tested it yet with real text or even grayscale images, only simple black-and-white boxes. I didn't really see any ghosting except that when you stop displaying the black box you get a faint outline (ie, the inside is fine, but the edge has some ghosting).

In short, it doesn't seem to be a big problem pending more testing. I'll also try sending the refresh command twice to see if multiple refreshes help.

[alex_d]

hmm... I had an idea. Flashing happens very quickly. It also uses separate commands. Maybe I can do a rough page turn more quickly if I use FBIO_EINK_POSITIVEPIC instead of FBIO_EINK_DISP_NEWPIC.

Edit: Strange, I can't make the Reader flash using POSITIVEPIC and NEGATIVEPIC! In fact, when I issue EINK_NEGATIVEPIC and quit, the display turns inverse and stays inverse. All books, including those encoded by rasterfarian, become white-on-black, and the reader FLASHES WHITE.

I'm upset that I can't get the lightining page turns, but I think I just discovered something really cool! The white-on-black mode even makes reading easier on the eyes.

Also, double refreshes work well to reduce ghosting. In RasterReader I'll do a single refresh when turning pages quickly, then refresh a second time when it seems the user has settled on a page. (And refresh again later to keep the eink from fading.)

[NatCh]

Originally Posted by alex_d

I didn't really see any ghosting except that when you stop displaying the black box you get a faint outline....

Sounds like what I see on a 'normal' refresh.


It also sounds like things are about to get very interesting around this thread!

[alex_d]

I've made a little package, based on igorsk's flasher, which will let you switch into and out of White-On-Black high-contrast mode.

Get it here: https://www.mobileread.com/forums/showthread.php?p=73267

[alex_d]

OK, I've got ttyDB0 mostly working. I've managed to figure out the control codes, but there still seem to be problems:

Occassionally, the response time is very good, but most of the time it's more than a second! WHY?!?!?!

Also, after my program exists, all the keys that I've entered get sent again to the regular Reader UI. Why?!?

Lastly, it turns out that everything else DOES stop working when I poll ttyDB0 incessantly. This includes the power button! Also, the power button doesn't have a key code associated with it (it must be another type of message).

key codes (gathered by trial and error):

#define KEY_1 0x72
#define KEY_2 0x43
#define KEY_3 0x73
#define KEY_4 0x44
#define KEY_5 0x74
#define KEY_6 0x45
#define KEY_7 0x75
#define KEY_8 0x46
#define KEY_9 0x76
#define KEY_0 0x47

#define KEY_CRCL_RIGHT 0x30
#define KEY_CRCL_LEFT 0x31
#define KEY_PG_RIGHT 0x70
#define KEY_PG_LEFT 0x71
#define KEY_VOL_UP 0x40
#define KEY_VOL_DOWN 0x41

#define KEY_DOWN 0x23
#define KEY_RIGHT 0x24
#define KEY_LEFT 0x25
#define KEY_UP 0x26

#define KEY_MENU 0x21
#define KEY_MARK 0x32
#define KEY_SIZE 0x42


eink commands (gathered from the driver):


0xA0 -- mark beginning of sending of screen data to the Eink controller's memory. I don't know if this starts sending per se or rather prevents multiple display calls from overlapping or does something else.
0xA1 -- mark end of sending screen data
0xAA -- get status -- used after sending to check transfer
0xA2 -- render the screen -- display the data that is in the Eink controller's framebuffer
0xA3 -- erase display -- makes the screen white. useful after changing depth.
	0x01
0xA4 -- eink init -- (1) used when initting the driver.
	0x01 
0xA5 -- restore pic -- display the previous image sent to the controller (ie, if you execute SEND_NEWPIC, you can undo it)

0xB0 -- begin sending partial screen data to the Eink controller. After this command, send the rectangle info.
0xB1 --	render the screen. The driver uses this in conjuction with 0xB0 althought oxA2 also works. Seems to be the same performance, so I don't know the real point.


0xF0 -- go to 'normal' power management state (the state during ioctl calls)
0xF1 -- go to 'sleep' power management state (the state between ioctl calls)
0xF2 -- go to standby power management state (the state while the Reader is "off")


0xF3 -- set depth
	0x00 2-bit 
	0x02 4-bit
0xF5 -- rotate.
	0x01 "rotate 90 degrees"	
0xF7 -- positivepic -- black-on-white mode.
0xF8 -- negativepic -- white-on-black mode. (doesn't seem to have anything to do with page-turn flashing)


0xFC -- refresh screen. is sometimes a substitute for display_pic. causes a flash.
0xF9 -- autorefresh on  (doesn't seem to work)
0xFA -- autorefresh off (see above)
0xFB -- set refresh time (used with autorefresh)
	0x64 -- "10 minutes"
0xFD -- get refresh time (used with autorefresh)


0xE0 "get_verocont" (0) NO IDEA what this does
0xE2 "get display status" (1) same


0x10 -- write register
	0x"set supply delay"
0x11 -- write register	

0x01 -- some sort of access of "flash." used by "clear flash", "write flash," also the "LUT." no idea what this means.
0x02 -- same

0x21 -- get eink temperature


0xEE "eink reset"

[igorsk]

I suggest you to compile strace and monitor all writes/reads from ttyDB0.

[alex_d]

cool, thanks!

I'm no guru in Linux. Tips like these are very helpful.

[alex_d]

ok, strace compiled.


however, how do i use it to intercept all reads/writes to ttyDB0? Seems like it only works with one program at a time, and just dumps all of its calls.

e.g., say i go one by one and luckily hook into the right process, but that process has already opened ttyDB0. How would I know the handle to match against read() calls? I must be missing something big.

[arivero]

while you are at it, you could try the processing of djvu from the tools in
http://dftuz.unizar.es/~rivero/lbdjvu.tgz

Also, attached you can see xclock running in the librie using the xvfb trick. It relies on xwdtopnm, included in the above tgz.

It was running over a 600x800x4 screen using a loop
./xwdtopnm /tmp/Xvfb_screen0 | ./pnmdepth 255 | tail +4 > /tmp/rawscreen
./pgm4biARM /tmp/rawscreen | ./putpic.arm

the depth depends on the framebuffer driver most probably it is different in the Reader.

Of course in a separate process, I run
Xvfb :1 -screen 0 600x800x8 -fbdir /tmp

and still in other
export DISPLAY=":1"
xclock

I am sorry I can not find Xvfb. It was compiled from the xorg sources for a X11R6 version.

[arivero]

How are you logged in your reader? with usbpdtg_con as in the librie?

[alex_d]

writing to the display is fine. the framebuffer driver is identical to the librie.

i'm stuck trying to read the buttons. using code for the librie it works, but there are several issues. The deal breaker for me is that its unacceptably laggy.

i am not logged in interactively. i can run scripts and compiled apps and also retrieve the output.