[Xaphiosis]

Originally Posted by kartu

I wonder if your findings could help openinkpot guys (or other way round ).

OpenInkpot sounds interesting, but regarding the 505 and 600 they didn't get very far. Once I have the touch screen figured out, I may be able to suggest something. The general app concept looks interesting, and may well be worth porting to the PRS600.

So, to summarize, you know how to update the screen as well as how to decode button press events. The remaining "white spot" is understanding touchscreen messages.

That's right. Other things that are left: interfacing to the battery/charger controller (to at least know how much battery is left), controlling sleep modes (e.g. telling the touchscreen to stop scanning for input), audio (this shouldn't be too hard, I think it runs ALSA and has a /dev/dsp).

I'd also like to put the functionality for running stuff off the SD card automatically upon its insertion into the porkupan firmware and maybe asking him release a new version with that in it, so I don't have to repeat the "hold VOL+ and HOME while inserting SD card" instructions every time.

1) If tinyhttp is already started and has obviously opened /dev/ttymxc1 could an app that's started afterwards (without killing tiny) get access to it?

At first I thought the answer would be "no". However, I've logged in to the device via USB and forgot to kill tinyhttp, then ran my subcpu logging program and it worked fine. I think there's a possibility of losing the very first message it sends (e.g. you press a button, but only get a button release event), but after that it works reliably.

Note that this is while having tinyhttp run a script via the "fskLoad" mechanism, so tinyhttp thinks it's in the middle of loading a module/extension. If you were to actually run a daemon alongside a running tinyhttp, my guess would be that you'd get some subset of the messages, and tinyhttp would get the rest, which would be amusing. However, as I don't see the point running two UIs simultaneously, I guess the answer to your question is "yes"

2) Do you (incidentally ) know how screen rotation works? I had an illusion, that it's done somewhere on driver level, and that code changing it's state is in ebook.so and if disassembled, it could be easily determined, whether rotating screen in the opposite direction was possible.

Screen rotation. Hmm. Well, I've never tried it, but it looks like the broadsheet driver supports "orientation" via

#define FBIO_EINK_SET_ORIENTATION		0x46F2	//Sets picture orientation angle (0 for 0, 1 for 90, 2 for 180, 3 for 270 degrees)

The question, however, becomes what this actually *does*. As far as I understand it, there are 480000 bytes in the frame buffer. This makes it possible to have 800x600, 600x800, and the "upside-down" variations for each. For switching from an orientation to its upside-down form, I'm guessing the software writing to the framebuffer doesn't need to do anything special, but obviously to rotate by 90 degrees, the "width" of the screen changes, so the software needs to adjust what it's doing. I can test this theory, but the soonest I can get back to you about it is in about a week.

If you just want to modify ebook.so to change its "sideways" rotation to be clockwise instead of counterclockwise, that should be doable.

In ebook.so, the assembly for EInkSetOrientation supports all four possible orientations (by the looks of it, it does a switch on some value, goes down four possible branches figuring out the new width and height of the screen, does an ioctl on the framebuffer device, then announces the new event to the Fsk world). Looking at ebookEinkDoRotate, it only supports two orientations: 0 and 1 (90 degrees). So changing it to be 2 and 1 would be trivial, however adding functionality to support all orientations, or even 0/1/2 would require more knowledge of the Fsk system than I currently have.

The problem is that I can't see the mapping between the functions I see at the assembler level and the functions at the Fsk level. This is because the Fsk thing loads up some bizarre structures into a strange array, then does stuff like in FskCore.xsb (using igorsk's DeFsk):

this.FskInclude.load = this.@[170]

I have no idea how to figure out what this corresponds to at the .so level. The 170 is arbitrary, and I don't even know which .so module it comes from. At a random guess ebookSystem.so, but I wouldn't be able to prove it. I showed it to a friend, who said it looks vaguely like the magic mozilla does with their XUL<->C interfacing, but he didn't have a clue how to resolve it either.
So, in conclusion, the best I can offer you with my current knowledge is an ebook.so that rotates to orientation 2 instead of orientation 0.

3) Does device respond to power switch, if tiny is dead?

If you mean the power slider on the top of the device, then you can see from my log that it only registers as a normal button press/release. It is no longer linked to any power functions when tinyhttp is killed. Relating to your question 1, since opening up /dev/ttymxc1 works during an fskLoad event, the power slider also does not function in those circumstances (e.g. running a script from the igorsk/porkupan loader).

So if anything goes wrong, you'll be needing to poke the reset button with your stylus. This is why I like working through the shell, if I make a stupid mistake, I hit ctrl+z to background the program, ps to get its pid, and then I kill it. When I'm done, I execute poweroff which turns off the device.