Earlier start time for Comfortlight

[jackiew1]

@geek1011 For your consideration once you feel like looking at patches again.

There was a request in the MR 'Kobo future firmware feature request thread' MR:post-3913806 regarding having the ability to set Comfortlight start time earlier than 21:00.

Naturally I'm bringing it to your attention because it's one I'd be interested in myself.😁 It can be dark by 15:00 in the UK in winter. Absolutely no urgency.

[pgaskin]

I'll take a look at it later today, and do the patch if it is straightforward (i.e. under 10 minutes to do). I'd also be interested in this myself once I get a Clara (I'm waiting for it to go on sale).

[pgaskin]

@jackiew1, do the hours 7, 18, and 5 mean anything to you (possibly shifted, so also consider the intervals in between)? If so, this will be a really simple patch, if not, I'll have to look further later.

00a499de 3046                   mov        r0, r6 ; CODE XREF=_ZN14BedtimeManager17adjustTemperatureEv+72
00a499e0 7AF6E8E2               blx        _ZN14BedtimeManager18daytimeTemperatureEv@PLT ; BedtimeManager::daytimeTemperature()
00a499e4 3861                   str        r0, [r7, #0x10]
00a499e6 3046                   mov        r0, r6
00a499e8 64F68CE0               blx        _ZN14BedtimeManager18bedtimeTemperatureEv@PLT ; BedtimeManager::bedtimeTemperature()
00a499ec 4346                   mov        r3, r8
00a499ee 7860                   str        r0, [r7, #0x4]
00a499f0 4246                   mov        r2, r8
00a499f2 0721                   movs       r1, #7
00a499f4 2046                   mov        r0, r4
00a499f6 CDF80080               str.w      r8, [sp, #0x70 + var_70]
00a499fa 61F68AE3               blx        _ZN5QTimeC1Eiiii@PLT ; QTime::QTime(int, int, int, int)
00a499fe D7F82C90               ldr.w      sb, [r7, #0x2c]
00a49a02 4346                   mov        r3, r8
00a49a04 4246                   mov        r2, r8
00a49a06 1221                   movs       r1, #18
00a49a08 CDF80080               str.w      r8, [sp, #0x70 + var_70]
00a49a0c 2046                   mov        r0, r4
00a49a0e B9F1FF3F               cmp.w      sb, #0xffffffff
00a49a12 08BF                   it         eq
00a49a14 4FF00009               mov.weq    sb, #0x0
00a49a18 61F67AE3               blx        _ZN5QTimeC1Eiiii@PLT ; QTime::QTime(int, int, int, int)
00a49a1c D7F82CB0               ldr.w      fp, [r7, #0x2c]
00a49a20 4346                   mov        r3, r8
00a49a22 CDF80080               str.w      r8, [sp, #0x70 + var_70]
00a49a26 4246                   mov        r2, r8
00a49a28 0521                   movs       r1, #5
00a49a2a 2046                   mov        r0, r4
00a49a2c BBF1FF3F               cmp.w      fp, #0xffffffff
00a49a30 08BF                   it         eq
00a49a32 4FF0000B               mov.weq    fp, #0x0
00a49a36 61F66CE3               blx        _ZN5QTimeC1Eiiii@PLT ; QTime::QTime(int, int, int, int)
00a49a3a FB6A                   ldr        r3, [r7, #0x2c]
00a49a3c 7B61                   str        r3, [r7, #0x14]
00a49a3e 0133                   adds       r3, #0x1
00a49a40 00F05881               beq.w      loc_a49cf4

[jackiew1]

That's a bit cryptic for me 😄 Here's the only actual info I can see, none of which answers your question.

The config setting for "Bedtime" is a drop-down menu with 13 entries:
21:00 to 03:00 inclusive, at 30min intervals. That's a range of 6 hours.

I have my Clara and Forma set at the minimum of 21:00 which is stored in the Kobo .conf file's [PowerOptions] section with a value BedTime=@Variant(\0\0\0\xf\x4\x81\x90\x80).

[pgaskin]

OK, thanks, that helps.

BTW, I'm going to release v54 in the next few minutes. All the missing patches are now updated.

[jackiew1]

... I typed that @variant with a capital 'V' but it's displaying as small 'v'

[pgaskin]

That's because GitHub's interpreting that as a mention to the user variant.

[jackiew1]

Well then, lets hope user variant can answer your question if he reads it 😄

[jackiew1]

A bit more info I missed ...
There is also another .conf setting in [PowerOptions] for the colour temperature slider value.
ColorSetting=6400 (for full blue)
ColorSetting=1500 (for full orange)

[pgaskin]

I found the relevant code multiple layers into functions which had their names optimized out by going back from references to QTime::addSecs (since the values aren't hard-coded, I guessed they would be generated this way). I just have to figure out where to patch it.

00a50e28 2DE9F04F               push.w     {r4, r5, r6, r7, r8, sb, sl, fp, lr} ; CODE XREF=sub_a51c98+1216
00a50e2c A3B0                   sub        sp, #0x8c
00a50e2e 06AF                   add        r7, sp, #0x18
00a50e30 0024                   movs       r4, #0x0
00a50e32 07F11006               add.w      r6, r7, #0x10
00a50e36 2346                   mov        r3, r4
00a50e38 2246                   mov        r2, r4
00a50e3a 0094                   str        r4, [sp, #0xb0 + var_B0]
00a50e3c 8246                   mov        sl, r0
00a50e3e 1521                   movs       r1, #0x15
00a50e40 3046                   mov        r0, r6
00a50e42 5AF666E1               blx        _ZN5QTimeC1Eiiii@PLT                 ; QTime::QTime(int, int, int, int)
00a50e46 C34B                   ldr        r3, =0x6526bc                        ; 0x6526bc,0xa51154
00a50e48 7B44                   add        r3, pc                               ; dword_10a3508
00a50e4a 1A46                   mov        r2, r3
00a50e4c 7B60                   str        r3, [r7, #0x4]
00a50e4e C24B                   ldr        r3, =dword_14ef8                     ; dword_14ef8,0xa51158
00a50e50 D258                   ldr        r2, [r2, r3]                         ; dword_10b8400
00a50e52 9368                   ldr        r3, [r2, #0x8]
00a50e54 7A61                   str        r2, [r7, #0x14]
00a50e56 C3F31E03               ubfx       r3, r3, #0x0, #0x1f
00a50e5a 0C2B                   cmp        r3, #0xc
00a50e5c C2BF                   ittt       gt
00a50e5e 07F11403               add.wgt    r3, r7, #0x14
00a50e62 1446                   movgt      r4, r2
00a50e64 BB60                   strgt      r3, [r7, #0x8]
00a50e66 40F33581               ble.w      loc_a510d4
00a50e6a 2368                   ldr        r3, [r4]

00a50e6c 012B                   cmp        r3, #0x1

00a50e6e 40F23F81               bls.w      loc_a510f0
                        loc_a50e72:

00a50e72 07F15803               add.w      r3, r7, #0x58                        ; CODE XREF=sub_a50e28+708, sub_a50e28+726, sub_a50e28+740

00a50e76 0D25                   movs       r5, #0xd

00a50e78 07F11804               add.w      r4, r7, #0x18

00a50e7c 07F11C08               add.w      r8, r7, #0x1c

00a50e80 FB60                   str        r3, [r7, #0xc]

00a50e82 16E0                   b          loc_a50eb2
                        loc_a50e84:

00a50e84 0422                   movs       r2, #0x4                             ; CODE XREF=sub_a50e28+204, sub_a50e28+234

00a50e86 0221                   movs       r1, #0x2

00a50e88 53F620E7               blx        _ZN10QArrayData10deallocateEPS_jj@PLT ; QArrayData::deallocate(QArrayData*, unsigned int, unsigned int)
                        loc_a50e8c:

00a50e8c F869                   ldr        r0, [r7, #0x1c]                      ; CODE XREF=sub_a50e28+208, sub_a50e28+230

00a50e8e 0368                   ldr        r3, [r0]

00a50e90 002B                   cmp        r3, #0x0

00a50e92 3FD1                   bne        loc_a50f14
                        loc_a50e94:

00a50e94 0422                   movs       r2, #0x4                             ; CODE XREF=sub_a50e28+264

00a50e96 0221                   movs       r1, #0x2

00a50e98 53F618E7               blx        _ZN10QArrayData10deallocateEPS_jj@PLT ; QArrayData::deallocate(QArrayData*, unsigned int, unsigned int)
                        loc_a50e9c:

00a50e9c 2046                   mov        r0, r4                               ; CODE XREF=sub_a50e28+238, sub_a50e28+260

00a50e9e 4DF6C4E4               blx        _ZN7QLocaleD1Ev@PLT                  ; QLocale::~QLocale()

00a50ea2 4FF4E161               mov.w      r1, #1800

00a50ea6 3046                   mov        r0, r6

00a50ea8 46F68EE3               blx        _ZNK5QTime7addSecsEi@PLT             ; QTime::addSecs(int) const

00a50eac 013D                   subs       r5, #0x1

00a50eae 3861                   str        r0, [r7, #0x10]

00a50eb0 3FD0                   beq        loc_a50f32
                        loc_a50eb2:

00a50eb2 2046                   mov        r0, r4                               ; CODE XREF=sub_a50e28+90

00a50eb4 78F6F4E5               blx        _ZN7QLocaleC1Ev@PLT                  ; QLocale::QLocale()

00a50eb8 0123                   movs       r3, #0x1

00a50eba 3246                   mov        r2, r6

00a50ebc 2146                   mov        r1, r4

00a50ebe 4046                   mov        r0, r8

00a50ec0 5FF60CE4               blx        _ZNK7QLocale8toStringERK5QTimeNS_10FormatTypeE@PLT ; QLocale::toString(QTime const&, QLocale::FormatType) const

00a50ec4 FB69                   ldr        r3, [r7, #0x1c]

00a50ec6 1A68                   ldr        r2, [r3]

00a50ec8 BB65                   str        r3, [r7, #0x58]

00a50eca 0132                   adds       r2, #0x1

00a50ecc 012A                   cmp        r2, #0x1

00a50ece 08D9                   bls        loc_a50ee2
                        loc_a50ed0:

00a50ed0 53E8002F               ldrex      r2, [r3]                             ; CODE XREF=sub_a50e28+184

00a50ed4 02F10102               add.w      r2, r2, #0x1

00a50ed8 43E80021               strex      r1, r2, [r3]

00a50edc 91F0000F               teq.w      r1, #0x0

00a50ee0 F6D1                   bne        loc_a50ed0
                        loc_a50ee2:

00a50ee2 07F10800               add.w      r0, r7, #0x8                         ; CODE XREF=sub_a50e28+166

00a50ee6 0BC8                   ldm        r0, {r0, r1, r3}

00a50ee8 FB65                   str        r3, [r7, #0x5c]

00a50eea 48F654E5               blx        ZN7QVectorI5QPairI7QString5QTimeEE6appendERKS3@PLT ; QVector<QPair<QString, QTime> >::append(QPair<QString, QTime> const&)

00a50eee B86D                   ldr        r0, [r7, #0x58]

00a50ef0 0368                   ldr        r3, [r0]

00a50ef2 002B                   cmp        r3, #0x0

00a50ef4 C6D0                   beq        loc_a50e84
00a50ef6 0133                   adds       r3, #0x1

00a50ef8 C8D0                   beq        loc_a50e8c
                        loc_a50efa:

00a50efa 50E8003F               ldrex      r3, [r0]                             ; CODE XREF=sub_a50e28+226

00a50efe A3F10103               sub.w      r3, r3, #0x1

00a50f02 40E80032               strex      r2, r3, [r0]

00a50f06 92F0000F               teq.w      r2, #0x0

00a50f0a F6D1                   bne        loc_a50efa
00a50f0c 002B                   cmp        r3, #0x0

00a50f0e BDD1                   bne        loc_a50e8c
00a50f10 B86D                   ldr        r0, [r7, #0x58]

00a50f12 B7E7                   b          loc_a50e84
                        loc_a50f14:

00a50f14 0133                   adds       r3, #0x1                             ; CODE XREF=sub_a50e28+106

00a50f16 C1D0                   beq        loc_a50e9c
                        loc_a50f18:

00a50f18 50E8003F               ldrex      r3, [r0]                             ; CODE XREF=sub_a50e28+256

00a50f1c A3F10103               sub.w      r3, r3, #0x1

00a50f20 40E80032               strex      r2, r3, [r0]

00a50f24 92F0000F               teq.w      r2, #0x0

00a50f28 F6D1                   bne        loc_a50f18
00a50f2a 002B                   cmp        r3, #0x0

00a50f2c B6D1                   bne        loc_a50e9c
00a50f2e F869                   ldr        r0, [r7, #0x1c]

00a50f30 B0E7                   b          loc_a50e94
                        loc_a50f32:

00a50f32 7B69                   ldr        r3, [r7, #0x14]                      ; CODE XREF=sub_a50e28+136

00a50f34 5A68                   ldr        r2, [r3, #0x4]

00a50f36 002A                   cmp        r2, #0x0

00a50f38 C2BF                   ittt       gt

00a50f3a 07F13806               add.wgt    r6, r7, #0x38

00a50f3e AB46                   movgt      fp, r5

00a50f40 07F12008               add.wgt    r8, r7, #0x20

00a50f44 21DD                   ble        loc_a50f8a
                        loc_a50f46:

00a50f46 DC68                   ldr        r4, [r3, #0xc]                       ; CODE XREF=sub_a50e28+352

00a50f48 3046                   mov        r0, r6

00a50f4a DAF88C20               ldr.w      r2, [sl, #0x8c]

00a50f4e 04EBC504               add.w      r4, r4, r5, lsl #3

00a50f52 D2F86090               ldr.w      sb, [r2, #0x60]

00a50f56 1C44                   add        r4, r3

00a50f58 211D                   adds       r1, r4, #0x4

00a50f5a 42F692E5               blx        _ZN8QVariantC1ERK5QTime@PLT          ; QVariant::QVariant(QTime const&)

00a50f5e 4046                   mov        r0, r8

00a50f60 78F69EE5               blx        _ZN7QLocaleC1Ev@PLT                  ; QLocale::QLocale()

00a50f64 CDF800B0               str.w      fp, [sp, #0xb0 + var_B0]

00a50f68 2146                   mov        r1, r4

00a50f6a 4846                   mov        r0, sb

00a50f6c 4346                   mov        r3, r8

00a50f6e 3246                   mov        r2, r6

00a50f70 68F604E2               blx        _ZN13TouchDropDown7addItemERK7QStringRK8QVariantRK7QLocaleb@PLT ; TouchDropDown::addItem(QString const&, QVariant const&, QLocale const&, bool)

00a50f74 4046                   mov        r0, r8

00a50f76 0135                   adds       r5, #0x1

00a50f78 4DF656E4               blx        _ZN7QLocaleD1Ev@PLT                  ; QLocale::~QLocale()

00a50f7c 3046                   mov        r0, r6

00a50f7e 4DF664E7               blx        _ZN8QVariantD1Ev@PLT                 ; QVariant::~QVariant()

00a50f82 7B69                   ldr        r3, [r7, #0x14]

00a50f84 5A68                   ldr        r2, [r3, #0x4]

00a50f86 9542                   cmp        r5, r2

00a50f88 DDDB                   blt        loc_a50f46
                        loc_a50f8a:

00a50f8a DAF88C30               ldr.w      r3, [sl, #0x8c]                      ; CODE XREF=sub_a50e28+284

00a50f8e 1E6E                   ldr        r6, [r3, #0x60]

00a50f90 6DF696E0               blx        _ZN6Device16getCurrentDeviceEv@PLT   ; Device::getCurrentDevice()

00a50f94 0146                   mov        r1, r0

00a50f96 F868                   ldr        r0, [r7, #0xc]

00a50f98 65F684E6               blx        _ZN8SettingsC2ERK6Device@PLT         ; Settings::Settings(Device const&)

00a50f9c 6F4B                   ldr        r3, =0x15320                         ; 0x15320,0xa5115c

00a50f9e 7A68                   ldr        r2, [r7, #0x4]

00a50fa0 D7F80C80               ldr.w      r8, [r7, #0xc]

00a50fa4 D458                   ldr        r4, [r2, r3]

00a50fa6 4046                   mov        r0, r8

00a50fa8 04F10803               add.w      r3, r4, #0x8

00a50fac BB65                   str        r3, [r7, #0x58]

00a50fae 72F61CE7               blx        _ZN13PowerSettings7bedTimeEv@PLT     ; PowerSettings::bedTime()

00a50fb2 07F17001               add.w      r1, r7, #0x70

00a50fb6 07F14805               add.w      r5, r7, #0x48

00a50fba 41F8380D               str        r0, [r1, #-0x38]!

00a50fbe 2846                   mov        r0, r5

00a50fc0 42F65EE5               blx        _ZN8QVariantC1ERK5QTime@PLT          ; QVariant::QVariant(QTime const&)

00a50fc4 2946                   mov        r1, r5

00a50fc6 3046                   mov        r0, r6

00a50fc8 6EF6E4E4               blx        _ZN13TouchDropDown23setCurrentIndexFromDataERK8QVariant@PLT ; TouchDropDown::setCurrentIndexFromData(QVariant const&)

00a50fcc 2846                   mov        r0, r5

00a50fce 0834                   adds       r4, #0x8

00a50fd0 4DF63AE7               blx        _ZN8QVariantD1Ev@PLT                 ; QVariant::~QVariant()

00a50fd4 4046                   mov        r0, r8

00a50fd6 BC65                   str        r4, [r7, #0x58]

00a50fd8 6AF6EEE7               blx        _ZN8SettingsD2Ev@PLT                 ; Settings::~Settings()

00a50fdc DAF88C30               ldr.w      r3, [sl, #0x8c]

00a50fe0 186E                   ldr        r0, [r3, #0x60]

00a50fe2 70F606E6               blx        _ZN13TouchDropDown20centerMenuVerticallyEv@PLT ; TouchDropDown::centerMenuVertically(), DATA XREF=ZN10ContentKey16removeByVolumeIdERK7QStringS2+160, dword_68e39c

00a50fe6 DAF88C30               ldr.w      r3, [sl, #0x8c]

00a50fea 0121                   movs       r1, #0x1

00a50fec 186E                   ldr        r0, [r3, #0x60]

00a50fee 57F6EEE6               blx        _ZN13TouchDropDown19setCheckmarkEnabledEb@PLT ; TouchDropDown::setCheckmarkEnabled(bool)

00a50ff2 7D68                   ldr        r5, [r7, #0x4]

00a50ff4 0024                   movs       r4, #0x0

00a50ff6 5A4A                   ldr        r2, =0x19368                         ; 0x19368,0xa51160

00a50ff8 1020                   movs       r0, #0x10

00a50ffa 5A4B                   ldr        r3, =0xfffffd4f                      ; 0xa51164

00a50ffc DAF88C10               ldr.w      r1, [sl, #0x8c]

00a51000 AA58                   ldr        r2, [r5, r2]

00a51002 7B44                   add        r3, pc                               ; 0xa50d55

00a51004 FC62                   str        r4, [r7, #0x2c]

00a51006 0D6E                   ldr        r5, [r1, #0x60]

00a51008 3B63                   str        r3, [r7, #0x30]                      ; DATA XREF=ZN10ContentKey16removeByVolumeIdERK7QStringS2+118, dword_68e398

00a5100a BA62                   str        r2, [r7, #0x28]

00a5100c 7C63                   str        r4, [r7, #0x34]

00a5100e 4EF66EE0               blx        _Znwj@PLT                            ; operator new(unsigned int)

00a51012 3C6B                   ldr        r4, [r7, #0x30]

00a51014 0122                   movs       r2, #0x1

00a51016 544E                   ldr        r6, =0x1a6b                          ; 0x1a6b,0xa51168

00a51018 2946                   mov        r1, r5

00a5101a 7D6B                   ldr        r5, [r7, #0x34]

00a5101c 5346                   mov        r3, sl

00a5101e 8460                   str        r4, [r0, #0x8]

00a51020 524C                   ldr        r4, =0x12e80                         ; 0x12e80,0xa5116c

00a51022 7E44                   add        r6, pc                               ; 0xa52a91

00a51024 0260                   str        r2, [r0]

00a51026 C560                   str        r5, [r0, #0xc]

00a51028 07F12405               add.w      r5, r7, #0x24

00a5102c 2246                   mov        r2, r4

00a5102e 7C68                   ldr        r4, [r7, #0x4]

00a51030 4660                   str        r6, [r0, #0x4]

00a51032 0026                   movs       r6, #0x0

00a51034 A258                   ldr        r2, [r4, r2]

00a51036 07F13004               add.w      r4, r7, #0x30

00a5103a 0190                   str        r0, [sp, #0xb0 + var_AC]

00a5103c 2846                   mov        r0, r5

00a5103e 0396                   str        r6, [sp, #0xb0 + var_A4]

00a51040 0492                   str        r2, [sp, #0xb0 + var_A0]

00a51042 07F12802               add.w      r2, r7, #0x28

00a51046 0296                   str        r6, [sp, #0xb0 + var_A8]

00a51048 0094                   str        r4, [sp, #0xb0 + var_B0]

00a5104a 64F6ECE2               blx        _ZN7QObject11connectImplEPKS_PPvS1_S3_PN9QtPrivate15QSlotObjectBaseEN2Qt14ConnectionTypeEPKiPK11QMetaObject@PLT ; QObject::connectImpl(QObject const*, void**, QObject const*, void**, QtPrivate::QSlotObjectBase*, Qt::ConnectionType, int const*, QMetaObject const*)

00a5104e 2846                   mov        r0, r5

00a51050 62F674E6               blx        _ZN11QMetaObject10ConnectionD1Ev@PLT ; QMetaObject::Connection::~Connection()

00a51054 7E69                   ldr        r6, [r7, #0x14]

00a51056 3368                   ldr        r3, [r6]

00a51058 6BBB                   cbnz       r3, loc_a510b6
                        loc_a5105a:

00a5105a F368                   ldr        r3, [r6, #0xc]                       ; CODE XREF=sub_a50e28+682

00a5105c 7568                   ldr        r5, [r6, #0x4]

00a5105e F418                   adds       r4, r6, r3

00a51060 03EBC503               add.w      r3, r3, r5, lsl #3

00a51064 F518                   adds       r5, r6, r3

00a51066 AC42                   cmp        r4, r5

00a51068 1CD1                   bne        loc_a510a4
                        loc_a5106a:

00a5106a 3046                   mov        r0, r6                               ; CODE XREF=sub_a50e28+634

00a5106c 0422                   movs       r2, #0x4

00a5106e 0821                   movs       r1, #0x8

00a51070 53F62CE6               blx        _ZN10QArrayData10deallocateEPS_jj@PLT ; QArrayData::deallocate(QArrayData*, unsigned int, unsigned int)
                        loc_a51074:

00a51074 7437                   adds       r7, #0x74                            ; CODE XREF=sub_a50e28+656, sub_a50e28+678

00a51076 BD46                   mov        sp, r7

00a51078 BDE8F08F               pop.w      {r4, r5, r6, r7, r8, sb, sl, fp, pc}

; endp
                        loc_a5107c:

00a5107c 0133                   adds       r3, #0x1                             ; CODE XREF=sub_a50e28+652

00a5107e 0FD0                   beq        loc_a510a0
                        loc_a51080:

00a51080 50E8003F               ldrex      r3, [r0]                             ; CODE XREF=sub_a50e28+616

00a51084 A3F10103               sub.w      r3, r3, #0x1

00a51088 40E80032               strex      r2, r3, [r0]

00a5108c 92F0000F               teq.w      r2, #0x0

00a51090 F6D1                   bne        loc_a51080
00a51092 2BB9                   cbnz       r3, loc_a510a0
00a51094 54F8080C               ldr        r0, [r4, #-0x8]
                        loc_a51098:

00a51098 0422                   movs       r2, #0x4                             ; CODE XREF=sub_a50e28+650

00a5109a 0221                   movs       r1, #0x2

00a5109c 53F616E6               blx        _ZN10QArrayData10deallocateEPS_jj@PLT ; QArrayData::deallocate(QArrayData*, unsigned int, unsigned int)
                        loc_a510a0:

00a510a0 A542                   cmp        r5, r4                               ; CODE XREF=sub_a50e28+598, sub_a50e28+618

00a510a2 E2D0                   beq        loc_a5106a
                        loc_a510a4:

00a510a4 0834                   adds       r4, #0x8                             ; CODE XREF=sub_a50e28+576

00a510a6 54F8080C               ldr        r0, [r4, #-0x8]

00a510aa 94F830F0               pld        [r4, #0x30]

00a510ae 0368                   ldr        r3, [r0]

00a510b0 002B                   cmp        r3, #0x0

00a510b2 F1D0                   beq        loc_a51098
00a510b4 E2E7                   b          loc_a5107c
                        loc_a510b6:

00a510b6 0133                   adds       r3, #0x1                             ; CODE XREF=sub_a50e28+560

00a510b8 DCD0                   beq        loc_a51074
                        loc_a510ba:

00a510ba 56E8003F               ldrex      r3, [r6]                             ; CODE XREF=sub_a50e28+674

00a510be A3F10103               sub.w      r3, r3, #0x1

00a510c2 46E80032               strex      r2, r3, [r6]

00a510c6 92F0000F               teq.w      r2, #0x0

00a510ca F6D1                   bne        loc_a510ba
00a510cc 002B                   cmp        r3, #0x0

00a510ce D1D1                   bne        loc_a51074
00a510d0 7E69                   ldr        r6, [r7, #0x14]

00a510d2 C2E7                   b          loc_a5105a
                        loc_a510d4:

00a510d4 07F11403               add.w      r3, r7, #0x14                        ; CODE XREF=sub_a50e28+62

00a510d8 5168                   ldr        r1, [r2, #0x4]

00a510da 1846                   mov        r0, r3

00a510dc BB60                   str        r3, [r7, #0x8]

00a510de 0D22                   movs       r2, #0xd

00a510e0 2346                   mov        r3, r4

00a510e2 66F6C6E6               blx        _ZN7QVectorI5QPairI7QString5QTimeEE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@PLT ; QVector<QPair<QString, QTime> >::reallocData(int, int, QFlagsQArrayData::AllocationOption)

00a510e6 7C69                   ldr        r4, [r7, #0x14]

00a510e8 2368                   ldr        r3, [r4]

00a510ea 012B                   cmp        r3, #0x1

00a510ec 3FF6C1AE               bhi.w      loc_a50e72
                        loc_a510f0:

00a510f0 0223                   movs       r3, #0x2                             ; CODE XREF=sub_a50e28+70

00a510f2 0022                   movs       r2, #0x0

00a510f4 0421                   movs       r1, #0x4

00a510f6 0820                   movs       r0, #0x8

00a510f8 70F6C2E5               blx        _ZN10QArrayData8allocateEjjj6QFlagsINS_16AllocationOptionEE@PLT ; QArrayData::allocate(unsigned int, unsigned int, unsigned int, QFlagsQArrayData::AllocationOption)

00a510fc 8442                   cmp        r4, r0

00a510fe 3FF4B8AE               beq.w      loc_a50e72
00a51102 7A69                   ldr        r2, [r7, #0x14]

00a51104 D37A                   ldrb       r3, [r2, #0xb]

00a51106 43F08003               orr        r3, r3, #0x80

00a5110a D372                   strb       r3, [r2, #0xb]

00a5110c B1E6                   b          loc_a50e72

[pgaskin]

@jackiew1, can you tell me the earliest and latest time in the list?

Edit: nevermind, found it at https://youtu.be/XIaN5TlbJJQ?t=120 - [9PM ... 3AM] step 30m (12 steps total). This confirms what I found in the firmware (init: 0xa50e76 => i=13, while: 0xa50f38 => i--;i>0, start: 0xa50e3e => 21h, increment: 0xa50ea2 => 1800).

[pgaskin]

@jackiew1, can you try this:

Change ComfortLight bedtime range:
  - Enabled: yes
  - Description: Change the times available in the ComfortLight bedtime dropdown.
    # In an unnamed subroutine two layers into FrontLightPopupController::loadView
    # (find it by going back from QTime::addSecs), the times for the dropdown are
    # generated into a QVector<QPair<QString, QTime>> with a simple loop.
    #
    # The abbreviated structure of the loop:
    #
    #    r0 = new QTime(r1 = 21, 0, 0)
    #    QVector<QPair<QString, QTime>>::reallocData(int, r2 = 13, QFlags<QArrayData::AllocationOption>)   ; https://code.woboq.org/qt5/qtbase/src/corelib/tools/qvector.h.html#_ZN7QVector11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE
    #    r5 = 13
    #    do {
    #      QLocale::toString(QTime const&, QLocale::FormatType)
    #      QVector<QPair<QString, QTime>>::append(QPair<QString, QTime> const&)
    #      QTime::addSecs(r1 = 1800)
    #      r5--
    #    } while (r5 > 0)
    #
  # Change the starting hour passed to the QTime constructor (mov r1, #21):
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 17}                       # 21:00 (9PM) -> 17:00 (5PM)
  # Optional: Change the second increment passed to QTime::addSecs:
  - ReplaceBytes: {Offset: 0xA50EA2, FindH: 4F F4 E1 61, ReplaceH: 4F F4 E1 61} # mov.w r1, #1800: 30m
  # Change the number of increments (movs r5, #13):
  - ReplaceInt: {Offset: 0xA50E76, Find: 13, Replace: 21}                       # 13 [9PM..3AM]+30m -> 21 [5PM..3AM]+30m
  # Change the number of elements pre-allocated (I don't think this is actually
  # required, as Qt will realloc as necessary, but we might as well do this just
  # in case):
  - ReplaceInt: {Offset: 0xA510DE, Find: 13, Replace: 21}                       # same as prev replacement

I've tested this with the following patch to confirm the dropdown items and config entries work properly:

Show natural light menu on all devices:
  - Enabled: yes
  - Description: |
      Just for testing the previous patch, will show the slider and dropdown,
      but won't actually do anything other than change the config file.
  # Show slider in FrontLightPopupController::loadView:
  - ReplaceBytes: {Offset: 0xA51E8A, FindBLX: 0x4C8984, ReplaceH: 4F F0 01 00}
  - ReplaceBytes: {Offset: 0xA51FC8, FindBLX: 0x4C8984, ReplaceH: 4F F0 01 00}

Everything seems to work. The only thing I can't test is the schedule itself, as I don't currently have a device with natural light.

[jackiew1]

Testing now. Sorry for delay, it's been a busy morning.

[jackiew1]

I installed the patch as-is on a KA1. It gave me the expected range of Bedtimes 17:00-03:00, 21 entries at 30min intervals. It's only 14:50 here so I need to customise the patch to force an earlier colour-changing.

I re-applied the patch with a customised minimum Bedtime of 15:00 and commented out all other find/replace. After installation, as expected, the drop-down has 13 entries at 30min intervals 15:00-21:00. I've selected 15:00 from the drop-down and made sure the Natural light Auto switch is on.

I would expect the colour to start changing immediately so it would gradually get to "full orange" by 15:00 . So far it's remained on "full blue". 😕

When you were digging around did you notice the algorithm for how the colour-change is meant to happen?

[pgaskin]

I did take note of where the color change was handled (BedTimeManager::adjustTemperature), but I didn't bother to try to understand it. I was just focusing on the menu and config file yesterday. Does the color change happen if you set the time even further back?

One suspicion I have is that those times I saw earlier also need to be adjusted (my patch doesn't touch anything to do with a wake-up time). Do you know when the auto color change ends (i.e. goes back to normal)?

[jackiew1]

Does the color change happen if you set the time even further back?

I haven't changed the patch on the KA1 but it's 15:12 now and the KA1 is still full blue. So passing the Bedtime value didn't kickstart anything.

One suspicion I have is that those times I saw earlier also need to be adjusted (my patch doesn't touch anything to do with a wake-up time). Do you know when the auto color change ends (i.e. goes back to normal)?

I don't know for sure when orange starts to move back to blue. When I've finished reading for the night (early morning) the device will be full orange. If I open the book next morning it will be full blue, although I have a feeling that the immediate colour will be wherever it was when I closed the cover and re-opening it immediately starts to auto-decrease the orange. It's gradual but fast-gradual.

[jackiew1]

Follow-up on the KA1 ...

• I disabled the auto-Natural light button at 15:30
• manually set the orange slider to max
• re-enabled the auto-Natural light button. The orange slider immediately starts to inch its way back from max to min.

So there's definitely more to it than we have so far.

[jackiew1]

Follow-up 2 ...

I've now installed the patch on my Clara. Bedtime 21 entries 15:00-01:00 set at 16:00. I plan to do some normal reading now and note at what time the orange starts to kick in (if it ever does).

I've left this page open on screen so if you have more ideas I should see them quite quickly.

[jackiew1]

Both KA1 and Clara started to move at 18:00. Both auto-stepped from min to max in under a minute. I have to admit that I've never paid attention to how long it normally takes to move from min to max.

My Forma remains unpatched and has Bedtime set at the default min of 21:00. It's at full blue at the moment, so the patch has obviously made some kind of difference.

I'll now continue reading on the unpatched Forma and pay more attention to when the colour-change kicks in and how fast it moves.

[pgaskin]

Can you enable all light-related logging categories in developer options (search devmodeon, go to device info)?

[jackiew1]

I've turned on dev mode and ticked every box in Logging Category.

[jackiew1]

I've just checked the colour-slider. It's started to move. It's about 1cm from min. I wouldn't have noticed the change if I hadn't gone looking.

[pgaskin]

These are the calculations "before day time start":

00a49d1e 7B69                   ldr        r3, [r7, #0x14] ; CODE XREF=dword_a4a6c4+1492, dword_a4a6c4+1538, dword_a4a6c4+2376, sub_a4b086+112
00a49d20 7A68                   ldr        r2, [r7, #0x4]
00a49d22 3969                   ldr        r1, [r7, #0x10]
00a49d24 ED1A                   subs       r5, r5, r3
00a49d26 C3EB0909               rsb        sb, r3, sb
00a49d2a 07EE902A               vmov       s15, r2
00a49d2e 8B1A                   subs       r3, r1, r2
00a49d30 F8EEE71B               vcvt.f64.s32 d17, s15
00a49d34 07EE905A               vmov       s15, r5
00a49d38 F8EEE70B               vcvt.f64.s32 d16, s15
00a49d3c 07EE909A               vmov       s15, sb
00a49d40 F8EEE73B               vcvt.f64.s32 d19, s15
00a49d44 07EE903A               vmov       s15, r3
00a49d48 F8EEE72B               vcvt.f64.s32 d18, s15
00a49d4c C0EEA30B               vdiv.f64   d16, d16, d19
00a49d50 42EEA01B               vmla.f64   d17, d18, d16
00a49d54 FDEEE17B               vcvt.s32.f64 s15, d17
00a49d58 C7ED047A               vstr       s15, [r7, #0x10]
00a49d5c C9E6                   b          loc_a49af2

These are "after sunset but not bed time yet":

00a4a54e 3A69                   ldr        r2, [r7, #0x10] ; CODE XREF=dword_a4a6c4+1894, dword_a4a6c4+1944, dword_a4a6c4+2406
00a4a550 CBEB0505               rsb        r5, fp, r5
00a4a554 CBEB0808               rsb        r8, fp, r8
00a4a558 7968                   ldr        r1, [r7, #0x4]
00a4a55a 07EE902A               vmov       s15, r2
00a4a55e 531A                   subs       r3, r2, r1
00a4a560 F8EEE72B               vcvt.f64.s32 d18, s15
00a4a564 07EE905A               vmov       s15, r5
00a4a568 F8EEE71B               vcvt.f64.s32 d17, s15
00a4a56c 07EE908A               vmov       s15, r8
00a4a570 F8EEE70B               vcvt.f64.s32 d16, s15
00a4a574 07EE903A               vmov       s15, r3
00a4a578 F8EEE73B               vcvt.f64.s32 d19, s15
00a4a57c C1EEA00B               vdiv.f64   d16, d17, d16
00a4a580 43EEE02B               vmls.f64   d18, d19, d16
00a4a584 FDEEE27B               vcvt.s32.f64 s15, d18
00a4a588 C7ED047A               vstr       s15, [r7, #0x10]
00a4a58c FFF7B1BA               b.w        loc_a49af2

And this calculation is used for something else:

00a49b5e 801A                   subs       r0, r0, r2
00a49b60 9FEDB86A               vldr       s12, =0x458ca000 ; 0xa49e44
00a49b64 0028                   cmp        r0, #0x0
00a49b66 DFEDB87A               vldr       s15, =0x4270 ; 0xa49e4a
00a49b6a B8BF                   it         lt
00a49b6c 4042                   rsbslt     r0, r0, #0x0
00a49b6e DFEDB76A               vldr       s13, =0x9b8e447a ; 0xa49e4e
00a49b72 1146                   mov        r1, r2
00a49b74 0122                   movs       r2, #0x1
00a49b76 07EE100A               vmov       s14, r0
00a49b7a 2846                   mov        r0, r5
00a49b7c B8EEC77A               vcvt.f32.s32 s14, s14
00a49b80 87EE067A               vdiv.f32   s14, s14, s12
00a49b84 67EE277A               vmul.f32   s15, s14, s15
00a49b88 67EEA67A               vmul.f32   s15, s15, s13
00a49b8c FDEEE77A               vcvt.s32.f32 s15, s15
00a49b90 17EE903A               vmov       r3, s15
00a49b94 61F6F8E4               blx        _ZN10FrontLight14setTemperatureEibi@PLT ; FrontLight::setTemperature(int, bool, int)
00a49b98 BAF1000F               cmp.w      sl, #0x0
00a49b9c BED1                   bne        loc_a49b1c

(these are mainly for my own reference, I'll need to work out the math when I get around to it)

[jackiew1]

I hope all that makes more sense to you than it does to me.

I won't be particularly surprised if I see a slider jump every 30mins rather than a constant gradual creep.

[pgaskin]

I hope all that makes more sense to you than it does to me.

It does. It's easier than it seems at first, as quite a few of those instructions are just variants of a few simple ones (blx to call functions, v... for floating point numbers, etc, ...lt for executing only if less-than, {mul,div} for math operations, ldr to load from a memory address, etc). For example, the last part (after the vldr) of the last one basically says FrontLight::setTemperature(r2, true, s14/s12*s15*s13). The main thing I have to figure out is what's currently stored in s14, s12, and s15, for which I need to follow the address in vldr back to their source.

I won't be doing much with this today, though. Once you have the logs, can you post them or PM them to me (specifically the lines about adjustTemperature)?

[jackiew1]

How long do you want me to let it run before connecting to access the logs? Is it one big log or lots of little ones?

[pgaskin]

It saves whenever you connect USB. And it'd be nice to have the logs at the beginning and end of the change (remember to keep track of what bedtime you used).

[pgaskin]

So, it seems the majority of my guesses are correct. Do you think it would be sufficient (with regards to this patch) to also set the sunset time earlier, or should I see if it is possible to make it transition over a fixed period before bedtime (this may be possible if I can find enough room to put it in)?

One last thing you could try is to change the int at 0x00a49a28 from 5 to 0 (and 0x00a499f2 from 7 to 1) and see if it starts getting cooler again (sunrise).

[jackiew1]

I applied the 2 new find/replaces with the device time set correctly. I couldn't immediately conclude anything. So I've advanced the time from 00:00 to 00:30, i.e. 30mins until sunrise ... and yes, the colour has moved down from full (almost) orange to about 50% orange. If your theory is true it should reach zero-orange within another 30 mins. I'll let it do this naturally with no more artificial time changes and post again in 30 mins.

[jackiew1]

... it's now 01:00 on this Kobo and colour is at full blue, i.e zero-orange.

Do you think it would be sufficient to also set the sunset time earlier, or should I see if it is possible to make it transition over a fixed period before bedtime (this may be possible if I can find enough room to put it in)?

Hmmm. Need to think about this a bit. These are initial personal thoughts, not what I think every other user will necessarily want.

I don't really care very much about what the transition duration from blue to orange is. And I care zero about transition duration from orange to blue because I'm never reading at sunrise. And even if I was I wouldn't care about colour. My personal wish for this patch is for the light to be orange when it actually dark rather than at my bedtime (which is very variable). As such, Kobo's idea of sunset being at 18:00 all year round doesn't work for me. In the UK darkness falls (roughly) anywhere between 15:00 in winter to 21:00 in summer.

I'm very happy to change the on-device Bedtime setting, as required, as the seasons change. Based on today's experiments that suggests we need the patch to

• have an earlier start time than 21:00, but I don't personally need 21 different values at 30min intervals.
• be able to change sunset to something earlier than 18:00 and <= minimum "Bedtime" (or for me minimum dark time)

[pgaskin]

How does this look for the final patch:

Change ComfortLight bedtime range:
  - Enabled: no
  - Description: |
      Change the times available in the ComfortLight bedtime dropdown and the
      start/end times for the color change. All values in this patch are
      customizable.

      The default values for this patch give you 21 options between 5PM and 3AM
      at 30 minute intervals, with the colour change starting at 4PM, and the
      change back to blue between 5AM and 7AM. The firmware default is 13 options
      between 9PM-3AM at 30 minute intervals, with the transition starting at 6PM.
    #
    # In an unnamed subroutine two layers into FrontLightPopupController::loadView
    # (find it by going back from QTime::addSecs), the times for the dropdown are
    # generated into a QVector<QPair<QString, QTime>> with a simple loop.
    #
  # Change the starting hour passed to the QTime constructor (mov r1, #21):
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 17} # 21:00 (9PM) -> 17:00 (5PM)
  # Optional: Change the increment passed to QTime::addSecs (you need to use an
  # ARM assembler to change this value):
  - ReplaceBytes: {Offset: 0xA50EA2, FindH: 4F F4 E1 61, ReplaceH: 4F F4 E1 61} # mov.w r1, #1800: 30m
  # Change the number of increments (movs r5, #13):
  - ReplaceInt: {Offset: 0xA50E76, Find: 13, Replace: 21} # 13 [9PM..3AM]+30m -> 21 [5PM..3AM]+30m
  # Change the number of pre-allocated elements (I don't think this is actually
  # required, as Qt will realloc as necessary, but we might as well do this just
  # in case) (mov r1, #21):
  - ReplaceInt: {Offset: 0xA510DE, Find: 13, Replace: 21} # same as prev replacement
    #
    # The actual color adjustment is done in BedtimeManager::adjustTemperature.
    # The color temperature is based on the current time, the bedtime, the hardcoded
    # sunset, the hardcoded sunrise start, the hardcoded sunrise end, the daytime
    # temperature, and the nighttime temperature.
    #
  # Change the sunset time (the transition to a warmer temperature starts here
  # and transitions until the bedtime chosen) (this should be 1-3 hours before
  # the minimum bedtime from the first replacement above) (mov r1, #18):
  - ReplaceInt: {Offset: 0xA49A06, Find: 18, Replace: 16} # 18:00 (9PM-3=6PM) -> 16:00 (5PM-1=4PM)
  # Optional: Change the sunrise start time (the transition back to a cooler
  # temperature starts here) (this should be sometime after the last bedtime,
  # but before the sunset time) (mov r1, #5):
  - ReplaceInt: {Offset: 0xA49A28, Find: 5, Replace: 5} # 5AM
  # Optional: Change the sunrise end time (the transition back to a cooler
  # temperature ends here) (this should be 1-3 hours after the sunrise start but
  # before the sunset time or bad things will happen with negative values) (mov r1, #7):
  - ReplaceInt: {Offset: 0xA499F2, Find: 7, Replace: 7} # 5AM+2=7AM

[jackiew1]

It can do a job but If you want my honest opinion it's too dense with too much technical detail that detracts from what the average user needs to know to customise it.

I do understand that a lot of it is there to document what you've done and acts as a permanent reminder of the details of the processes involved. But do the users need to know all that?

In addition:

• Do we really need to expand the drop-down menu from 13 entries to 21 entries?
• Do we really need to do anything at all with Sunrise time and transition from orange back to blue? Has anyone ever mentioned early morning changes?

Also, the patch name needs to be more generic e.g.
Customize Comfortlight settings
as it's now more than just changing the bedtime range.

As your last post arrived I was just about to write to say that for my purposes the patch could be reduced to 2 find/replaces:

Customize Comfortlight settings:
  - Enabled: no
  - Description: |
      Change the times available in the ComfortLight bedtime drop-down and the
      start/end times for the colour change from cool to warm.
  # Change the starting hour for the Bedtime menu:
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 16}   # 21:00 (9PM) -> 16:00 (4PM)
  # change Sunset time from 18:00 to 15:00
  - ReplaceInt: {Offset: 0xA49A06, Find: 18, Replace: 15}

... or have I oversimplified this?

[pgaskin]

It can do a job but If you want my honest opinion it's too dense with too much technical detail that detracts from what the average user needs to know to customise it.

I agree with that completely.

I do understand that a lot of it is there to document what you've done and acts as a permanent reminder of the details of the processes involved. But do the users need to know all that?

Yes, that's why I put it there, but edited out some of the denser parts. I've settled on that style for my patches, especially the complex ones like this one, as it provides enough information for me to quickly recreate it if I need to (unlike things like the 24 line spacing values patch), and it also provides enough information for somebody without much experience to learn how to update it in case I ever stop updating the patches for whatever reason. Before each section of replacements, I describe which function it's in (for context), how to find that function (in case it loses it's function name due to optimization), and what the defining characteristic of it is (in case the code ever gets moved around, like with the new reader stuff). Before each replacement, I describe what it is replacing, the possible side effects, and the user-facing description and constraints. With each replacement, I show the previous and new values along with the assembly instruction (so someone interested doesn't have to decompile each instruction manually to read it -- this was one of the most time consuming parts of learning to update the patches a few years ago). So, yes, quite a bit of this info is extra for users, but this info is the minimum I can put to save a lot of time and effort in the future if it needs to be rewritten or if someone else updates it.

Do we really need to expand the drop-down menu from 13 entries to 21 entries?

My rationale was that there isn't any harm in putting them all there, and that a patch shouldn't remove functionality if possible.

Do we really need to do anything at all with Sunrise time and transition from orange back to blue? Has anyone ever mentioned early morning changes?

I'd be using it myself once I have a Clara, and it's also there for reference about the 5 and 7 times.

Also, the patch name needs to be more generic e.g.
Customize Comfortlight settings
as it's now more than just changing the bedtime range.

Yep, will fix that. Thanks!

As your last post arrived I was just about to write to say that for my purposes the patch could be reduced to 2 find/replaces:

Yes, that should work. And, did you try that to make sure the array reallocation isn't needed (I didn't think it was, but if it turned out to be, it would segfault or cause unusual bugs when building the array).

[jackiew1]

As your last post arrived I was just about to write to say that for my purposes the patch could be reduced to 2 find/replaces:

Yes, that should work. And, did you try that to make sure the array reallocation isn't needed (I didn't think it was, but if it turned out to be, it would segfault or cause unusual bugs when building the array).

I did it this way to try to minimise the mods required (for me). Do you think I may be creating problems for myself that I haven't fully understood?

In theory, it gives me 13 selectable Bedtimes from 16:00 to 21:00 and a constant start transition of 15:00 (sunset). I've now applied it to a Clara (Bedtime=16:00) and a Forma (Bedtime=21:00) for a proper test today. The theory is that:

• both should start to transition at 15:00
• the Clara will transition in a couple of big jumps
• the Forma will be a more gradual transition in more but smaller jumps.

Based on my (rather haphazard and accidental) observations so far I think the following may also be true:

• if you're actually reading normally as the sunset time is reached, no transition at all happens for the first 30mins.
• if there is a sleep/wake, PCconnect, ... etc ... during that first 30mins then there will be a colour transition to the correct level for the time the device "wakes up".
• or more generally, transition jumps happen every 30mins or whenever the device re-awakens - whichever is sooner.

Now, back to the full patch ... I'm not sure what changes you've already made but the following confused me so may confuse others:

• the first line comment of the following find/replace needs humanising

# Change the starting hour passed to the QTime constructor (mov r1, #21):
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 17} # 21:00 (9PM) -> 17:00 (5PM)

How about # Change the starting hour for the Bedtime drop-down menu

• What is the following find/replace actually for? ReplaceH is the same as FindH and it doesn't look like something where a user can choose their own ReplaceH?

  # Optional: Change the increment passed to QTime::addSecs (you need to use an
  # ARM assembler to change this value):
  - ReplaceBytes: {Offset: 0xA50EA2, FindH: 4F F4 E1 61, ReplaceH: 4F F4 E1 61} # mov.w r1, #1800: 30m

[pgaskin]

I was thinking you missed this part:

  # Change the number of pre-allocated elements (I don't think this is actually
  # required, as Qt will realloc as necessary, but we might as well do this just
  # in case) (mov r1, #21):
  - ReplaceInt: {Offset: 0xA510DE, Find: 13, Replace: 21} # same as prev replacement

But now I realize you only wanted to change the time, not the number of values. So yes, your patch is fine.

or more generally, transition jumps happen every 30mins or whenever the device re-awakens - whichever is sooner.

That looks like I might have to patch the timer code too.

the first line comment of the following find/replace needs humanising

Yep, missed that one (you can see the current version in my kobopatch-config repo.

What is the following find/replace actually for? ReplaceH is the same as FindH and it doesn't look like something where a user can choose their own ReplaceH?

That's for optionally changing the increment of 1800s, but if what I said about needing to change the timer is true, I'll probably remove this option.

[pgaskin]

I was right about missing the timer. Thanks for catching that!

Here is one timer. That is probably all you need:

00a49b1c 0025                   movs       r5, #0x0 ; CODE XREF=_ZN14BedtimeManager17adjustTemperatureEv+564
00a49b1e 1221                   movs       r1, #18
00a49b20 2B46                   mov        r3, r5
00a49b22 2A46                   mov        r2, r5
00a49b24 0095                   str        r5, [sp, #0x70 + var_70]
00a49b26 2046                   mov        r0, r4
00a49b28 61F6F2E2               blx        _ZN5QTimeC1Eiiii@PLT ; QTime::QTime(int, int, int, int)
00a49b2c 2A46                   mov        r2, r5
00a49b2e 2146                   mov        r1, r4
00a49b30 06F12800               add.w      r0, r6, #0x28
00a49b34 82F66AE6               blx        _ZN10PowerTimer6fireAtERK5QTimeN2Qt8TimeSpecE@PLT ; PowerTimer::fireAt(QTime const&, Qt::TimeSpec)
00a49b38 4437                   adds       r7, #0x44
00a49b3a BD46                   mov        sp, r7
00a49b3c BDE8F08F               pop.w      {r4, r5, r6, r7, r8, sb, sl, fp, pc}

Add the following:

- ReplaceInt: {Offset: 0xA49B1E, Find: 18, Replace: 15} # should match sunset time

[pgaskin]

And just as a note for myself, here's the other timer (which is for the next step of the change, and is calculated from the other times):

00a49bc6 6CF676E0               blx        _ZNK5QTime6minuteEv@PLT ; QTime::minute() const
00a49bca 0546                   mov        r5, r0
00a49bcc 4946                   mov        r1, sb
00a49bce 85FB0889               smull      r8, sb, r5, r8
00a49bd2 EA17                   asrs       r2, r5, #0x1f
00a49bd4 5346                   mov        r3, sl
00a49bd6 CDF800A0               str.w      sl, [sp, #0x70 + var_70]
00a49bda 2046                   mov        r0, r4
00a49bdc 4D44                   add        r5, sb
00a49bde C2EB2515               rsb        r5, r2, r5, asr #4
00a49be2 6A01                   lsls       r2, r5, #0x5
00a49be4 A2EB4502               sub.w      r2, r2, r5, lsl #1
00a49be8 61F692E2               blx        _ZN5QTimeC1Eiiii@PLT ; QTime::QTime(int, int, int, int)
00a49bec 2146                   mov        r1, r4
00a49bee 5846                   mov        r0, fp
00a49bf0 4FF620E6               blx        _ZNK5QTime7msecsToERKS_@PLT ; QTime::msecsTo(QTime const&) const
00a49bf4 011E                   subs       r1, r0, #0x0
00a49bf6 06F12800               add.w      r0, r6, #0x28
00a49bfa BEBF                   ittt       lt
00a49bfc 01F1A461               add.wlt    r1, r1, #0x5200000
00a49c00 01F5CB21               add.wlt    r1, r1, #0x65800
00a49c04 01F58061               add.wlt    r1, r1, #0x400
00a49c08 75F69EE3               blx        _ZN10PowerTimer6fireInEi@PLT ; PowerTimer::fireIn(int)
00a49c0c 4437                   adds       r7, #0x44
00a49c0e BD46                   mov        sp, r7
00a49c10 BDE8F08F               pop.w      {r4, r5, r6, r7, r8, sb, sl, fp, pc}

[jackiew1]

or more generally, transition jumps happen every 30mins or whenever the device re-awakens - whichever is sooner.

That looks like I might have to patch the timer code too.

I wasn't actually reporting it as an error, just an observation 😃 but if you think this new find/replace will improve things, all well and good.

- ReplaceInt: {Offset: 0xA49B1E, Find: 18, Replace: 15}   # should match Sunset hour

I've now applied it to both my Clara/Forma test devices ready for "Sunset" to happen at 15:00 (45mins from now).

What different behaviour should I be looking for, exactly, as a result of having added this extra patch line?

[pgaskin]

What different behaviour should I be looking for, exactly, as a result of having added this extra patch line?

It should start changing automatically at a sunset time before 6PM without needing to put it to sleep and wake it up again.

[jackiew1]

It did. I was reading the Clara at 15:00 when there was the tiniest shift off zero-orange. The slider hasn't moved again in the last 12mins of reading.

I've now just done a manual sleep/wake cycle and the slider moved quite a lot. To be expected given the full transition should be completed in 1hour start-to-finish.

[pgaskin]

OK, so that one worked. I might need to change the other timer too if it doesn't keep moving by itself.

[jackiew1]

The Clara moved on its own at 15:30.

[pgaskin]

The Clara moved on its own at 15:30.

So, it seems to work then. Do you think this patch is ready and bug-free now?

Customize ComfortLight settings:
  - Enabled: no
  - Description: |
      Change the times available in the ComfortLight bedtime dropdown and the
      start/end times for the color changes. All values in this patch are
      customizable.

      The default values for this patch give you 21 options between 5PM and 3AM
      at 30 minute intervals, with the colour change starting at 4PM, and the
      change back to blue between 5AM and 7AM. The firmware default is 13 options
      between 9PM-3AM at 30 minute intervals, with the transition starting at 6PM.
    #
    # In an unnamed subroutine two layers into FrontLightPopupController::loadView
    # (find it by going back from QTime::addSecs), the times for the dropdown are
    # generated into a QVector<QPair<QString, QTime>> with a simple loop.
    #
  # Change the initial hour / first dropdown item passed to the QTime constructor
  # (mov r1, #21):
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 17} # 21:00 (9PM) -> 17:00 (5PM)
  # Optional: Change the increment passed to QTime::addSecs (you need to use an
  # ARM assembler to change this value):
  - ReplaceBytes: {Offset: 0xA50EA2, FindH: 4F F4 E1 61, ReplaceH: 4F F4 E1 61} # mov.w r1, #1800: 30m
  # Change the number of increments / dropdown items (movs r5, #13):
  - ReplaceInt: {Offset: 0xA50E76, Find: 13, Replace: 21} # 13 [9PM..3AM]+30m -> 21 [5PM..3AM]+30m
  # Change the number of pre-allocated elements (I don't think this is actually
  # required, as Qt will realloc as necessary, but we might as well do this just
  # in case) (mov r1, #21):
  - ReplaceInt: {Offset: 0xA510DE, Find: 13, Replace: 21} # same as prev replacement
    #
    # The actual color adjustment is done in BedtimeManager::adjustTemperature.
    # The color temperature is based on the current time, the bedtime, the hardcoded
    # sunset, the hardcoded sunrise start, the hardcoded sunrise end, the daytime
    # temperature, and the nighttime temperature.
    #
  # Change the sunset time (the transition to a warmer temperature starts here
  # and transitions until the bedtime chosen) (this should be 1-3 hours before
  # the minimum bedtime from the first replacement above) (mov r1, #18):
  - ReplaceInt: {Offset: 0xA49A06, Find: 18, Replace: 16} # 18:00 (9PM-3=6PM) -> 16:00 (5PM-1=4PM)
  # Change the time for the sunset timer to fire at (this is passed to a QTime
  # constructor which is passed to PowerTime::fireAt) (mov r1, #18):
  - ReplaceInt: {Offset: 0xA49B1E, Find: 18, Replace: 16} # should match sunset time above
  # Optional: Change the sunrise start time (the transition back to a cooler
  # temperature starts here) (this should be sometime after the last bedtime,
  # but before the sunset time) (mov r1, #5):
  - ReplaceInt: {Offset: 0xA49A28, Find: 5, Replace: 5} # 5AM
  # Optional: Change the sunrise end time (the transition back to a cooler
  # temperature ends here) (this should be 1-3 hours after the sunrise start but
  # before the sunset time or bad things will happen with negative values) (mov r1, #7):
  - ReplaceInt: {Offset: 0xA499F2, Find: 7, Replace: 7} # 5AM+2=7AM

And here's another version using a lesser-known YAML feature:

Customize ComfortLight settings:
  - Enabled: no
  - Description: |
      Change the times available in the ComfortLight bedtime dropdown and the
      start/end times for the color changes. All values in this patch are
      customizable.

      The default values for this patch give you 21 options between 5PM and 3AM
      at 30 minute intervals, with the colour change starting at 4PM, and the
      change back to blue between 5AM and 7AM. The firmware default is 13 options
      between 9PM-3AM at 30 minute intervals, with the transition starting at 6PM.
    #
    # In an unnamed subroutine two layers into FrontLightPopupController::loadView
    # (find it by going back from QTime::addSecs), the times for the dropdown are
    # generated into a QVector<QPair<QString, QTime>> with a simple loop.
    #
  # Change the initial hour / first dropdown item passed to the QTime constructor
  # (mov r1, #21):
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 17} # 21:00 (9PM) -> 17:00 (5PM)
  # Optional: Change the increment passed to QTime::addSecs (you need to use an
  # ARM assembler to change this value):
  - ReplaceBytes: {Offset: 0xA50EA2, FindH: 4F F4 E1 61, ReplaceH: 4F F4 E1 61} # mov.w r1, #1800: 30m
  # Change the number of increments / dropdown items (movs r5, #13):
  - ReplaceInt: {Offset: 0xA50E76, Find: 13, Replace: &increments 21} # 13 [9PM..3AM]+30m -> 21 [5PM..3AM]+30m
  # Change the number of pre-allocated elements (I don't think this is actually
  # required, as Qt will realloc as necessary, but we might as well do this just
  # in case) (mov r1, #21):
  - ReplaceInt: {Offset: 0xA510DE, Find: 13, Replace: *increments} # same as prev replacement
    #
    # The actual color adjustment is done in BedtimeManager::adjustTemperature.
    # The color temperature is based on the current time, the bedtime, the hardcoded
    # sunset, the hardcoded sunrise start, the hardcoded sunrise end, the daytime
    # temperature, and the nighttime temperature.
    #
  # Change the sunset time (the transition to a warmer temperature starts here
  # and transitions until the bedtime chosen) (this should be 1-3 hours before
  # the minimum bedtime from the first replacement above) (mov r1, #18):
  - ReplaceInt: {Offset: 0xA49A06, Find: 18, Replace: &sunset 16} # 18:00 (9PM-3=6PM) -> 16:00 (5PM-1=4PM)
  # Change the time for the sunset timer to fire at (this is passed to a QTime
  # constructor which is passed to PowerTime::fireAt) (mov r1, #18):
  - ReplaceInt: {Offset: 0xA49B1E, Find: 18, Replace: *sunset} # should match sunset time above
  # Optional: Change the sunrise start time (the transition back to a cooler
  # temperature starts here) (this should be sometime after the last bedtime,
  # but before the sunset time) (mov r1, #5):
  - ReplaceInt: {Offset: 0xA49A28, Find: 5, Replace: 5} # 5AM
  # Optional: Change the sunrise end time (the transition back to a cooler
  # temperature ends here) (this should be 1-3 hours after the sunrise start but
  # before the sunset time or bad things will happen with negative values) (mov r1, #7):
  - ReplaceInt: {Offset: 0xA499F2, Find: 7, Replace: 7} # 5AM+2=7AM

[jackiew1]

So, it seems to work then. Do you think this patch is ready and bug-free now?

The Clara just completed its transition to orange at 16:00 with no manual intervention whilst I was reading normally. So a 1 hour full transition works as expected. There's nothing more to be learned from the Clara today.

I'd say it's working correctly, but I want to let the Forma's transition play out to the end before giving a final opinion. This should have a 6-hour transition which will complete at 21:00.

I need to go and do something (unrelated) now. I'll comment on your revised patch shortly when I come back.

[NiLuJe]

As a completely useless data point, the Kindle uses geolocation to request sunset/sunrise times at the user's location ;).

[jackiew1]

Comments:

• Using variable names when the same value is required in multiple places. With my programmer hat on, this seems like a good idea and one I might try elsewhere in my custom patches. Is it documented somewhere? For non-techies, I'm not sure whether it helps or hinders if they haven't seen it before. A bit of education might help, or an extra comment on subsequent lines where a varname is referenced e.g. "# *** Don't change the next line ***"

• To make it clearer what it does, change "first dropdown" to "first Bedtime dropdown" in the comment for

  # Change the initial hour / first dropdown item passed to the QTime constructor
  # (mov r1, #21):
  - ReplaceInt: {Offset: 0xA50E3E, Find: 21, Replace: 17} # 21:00 (9PM) -> 17:00 (5PM)

• Why is this still here? It still doesn't appear to serve any purpose from a user POV. What are they supposed to do with it?

  # Optional: Change the increment passed to QTime::addSecs (you need to use an
  # ARM assembler to change this value):
  - ReplaceBytes: {Offset: 0xA50EA2, FindH: 4F F4 E1 61, ReplaceH: 4F F4 E1 61} # mov.w r1, #1800: 30m

• Perhaps make it clearer how much choice users have in changing the number of increments. Is it a free choice? Or should they either leave it at 21 or comment it out completely (like I did).

  # Change the number of increments / dropdown items (movs r5, #13):
  - ReplaceInt: {Offset: 0xA50E76, Find: 13, Replace: 21} # 13 [9PM..3AM]+30m -> 21 [5PM..3AM]+30m
  # Change the number of pre-allocated elements (I don't think this is actually
  # required, as Qt will realloc as necessary, but we might as well do this just
  # in case) (mov r1, #21):
  - ReplaceInt: {Offset: 0xA510DE, Find: 13, Replace: 21} # same as prev replacement

[jackiew1]

As a completely useless data point, the Kindle uses geolocation to request sunset/sunrise times at the user's location ;).

Does that require wi-fi to be on or does it just use the device's timezone setting? Anything which absolutely requires wi-fi to be on is the devil's work as far as I'm concerned. 😃

[pgaskin]

Using variable names when the same value is required in multiple places. With my programmer hat on, this seems like a good idea and one I might try elsewhere in my custom patches. Is it documented somewhere? For non-techies, I'm not sure whether it helps or hinders if they haven't seen it before. A bit of education might help, or an extra comment on subsequent lines where a varname is referenced e.g. "# *** Don't change the next line ***"

Yes, although the use is quite limited. The value must have already been defined as a property of another element (i.e. you can't have things like config vars), the variable is global (I'd rather not use them too much), and it's all or nothing (i.e. you can't concatenate strings or that kind of thing). I'd rather not document it, as it's not something I want to officially endorse using for these reasons.

To make it clearer what it does, change "first dropdown" to "first Bedtime dropdown" in the comment for

👍

Why is this still here? It still doesn't appear to serve any purpose from a user POV. What are they supposed to do with it?

You can replace it with something like armconverter.com.

Perhaps make it clearer how much choice users have in changing the number of increments. Is it a free choice? Or should they either leave it at 21 or comment it out completely (like I did).

I'll add some more notes about that.

[NiLuJe]

As a completely useless data point, the Kindle uses geolocation to request sunset/sunrise times at the user's location ;).

Does that require wi-fi to be on or does it just use the device's timezone setting? Anything which absolutely requires wi-fi to be on is the devil's work as far as I'm concerned. smiley

Of course it does, it's Amazon, after all ;). Kindle are, by design, getting more and more hobbled when they're in airplane mode...

[jackiew1]

Using variable names when the same value is required in multiple places. With my programmer hat on, this seems like a good idea and one I might try elsewhere in my custom patches. Is it documented somewhere? For non-techies, I'm not sure whether it helps or hinders if they haven't seen it before. A bit of education might help, or an extra comment on subsequent lines where a varname is referenced e.g. "# *** Don't change the next line ***"

Yes, although the use is quite limited. The value must have already been defined as a property of another element (i.e. you can't have things like config vars), the variable is global (I'd rather not use them too much), and it's all or nothing (i.e. you can't concatenate strings or that kind of thing). I'd rather not document it, as it's not something I want to officially endorse using for these reasons.

It sounds like we ought to pretend that there's only one version of the patch, namely the one without varnames.

Why is this still here? It still doesn't appear to serve any purpose from a user POV. What are they supposed to do with it?

You can replace it with something like armconverter.com.

Are we having a serious conversation? How many users are going to do that? I must say that I look forward to reading your extensive user help notes. 😄

[jackiew1]

As a completely useless data point, the Kindle uses geolocation to request sunset/sunrise times at the user's location ;).

Does that require wi-fi to be on or does it just use the device's timezone setting? Anything which absolutely requires wi-fi to be on is the devil's work as far as I'm concerned. smiley

Of course it does, it's Amazon, after all ;). Kindle are, by design, getting more and more hobbled when they're in airplane mode...

... and still so many users won't consider buying anything else. I wonder if there will ever be a "straw that breaks the camel's back" moment. Their KFX format abomination marketed as "enhanced reading experience" was mine.

[pgaskin]

It sounds like we ought to pretend that there's only one version of the patch, namely the one without varnames.

Yes, I'll probably keep the version without variables.

Are we having a serious conversation? How many users are going to do that? I must say that I look forward to reading your extensive user help notes.

I expect the people who don't know or care how to do it leave it alone, the people who want a specific value to ask me if needed, and the more resourceful people to know how to figure it out.

I think I'll push the patch once I do the improvements mentioned previously.

[jackiew1]

If you're going to do a full patch release you may want to have a closer look at libnickel patches
"Don't uppercase header/footer text:"
"Don't uppercase header/footer text and change page number text:"
because they both appear to be the same. The first one is supposed to exclude the page number text find/replace (last 2 lines)

It's almost 21:00 and I'm pretty confident my patched Forma is working as expected.

[pgaskin]

If you're going to do a full patch release

I'm probably not doing a full patch release for at least a week so I can give the current one time to settle, and because this is a relatively niche patch as of right now (if people are interested, they can get it directly from the linked commit on the request thread).

because they both appear to be the same. The first one is supposed to exclude the page number text find/replace (last 2 lines)

Look closer 😄. The difference is of vs /. One changes the text, and one just lowercases it.

It's almost 21:00 and I'm pretty confident my patched Forma is working as expected.

That's good to hear.

[jackiew1]

Look closer 😄. The difference is of vs /. One changes the text, and one just lowercases it.

OK, you've got me there. My mistake 😃