PRS-600 Accessing the display via /dev/fb fails silently... any ideas why?

[Xaphiosis]

I do hope someone might be able to help. I got the arm toolchain going from http://www.emdebian.org/tools/crossdev.html so I can kinda compile code to run on the reader.

Background:

So I went and wrote two hello programs, one in asm I found somewhere on the net, and the other in C (I just wrote the usual one). I also wrote an attempt at accessing the framebuffer device (/dev/fb) cobbled together from various places on the net. I then added their execution to porkupan/igorsk's firmware loader script (load_test.600.sh):

echo "ASM:" >> $W_LOG
/Data/test/hello/hello_asm 2>&1 >> $W_LOG
echo "C:" >> $W_LOG
/Data/test/hello/hello 2>&1 >> $W_LOG
echo "FB:" >> $W_LOG
/Data/test/hello/fb 2>&1 >> $W_LOG

Ok, so hello_asm and hello work fine:

ASM:
Hello from Asm!
C:
Hello from C!

Problem:

The execution of fb proceeds successfully, here's the output:

FB:
Attempting to access the framebuffer device
Screen mapped: 600 x 800, 8bpp
Type: 0, linelen: 600, smemlen: 480000
grey: 8, rotate: 0
Sleeping for 1 seconds.
Exiting.

However, nothing happens to the screen! I put the code into a loop which hammered /dev/fb continuously with all possible values, I made the script wait, nothing changed.

I'm attaching the code, but it's vanilla framebuffer access code via mmap, so I don't see why it isn't working, especially when no errors occur :(

[Xaphiosis]

Ok, it's definitely not my code. I pulled the framebuffer before and after my code runs ("screenshots" attached). Clearly, my code's output is sitting in the framebuffer afterwards, it just doesn't get drawn to the physical screen. Looking at the options the kernel was compiled with, it's using CONFIG_FB_DEFERRED_IO=y but not CONFIG_FB_VIRTUAL, so I don't see why it's doing this to me. Sigh.

[kartu]

Check this out: https://www.mobileread.com/forums/showthread.php?t=48704

[Xaphiosis]

It definitely looks promising, but I can't make heads or tails out of it. My system can't even open most of the files on that chinese forum either

Is there something specific in there you had in mind?

[Xaphiosis]

I found (via google translate) a russian site where they discuss the chinese firmware you mentioned, kartu. They do manage to figure out some of the protocol used by the actual hardware device, but it's a bit wobbly.

First, the quick answer to my question: what was wrong? Simply writing to the framebuffer won't do anything on these kinds of devices. You need to tell them to sync the memory with the display.

Fortunately, I've found that there is a driver in linux (at least the one on the sony website) that handles the vizplex screens like the ones in the PRS600. It's called "broadsheet". Looking at broadsheet.c, I looked at their ioctl handling code, then at the available commands in broadsheet.h. Stuff like FBIO_EINK_UPDATE_PIC looked very promising, so I started playing around with that.

Unfortunately, every time I tried to paint something to the screen using an ioctl, I'd freeze my reader, requiring a hard reset with the stylus and magic button. Google doesn't help; there appear to be no matches of anyone actually *using* that driver, only some politics about accepting it into the linux kernel.

After hitting my head against the wall, I checked the power status of the display. I'd just assumed it would be POWER_MODE_NORMAL as it just got updated a second ago. Nope, it was POWER_MODE_SLEEP. Changing the power mode to POWER_MODE_NORMAL made the screen updates actually go through instead of freezing the reader.

The driver is kinda undocumented though... updating using upmode=0 causes some strange flashing and only some shades to come through; upmode=1 has a few shades come through (transparency?), but no flashing. Modes 2 and 3 seem to allow all shades to come through, but mode 3 apparently updates the entire screen, not just a partial update.

Anyway, code attached. I'm just drawing the test pattern in the first post of this thread, but now at least it works.

Code and binary attached.

[Xaphiosis]

Sigh. I'd really like to change the thread title to have [SOLVED] in it like I changed the top post, so people browsing see that it contains the solution, not just a problem.

[kartu]

Xaphiosis
I am not into linux programming, just remembered that it was possible.
You also might find this interesting:

https://www.mobileread.com/forums/showthread.php?t=68103

[Xaphiosis]

You may not be into linux programming, but your memory is a goldmine! Thanks

If I can figure out how to interface with the buttons and/or touchscreen, then maybe something like embedded qt will make an interesting next step.

A comment on igorsk's blog says that the buttons/touchscreen and maybe other events come in via /dev/ttymxc1 but the protocol is not documented, so it'll take a bit of head-scratching. Still, I can control the display now, so there's progress :P

[kartu]

Xaphiosis
Harnessing it this way:
https://www.mobileread.com/forums/showthread.php?t=11280

Might bring better results. (unfortunately it didn't work for me (I was thining about writing an fb2 viewer) with the latest ebook library, probably because some interfaces have changed, program was just eating heaps of memory non-stop) As it's easier to debug stuff on a desktop...

Igorks mentioned somewhere that he's stopped developing it, due to the lack of interest from users. Maybe if you contact him in a polite way, he'll have a look what's wrong with the current version.

Sony's current UI is (somewhat) easily programmable (and obviously easily debuggable/fixable) using javascript. Compiled stuff is needed only for performance critical apps (viewers).

PS
There is another eink related linux project:
http://openinkpot.org/wiki/Hardware

Somebody has tried to port it to 505, but didn't manage it. Anyway it's a place to ask people eink/linux related questions.

PS
I have a version of PRS-600 firmware, that calls shell script on startup if reader is not connected to USB (to be able to unbrick it, if you've screwed something via custom script) ), in case you something like that. mount --bind from there works like a charm. If you "bind" stuff directly from /Data, it might have unpleasant side effects when modifying files, but copying file to /tmp or dict partition (there are about 10 mb's of free spaca afair) works perfectly.

[Xaphiosis]

Yes, playing around with Fsk will definitely yield better results than my approach, as will your approach (PRS+) of hacking around within the ebook setup by using javascript/xml.

Truth be told, I'm doing this for the fun of it. Since I got my reader and installed porkupan's software, I've learnt a lot about the linux kernel, drivers, ELF executables, filesystems, reverse-engineering, dynamic linking, polished up my python skills a bit, got to code in C again, refreshed my knowledge of ARM instructions and got a cross-compiler installed. It's awesome fun, even if drawing to the screen is all I have to show for it

On the other hand, I investigated the javascript/xml hackery that is the sony software before I started on my current path. I wasn't really impressed with it, but more importantly, I was completely uninspired. There's hooks coming in from everywhere, being thrown around, functions being defined in xml and then called from javascript, strange vm.xml files needed, etc. The knowledge gained this way is not so exciting for me, as I'd only learn about the sony ebook/fsk setup. Brushing up on javascript might be interesting though, so I might take a look in a while and maybe even try help with your PRS+ efforts.

My inspiration or lack thereof doesn't have anything to do with what I think of your efforts though. I am seriously impressed with everyone who got PRS+ going.

Running shell scripts from the firmware on startup I can indeed do. What I would really really like to know is if there's a way to put a hook into the whole fsk/xml/js thing so that it would run a script from an SD card when I insert one. Whether by copying it into /tmp first or not, doesn't matter. I can't figure out how to make a hook that responds to the insertion of an SD card. I would very much value your throughts/advice on this matter.

[kartu]

You could hook FskCache.diskSupport.canHandleVolume then call external shell script using igorsk's libfsk.