Instructions for patching firmware 3.18.0

[NiLuJe]

@GeoffR: At the very least the H2O.

Possibly the Aura (to the effect of a few pixels at the *bottom*), but I never could properly confirm that.

It's easy enough to check: take a screenshot of nickel's homescreen with fbgrab, and look for rows of black pixels .

[GeoffR]

This patch will only be useful if you use the `ePub fixed/adjustable top/bottom margins` patch and have the top margin configured to be adjustable. If that is not you, then you might want to stop reading here.

Without this patch, you need to choose an adjustment multiple when configuring the `ePub fixed/adjustable top/bottom margins` patch to suit either full-screen or normal reading mode, and it is not possible to set a value that scales very well across the whole range of the margin slider in normal mode. This problem is caused by the built-in ePub top margin that is present in normal reading mode but not in full-screen mode.

Since I have been unable to find any way to remove that troublesome built-in top margin, this patch tackes the problem from another direction: it adds an exra left/right margin to compensate for the built-in top margin when in normal reading mode, but doesn't add any extra margin in full-screen mode.

This allows you to select the adjustment multiple that suits full-screen mode (e.g. 7 on the Glo) which should lead to the same margin proportions in normal mode too.

However all of this assumes that the body left/right margin and padding in the book are zero. If the book has a non-zero body margin or padding (or doesn't set a body margin at all which results in a small default margin) then the left/right margins will be too large.

(I edit all my ePubs to have zero body left/right margin and padding, and add a small default @page margin so that the books will still look okay if I read them on a device that doesn't have adjustable margins. The book's @page margin is overridden by the `ePub fixed/adjustable top/bottommargins` patch.)

Note also that the bottom margin will depend on the size of the footer. If you enable the `Disable reading footer` patch you get an invisible footer of 5px. You can change that to match the size of the built-in top margin (e.g. 15px on Glo and GloHD) if you wish.

I should add that I have been assuming that the ePub margins set by the margins slider are in multiples of 1% of screen width, because that is true on the Glo. However it is possible that this is not the case on all devices. I've only tested this on my Glo.


I'll add some screenshots later which should help explain what this is all about. This patch turned out to be more complicated than I first expected, so I might not continue with it if the refresh bug that affects full-screen mode is fixed.

Firmware 3.18.0, paste into libnickel.so.1.0.0.patch:

Spoiler:

<Patch>
patch_name = `Increase ePub L/R margins by 2% in normal reading mode only`
patch_enable = `yes`
#
# In AdobeStyling::update
#
#  setMarginSize(getReadingLeftMargin(...))
#  --> if (fullScreenReading())
#       setMarginSize(getReadingLeftMargin(...))
#      else
#       setMarginSize(2+getReadingLeftMargin(...))
#
#  setPageMarginSize(ceil(0.8*getReadingFontSize(...)))
#  --> setPageMarginSize(103*getReadingFontSize(...)/128)
#
replace_bytes = 45F16A, 01 46, 05 46
replace_bytes = 45F16C, 48 46, 20 46
replace_bytes = 45F16E, AD F7 CC E9, A0 F7 36 EC
replace_bytes = 45F172, 20 46, 29 46
replace_bytes = 45F174, 41 46, 00 B9
replace_bytes = 45F176, A3 F7, 02 31
replace_bytes = 45F178, B0 E8, 48 46
replace_bytes = 45F17A, 07 EE 90 0A, AD F7 C6 E9
replace_bytes = 45F17E, F8 EE, 20 46
replace_bytes = 45F180, E7 1B, 41 46
replace_bytes = 45F182, 9F ED B1 0B, A3 F7 AA E8
replace_bytes = 45F186, 21 EE, 67 21
replace_bytes = 45F188, 80 0B, 41 43
replace_bytes = 45F18A, AC F7, C9 09
replace_bytes = 45F18C, 68 EE, 00 BF
replace_bytes = 45F18E, BD EE, 00 BF
replace_bytes = 45F190, C0 0B, 00 BF
replace_bytes = 45F192, 48 46, 00 BF
replace_bytes = 45F194, 10 EE, 00 BF
replace_bytes = 45F196, 10 1A, 48 46
#
# Replacement value: size of extra margin, a percentage of screen width.
replace_int = 45F176, 2, 2
</Patch>

Edit: These screenshots are from my Glo readng a sideloaded ePub that has zero body margin and padding. They demonstrate the effects of the following patches in combination:
* `Disable reading footer` (height set to 15px)
* `Custom left & right margins` (default)
* `ePub fixed/adjustable top/bottom margins` (multiple set to 7)
* `Increase ePub L/R margins by 2% in normal reading mode only` (as above)

1. In normal reading mode (fullScreenReading=false) with the margin slider set to 0%, 3% 6%:


2. In full-screen mode (fullScreenReadng=true) with the margin slider set to 2%, 5%, 8%:


As can be seen the margins are almost identical (within a pixel or two) in both readng modes, the only real dfference being that the margins could be made two steps smaller in full-screen mode. The font is Gentium Book Basic (unhinted.)

[Nick_1964]

I hope I don't offend you because I know how much time you spend on it, but, and that is a big but, this only works with sideloaded epubs.. At the moment you sync your books, in the Netherlands Bol.com sends epubs to your device. Epubs that have margins and padding set. Then the only way to edit them is take them off or edit them with a computer while they are on the device, and that sometimes gives problems with the database. I switched to kepubs, so I don't sync, but with kepubs you always stuck with the header, you can make it "invisible" but then you keep that stupid blank lines.. I am grateful for your work, but hate it that I must switch on every new firmware between epub and kepubs and keep my reader near a computer all the time, I hope the full page bug will be fixed soon in a nearby update, or stay on 3.17.3 with ghosting.. It becomes a bit complicated... Kobo has nothing to do with your patches so they can fiddle around, leaving you always one step behind... It tooks 3 firmware update, so much patches and now the layout of the menus is back to 3.15 to stop ghosting... We had and lost sickel in between. What surprise will be in the next one.. I hope you will find something to get those blank lines on top of the kepubs and then I think I stop upgrading, I must edit the Dutch dictionary every time and win nothing at the end..

Sorry for "abusing" your topic, I admire your willingness to search every time for a solution, thank you!

[GeoffR]

Originally Posted by Nick_1964

I hope I don't offend you because I know how much time you spend on it, but, and that is a big but, this only works with sideloaded epubs..

Yes it only works properly if the book has zero left/right body margin and padding, and the only way you can be sure of that is to edit the book.

It might be possible to make a patch to override the body margin and padding in ePubs, but this would not work for all books, in particular it would not work for most books created or converted by Calibre because of the way that Calibre mangles the structure of the CSS. Nevertheless it might be worth trying to create a patch anyway, since most publishers don't use Calibre.

Edit: Actually, thinking about this a bit more, perhaps adding the following to the ePub stylesheet (either by patching the device's stylesheet or by adding it automatically when sideloading via Calibre's kobo_extra.css mechanism) would work, at least for the vast majority of the books I have seen:

body, body.calibre {
  margin-left:0!important;
  margin-right:0!important;
  padding-left:0!important;
  padding-right:0!important;
}

The main problem with creating a patch for the device's styesheet is making enough room to squeeze it in to the existing stylesheet.

[GeoffR]

An alternative to patching for coping with the refresh problems that affect firmware 3.18.0 would be to change my behaviour and get used to:

1. closing the book before putting the device to sleep, and reopening it after waking
2. closing and re-opening the book after each use of the dictionary, advanced font menu, table of contents, reading settings menu.

The second part is not actually all that onerous for me, because I don't use those features very often, the table of contents I use one or twice per book and the others only one or twice a month. The first part I think I could get used to in time.

The other alternative would be to dowgrade to firmware 3.17.3. Although it had the menu/popup ghosting and sleep screen progress bugs, I didn't find those anywhere near as irritating as the refresh bug in 3.18.0.

[JSWolf]

Does the refresh bug show up if FullScreenReading is never turned on? As I've never used that, it's never been on.

[GeoffR]

Originally Posted by JSWolf

Does the refresh bug show up if FullScreenReading is never turned on? As I've never used that, it's never been on.

The bug is triggered by performing one of these actions from within a book (from outside the book doesn't trigger it):

1. putting the device to sleep and waking it again.
2. using the dictionary
3. accessing the reading settings menu
4. accessing the table of contents
5. accessing the advanced font menu
6. maybe other things...

The bug can be un-triggered by closing the book (return to library or homescreen.)

Once triggered There are two parts to the bug on devices other than the Aura:

1. Full refresh every page regardless of refresh rate settings. It is a much heavier refresh than the normal page turn refresh.
2. An extra refresh when tapping the centre of the page to open the reading menus.

The first part only happens in full-screen mode (FullScreenReading=true and "Show header and footer" unticked.)

The second part happens in normal reading mode too, even if the FullScreenReading feature setting is not in the config file.

(Edit: On the Aura the trigger conditions seem to be the sme, but instead of a refresh every page, there is no refresh at all. I don't know what happens on the Aura when bring up the reading menus.)

To see if it happens on your device (other than the Aura), just do this:

1. Open a book
2. Put the device to sleep (or one of the other trigger actions) and wake it up.
3. tap the screen to bring up the reading menus (header and footer icons)

If there was a refresh when you brought up the reading menus, then the bug has been triggered.

Edit: If you don't use full-screen mode and don't care about the extra refresh when opening the menus then the bug is no big deal, you might not even notice it. But if you are used to setting a very high page count between automatic refreshes and tapping the screen twice to refresh manually when needed, then the double-refresh that results is a bit annoying even in normal reading mode. In FullScreenMode the fact that the refresh after triggering the bug is an extra heavy-duty one means you will probbaly notice it even if you have set the device to refresh every page anyway.

[Nick_1964]

From my point of view, I switched to kepubs because they load faster on my device at that current moment and with that current firmware,and maybe optical illusion, i found the txt a lot sharper with kepub compared to epub (Don't know if anyone can confirm that).. there are about 40 books on the main reader,all kepub.
With Kepub I experience that the txt at the bottom is closer to the page xxx of xxx txt then with epub, with epub the footer waisted space is bigger.
But on kepub,there is a big gap at the header that seems impossible to remove so maybe the total amount of txt is the same..
So I try to figure out what is better, upgrade and switch to epub again (meaning that I have to remove all kepubs, switch of the features in the calibre driver to make it..) or keep using kepubs with no possibility to use the full screen anymore...

To bad that we don't know any of Kobo's intentions, will they fix a bug that isn't featured at all ? It must be terrible frustrating to make a patch,that is obsolete in a next firmware version..
It seems my old Sony 650 without any upgrade at all,performs better (Not it's resolution,hell no) and there is no waist of space at all..
I don't use the statistics that belong to kepub..
I think I send a couple of books that are now present als kepub also as epub and try to compare.

Is this valid as extra css, and does it adds the extra css when the kobo extended epub feature is disabled ?
body, body.calibre {
margin-left:0!important;
margin-right:0!important;
padding-left:0!important;
padding-right:0!important;
line-height: 1.2 !important;
text-indent: 0 !important;
widows:1;
orphans:1;
}

[Nick_1964]

Difference between epub and kepub with this above called extra in the css.
With kepub there is still a marge on the left and right, but the txt is sharper.. don't know why there is still a left and right margin.. also notice difference in page numbers..



Epub





Kepub

[GeoffR]

Originally Posted by Nick_1964

Is this valid as extra css, and does it adds the extra css when the kobo extended epub feature is disabled ?
body, body.calibre {
margin-left:0!important;
margin-right:0!important;
padding-left:0!important;
padding-right:0!important;
line-height: 1.2 !important;
text-indent: 0 !important;
widows:1;
orphans:1;
}

Putting the line-height and text-indent there is a bad idea, they won't do anything useful and in some books will cause problems. What I was suggesting was only intended as a way to zero the body left/right margin and padding in ePubs, nothing else.

The footer is exactly the same in KePubs and ePubs, any difference you see could be due to a @page bottom margin in ePubs (@page margins don't work in KePubs.) or other things, but if you have everything else the same then you can get the text as close to the footer in an ePub as in a KePub.

[GeoffR]

I've updated the `Only show multi-touch options on multi-touch devices` in post #14, it now corrects the help pages on the Glo which currently show the brightness adjustment instructions for the Aura.

There are a number of places in the code where the firmware is mistaking the Glo for the Aura. (the above patch corrects three of them.)

This makes me think the FullScreenReading bug could he caused by a similar problem. I don't know exactly how the Aura's screen refresh works, but if it is doing a Reagl refresh every page and a normal refresh once per chapter, then it could be mistakenly doing the Aura refreshes on other devices when the bug is triggered, except that the other devices don't support the Reagl refresh and so it shows as a sort-of deformed full refresh.

[NiLuJe]

I'm kind of attached to FullScreenReading mode working, so I haven't updated my H2O, but if someone wants to take a look, feel free to take a peek at what nickel is doing w/ eink refreshes:

strace -fitv -e trace=ioctl -p $(pidof nickel)

(You'll find a strace build handling the mxcfb ioctls in there).

[JSWolf]

Any chance of adding in the patch to allow font-family: monospace to work?

[GeoffR]

Originally Posted by JSWolf

Any chance of adding in the patch to allow font-family: monospace to work?

It is already included, and enabled by default. (Edit: in librmsdk.so.1.0.0.patch)

Edit2: You'll have to have a font installed with a name starting with Courier to see any effect though.

[JSWolf]

Originally Posted by GeoffR

It is already included, and enabled by default. (Edit: in librmsdk.so.1.0.0.patch)

Edit2: You'll have to have a font installed with a name starting with Courier to see any effect though.

Thank you. I didn't look there for it. My fault.