iLiad Another Powersaving idea?

[nekokami]

I don't get it. How could iRex have missed this? They said they tried things like this (over on the iRex forum). As far as I can tell, nothing the iLiad does requires a fast processor, given the inherent latency of the e ink display. I'm trying to imagine some mythical B2B need that would exclude scaling the processor down....

[k2r]

Originally Posted by CommanderROR

That makes the total uptime around 15:30 hours. Not really great, but a nice improvement over the standard configuration.

Well, it this would be close to doubleing my runtime and would mean that I would not run out of battery during the day. Of course it's still far from leaving your travel-dock at home during holidays. Though it would be possible displaywise, I'm absolutely sure that it's not possible hardwarewise because somebody completely fscked up the hardwaredesign there.

Originally Posted by CommanderROR

The next steps now would be to add voltage scaling and of course link the script into the iPDF launch.

The script is only meant as a comfortable way of testing runtime at different CPU speed. Please don't expect me to try integrating it into the launcing process of the viewers, I don't need a bricked iLiad, so this is exactly the area of the device I'll stay away from.
Apart from that I think that the best place (quickest win) to take advantage of frequency scaling would be iPDF. Give it a config-file in ~/ , do set min-speed and max-speed and make it set speed to min-speed if rendering is completed and set it to max-speed during rendering. min-speed and max-speed can be set to the same values if you don't like speeding up.
The config-file could be set up comfortably using a script that reads and writes the parameters in manifest.xml, similar to my script. So we would not need an additional GUI element for iPDF.

And then hope that iRex somehow adapts the battery indicator.

Originally Posted by CommanderROR

Turning pages at 30Mhz is absolutely OK, no need to scale the processor up again.

I have to disagree here. I have some documents where 33 MHz are sufficient and then some complex documents that render too slowly. Maybe having iPDF not only read ~/.ipdfrc but even $DOCUMENTFOLDER/.ipdfrc would be a good and very simple idea. By this one could override the standard behaviour by placing a different setup in the folder of the document to open...

Originally Posted by CommanderROR

I don't know anything about programming, but there seem to be lots of websites with information about implementing powersaving for PXA255

I'm sure the iRex people have all the information but somehow (were) decided that powersaving by frequency scaling is not worth the effort. And they would have been right if they were capable of sending the system to deep-sleep and waking it up on button interrupts...

#!chris

[Mambo]

I am still worried about the fact that the screen is not cleared when I leave the device turned on for a long time. Could somebody implement a small software which would clear the screen and leave it that way until I press a button. Then it would take me back to the content lister.
This way I would not be worried about images burned into my screen.

[Mambo]

It seems 33Mhz + larger battery + ability to turn off the screen with the press of a button (let's say short press on iDS) would make me happy altogether, despite the fact that there is no power saving. I can't wait to try this hack myself.

[k2r]

I just found an interesting paper:
Power Management and Dynamic Voltage Scaling: Myths and Facts

#!chris

[k2r]

Originally Posted by Mambo

I am still worried about the fact that the screen is not cleared when I leave the device turned on for a long time.

The screen is - except during the periods it's changing it's content - completely passive. As far as I understand if there is a wearing out it should happen if the screen changes it's content. So clearing the screen might even _lower_ your screen's lifetime slightly and eat up more energy.

[CommanderROR]

@k2r

I'm not expecting you to try anything dangerous...don't worry...
I'm just hoping that somebody will try it, or maybe this will give iRex the right idea...

About the page-turning...you are right of course. I was only using Plaintext PDF files, so forme the speed was adequate, with complex documents you would of course need more power!

[BACbKA]

Maybe having iPDF not only read ~/.ipdfrc but even $DOCUMENTFOLDER/.ipdfrc would be a good and very simple idea. By this one could override the standard behaviour by placing a different setup in the folder of the document to open...

instead of all this woodoo, a proper in-kernel cpu governor policy enabling should work much better and solve all the issues once and for all :-) yet another reason to welcome the unbrick asap

[NatCh]

Originally Posted by Mambo

I am still worried about the fact that the screen is not cleared when I leave the device turned on for a long time. <snip> This way I would not be worried about images burned into my screen.

E-ink doesn't work like a CRT or an LCD or plasma or whatever other active display you'd care to name. Since it works by moving physical particles around via an EMF (which is turned totally off between display changes), there's nothing to burn in.

Consider this, when the screen is blank, what you actually have is all the white particles on the top and all the black particles at the bottom, but all the particles (of both colors) are still there. They don't care if they're all together, mixed up, top, bottom, whatever, because they're just sitting where they were left, and they'll go on sitting where they're left until they're moved somewhere else.

Perhaps they will lose their charge over an extended time, and stop working then, but it won't have anything at all to do with what position (top/bottom) they were left in or for how long -- they just aren't affected by that.

[k2r]

Originally Posted by BACbKA

instead of all this woodoo

I don't expect us to get an unbricking solution within the next decade, so this Voodoo seems to be the most reasonable compile-it-yourself approach. It should be easily implemented by somebody familiar with the iPDF sources.

[BACbKA]

An alternative until then would be compile & ask somebody with the unbrick option already available (i.e., the irex folks) to test it and report if it works or crashes

[k2r]

BACbKA: There is more than a single reason I and every sane person would avoid taking part in a project like this. Avoid as in "like the plague" and in "run very fast".
ipdf is the only option.

[narve]

I don't have any power issues yet (I am not using it for so much time between charges) so I haven't tested any of this.

But as far as I can see, I would be adequately happy with manually running the "Turn on powersave options" script before I start reading ifI plan to read a lot and need max battery hours, like on long journeys (or whenever I don't feel like recharging). The preprocessing should make it unnecessary for me to turn the frequency up and down between page turns, at least for simple PDFs.

For me, the main bugger now is how slow the content lister is. Moving my hands to "rest position" after clicking "Books" just feels silly...

[Adam B.]

I can't believe iRex hasn't tried this. With the (planned) upgraded battery, and CPU downstepping, I don't see why we should be able to get the advertised 21 hours out of the iLiad.

[narve]

Originally Posted by Adam B.

I can't believe iRex hasn't tried this. With the (planned) upgraded battery, and CPU downstepping, I don't see why we should be able to get the advertised 21 hours out of the iLiad.

are you missing a "not" here?