Ok, so now we can run anything we want on the Reader, and it's easy. Yay!

Now... how would we go about compiling for it?

Building an a cross-compiler isn't too hard, but maybe someone's already done the deed? (I'm still pissed off why a linux cross-compiler has to be "built." Why can't compilers just compile whatever you want them to? Microsoft's VC++ doesn't care if it outputs x86, x86-64, or even Itanium.)

Also, where do I find all the headers (which specify framebuffer ioctls, for example)?

hey Alex,

maybe I missed something...
I saw posts that describe how to modify the Reader's file system, but I wouldn't say we have an easy way to run our own apps.
Please let me know if you know otherwise!

Also, where do I find all the headers (which specify framebuffer ioctls, for example)?
Check libro_fb sources here:
http://www.sony.net/Products/Linux/
You can also most probably just recompile programs that were released for Librie.
sic,
inspect the shell scripts that come with the flasher.

thanks a lot! I found a crosscompiler tutorial for the Reader here:
http://www.the-ebook.org/forum/viewtopic.php?p=64904#64904

also a nice tutorial for framebuffer programming here:
http://web.archive.org/web/20051223073044/http://devel.linvision.com/doc/fbh/current/x267.html

the framebuffer driver for the reader is very clearly written. frankly, i'm surprised sony even posted the sources. one great find is that eInk has built-in functionality to do auto-refresh. You just call a few ioctls, and now eink doesn't fade! This was really bothering me quite a bit.



OK, now... how do i capture input??

I've found this:
http://www.sven.de/librie/Librie/SoftWare

But the damn link is broken!

Check http://www.public.asu.edu/~ajennin/librie.html
Basically, you need to read /dev/ttyDB0

"Basically, you need to read /dev/ttyDB0"

It seems to be a lot more complicated than that. /dev/ttyDB0 is apparently not a terminal for getting keystrokes but an interface to an auxiliary microcontroller or some sort of driver. From this interface one can read various messages, including those coding keystrokes.

What simplereader does is read all the messages, ACk all the messages, and then filter out the keys. This might hinder the other functions of the Reader. The link I posted in my previous post talks about this, but I'm not sure its solution of ignoring messages it doesn't understand will do anything (they'll get sent again, but who's going to read them if i hog ttyDB0?).


The real problem, however, is that I don't know thr codes. Simplereader defines the Keydown message type and the letter keys of the Librie (which was qwerty). Big help. I don't know the keyup message (but ok, i prob don't need it), much less the codes for all the buttons on the Reader. Perhaps I can just figure it out the hard way by reading messages and pressing buttons. But maybe there's a reference?

Another problem is that the mechanism inherently requires polling, which'll either destroy the battery or destroy the responsiveness. Surely that's not how the reader's native software does things?

p.s. how did the person who wrote simplereader figure out how to interact with ttyDB0? Is there Sony source code somewhere? Plain brute force?

I couldn't find any description of the command in kernel sources. Reader's implementation of keyboard handling is in ebook.so, you could try disassembling that.

"Reader's implementation of keyboard handling is in ebook.so, you could try disassembling that."
sigh.

ok, so I guess i'll have to find out the key codes just by pressing buttons. i guess it won't be _that hard (easier than reading ARM disassembly!). do you know if i can open a text console and simply do printf? or do i have to interface through the framebuffer?

but the polling... the damn polling... :angry:

Is polling really going to affect the battery life? Experiments appear to have shown that the Reader's power consumption is pretty constant regardless of whether the machine is on or "off". The CPU never seems to go into its low-power "standby" state.

harry, think about what happens when you play mp3s. using the cpu definately will affect power consumption, and constant polling is pretty taxing.

however, on second thought, i think polling every 10 ms or so won't affect the battery much and will also give perfect responsiveness.

then after 10 minutes of inactivity i'll...

no, wait, what will i do? it probably will not turn itself off like it normally does since i'm stealing all the messages. either that, or it'll turn itself off all the time because i'm stealing all the messages...

Hopefully it won't turn itself off, and I think I can just cut down the polling to be even more infrequent and put the screen into standby (there's an ioctl for that). Hopefully you're right, and my slow-polling method will yield the same two weeks of battery.

But I really wonder what i'll be affecting by messing with /dev/ttyDB0. Am I going to have to take over everything, including the power button? Even battery status supposedly gets conveyed over ttyDB0 so I might have to do that too (which is good, seeing as it doesn't work now!). But I'm not sure how i'd decode the messages for things like that.

The only thing I pray for is that the reset button doesn't use ttyDB0 ;-)

Is there no way of processing the messages that interest you, and passing the others on to whatever would have processed them had your code not been there?

I don't know. I think when you read them off of ttyDB0 they're gone. If you don't send an ACK, however, they should get sent again. If someone else is reading the device as well, then maybe that agent will read half the messages and things will eventually be processed. But then if that daemon is reading half the messages, it might swallow up the key presses AND ack them so that I never receive half the input.

I don't know, it's all theoretics at this point and i have to try all of this in hardware.

Ok, I'm up and running and got framebuffer access working.

Having done some benchmarks, I can continuously refresh at 2bit without black/white transitions in under 0.7s per screen. Not too bad. I think with prefetching the next page into the screen I can get latency down even more (but i'm not sure how to measure this empirically).

However, I can't for the life of me get 1b mode working. I can switch into it, but the memory layout is bizarre and I can't display anything. This sucks, because I was really hoping for some killer refresh rates using 1b mode. If no one here knows anything about it, maybe i'll email the guy who wrote simplereader.

also, the auto-refresh doesn't seem to work. sony probably disabled it. that's too bad, but it's ok. I can just do the refreshes manually.

ok, next step is to render some text and list the files and folders on the sd card.

Ok, how about some easy questions that I think igorsk can answer:

How much free disk space does the Reader have for my programs? The freetype library alone, for example, is almost two megs.

On a related note, can I run programs from or store libraries on the SD card? If yes, will bad crashes happen if the SD card is removed?

How much free memory does the Reader have for program code and heap?

How much free disk space does the Reader have for my programs? The freetype library alone, for example, is almost two megs.
On a related note, can I run programs from or store libraries on the SD card? If yes, will bad crashes happen if the SD card is removed?
How much free memory does the Reader have for program code and heap?
Free space depends on which partition you want to use. /Data has approximately 96 megs, minus all the books you have stored. /opt is 7MB compressed, but it's read-only meaning you need to reflash to add files to it. /opt0 has 3 megs, and /tmp is a 4MB ramdisk (gone after reboot).
You can run programs from the card if you mount it first.
Memory infro from dmesg:

Memory: 64MB = 64MB total
Memory: 62676KB available (1391K code, 321K data, 80K init)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)

wow... it's got more free ram than a nintendo wii (http://www.coolgameszone.com/nintendo/nintendo_wii_specs.html) >=)

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.:grin2:
Norm

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

...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?

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.

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.)

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. :shrug:


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

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: http://www.mobileread.com/forums/showthread.php?p=73267

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?!?!?! :angry:

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"

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

cool, thanks!

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

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.

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.

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

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.