Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-07-06

01:06:24***Saving seen data "./dancer.seen"
01:21:27desowinthe lcd power off improved runtime from 8h 21min to 9h 27min, less than an hour away from OF
01:22:07desowinconsidering we run at maximum OF can, throttling is probably going to help
02:42:20 Quit j-r (Remote host closed the connection)
03:06:25***Saving seen data "./dancer.seen"
03:06:32 Join j-r [0] (
03:34:14desowinand well, I should use power instead of current for quickly checking change effectiveness
03:35:22desowinas current goes up when voltage drops, energy conversion efficiency at different input voltages is negligible
03:37:01 Quit kadoban (Ping timeout: 246 seconds)
04:06:11desowinabout time estimate, should it use the measured discharge rate, or should it use user (Rockbox firmware) entered discharge rate?
04:06:30desowinusing measured rate, the value changes quite significantly depending on the backlight
04:07:29desowinso you get lower (but adequate if you won't turn backlight off) estimate that goes up when screen if off
04:08:20desowinso it's pretty much ideal for blind users as they can just extend the battery life by always turning off backlight
05:06:28***Saving seen data "./dancer.seen"
07:06:32***No seen item changed, no save performed.
07:37:58braewoodsdesowin: why not make it a setting?
07:38:38braewoodsthe hardware is more reliable in theory but if they do a battery replacement somehow, the battery monitor / charger chip may no longer be accurate
08:32:41desowinwell, it wouldn't help as the estimate would still go from bq27000
08:45:50braewoodsi see
08:47:44 Join massiveH [0] (
09:03:03braewoodsinteresting. seems this quirk of whether directories are included or not depends on the archiving software.
09:03:27braewoodsthe ones we normally use do that but apparently android APKs exclude directories
09:06:36***No seen item changed, no save performed.
09:18:19 Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542)
10:14:34 Quit massiveH (Quit: Leaving)
11:03:09 Quit ufdm_ (Quit: Leaving)
11:03:22 Join ufdm [0] (
11:06:39***Saving seen data "./dancer.seen"
11:31:20 Join kadoban [0] (~kadoban@user/kadoban)
11:44:26braewoodsi see some improvements that could be added to the rockbox FAT driver.
11:44:43braewoodsmostly emulation of utime system call or something similar
11:45:09braewoodsto allow manual updates of mtime and atime fields
13:06:40***No seen item changed, no save performed.
13:09:07 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:1d24:7939:8db2:2195)
13:10:03 Join ZincAlloy [0] (~Adium@
13:19:14braewoodsspeachy: i think i found a suitable inflate library. it clearly states "This source code is public domain." is this a problem to use in rockbox?
13:19:37speachynope, PD is free-for-all
13:19:47braewoodsthought so but i thought i'd ask
13:19:59speachywe should still give credit, of course.
13:20:12braewoodsi plan to, i'm just going to strip out the parts we don't really need.
13:20:31braewoodsit needs ~2k bytes for its internal state struct
13:20:37braewoodsi doubt i can stack allocate that
13:20:50braewoodsso core_alloc here i come
13:21:04braewoodsi pick this because it's simple to integrate due to little integration with regular libc
13:27:56speachyoh, FYI −− Tropical Storm Elsa is projected to pretty much go straight overhead over the next 24 hours. I don't anticipate any outages but one never knows.
13:30:57braewoodsspeachy: btw, if we wanted to emulate utime, would it be difficult to integrate? all it does is allow manual setting of mtime and atime records or their equivalent thereof
13:31:22speachydon't see why it would matter. do any of our filesystems even have atime?
13:31:36braewoodsisn't that what acctime field is?
13:32:11speachyiirc fat32 just has mtime..
13:32:34braewoodsthe struct internally has only the date field for access
13:33:12braewoodsspeachy: fat.h shows fields for creation, modify, and access (very limited)
13:33:24braewoodsto date they're only updated automatically if at all
13:33:39speachythe fat32 directory entry only stores last modified time & date in separate fields.
13:33:56braewoodsi'm guessing limitation of underlying FS
13:34:00braewoodsor else it'd probably be present
13:34:10speachy(as in that's what is stored on-disk)
13:34:31braewoodsyea i understand, if we emulate it obviously will be crude and not 100%
13:34:42braewoodswe can just implement the portion we can use
13:34:54braewoodsand use the host version where full support is available
13:35:04speachyso ctime = mtime, and atime can always be "now"
13:35:32braewoodsjust not sure how one would write an api for updating these
13:35:40braewoodsthe FAT driver is a bit confusing
13:35:58speachyheh, atime isn't used that often any more even on more capable filesystems as it incurs a substantial performance penalty. plus wears out SSDs a lot faster than is otherwise necessary
13:36:22braewoodsit's probably why relatime and noatime are a thing
13:36:53braewoodsin any case i'd like to have a utime api if at all possible... just not sure how i'd do it myself
13:37:09braewoodsit would allow me to set the timestamps of extracted files to what is in the ZIP archive
13:37:52braewoodsi'll poke around and see what my options are for modifying only the file metadata
13:38:30braewoodsbut right now i'm focusing on inflate
13:38:46braewoodsfor reference this is the one i'm trying to adapt
13:39:00braewoodsi found it through an obscure link
13:40:10braewoodsit does break a few rockbox rules; i'll try to change the struct at least.
13:40:17braewoodsthe macros though would require a lot of rewriting
13:45:02speachyexternal code we pull in we try to modify as little as possible to make keeping it in sync easier.
13:47:04braewoodsi could just make it follow rules on the external header and alias it internally
13:47:12speachythat's reasonable
13:47:31speachyand matches our general behavior
13:53:44braewoodsi'm probably going to strip out their crc algorithm though since we already have one we can add
13:54:52*braewoods is trying to avoid duplicates of the same reusable algorithm.
14:11:18 Quit emacsomancer (Read error: Connection reset by peer)
14:12:55 Join emacsomancer [0] (
14:39:24 Join reductum [0] (
14:39:31desowinI don't get why powermgmt.c inflates the first battery voltage reading by 15 mV. It dates back to 11 Nov 2006 where I see absolutely no reason for "+ 15000" in the SVNr11507
14:39:56desowinlater that magic value just got scaled with the units changed
14:48:40speachyjust enough to keep teh device from auto-powering-off?
14:53:10desowinmaybe, but that still doesn't really answer the question "why?"
14:54:37speachyto prevent a boot loop cycle when the battery is really weak but charging
14:55:02speachynot saying that's why, but it is a scenario I've run into before
14:55:32speachyboost the initial reading a little prevent shutdown long enough to get some charging done
15:06:41***Saving seen data "./dancer.seen"
15:21:47_bilgusyes^ Ive had the same issues with sansa clip_
15:22:32_bilgusit brings the running average up but should pretty quickly settle towards the actual value
15:24:00_bilgusIve run into at least one that has such transients that every reading gets averaged before even attempting to get a value
15:28:23braewoodsthere's two main headers for deflate streams... and they both use different checksum algorithms.
15:28:44braewoodsshouldn't be too hard to support those later but for now i just need raw deflate stream support
15:31:09braewoods_bilgus: is there a reason we use bmp instead of png?
15:31:17braewoodsi'd guess simplicity
15:31:33_bilgusyep bitmaps are so easy
15:31:43braewoodsthough if we implement ZIP support we could rely on that for compression if we wanted to
15:31:49braewoodsfor loading files
15:32:27_bilgusI'd hazard a guess that it would not help anything
15:32:36braewoodsperhaps so
15:33:09_bilgusyou would still be utilizing it as a bitmap in the image buffer
15:33:52_bilgusnow maybe to store the compressed version in ram and load it to the buffer through the decompression maybe?
15:34:44_bilgusbut how much space are we talking here enough to justify having a decoder sitting in ram
15:37:03braewoodsno idea.
15:37:13 Join Maxdamantus [0] (~Maxdamant@user/maxdamantus)
15:37:32braewoodsin any case i'm working on adding inflate support that's pretty lightweight so we can support a large subset of zip files
15:37:32speachynot just decoder but the decompression overhead too
15:37:35speachypng isn't lightweight
15:37:44_bilgusjust the fact we can use themes as a zip is nice
15:38:14_bilgusno worries about unzipping them
15:38:18braewoodsthe main mode of operation i plan to support is extraction to disk but extraction to memory can also be a thing
15:38:27_bilguseither is fine
15:38:36_bilgusspace is pretty cheap
15:38:49braewoodsbut i at least need to support deflate to make this all work
15:39:05braewoodsi'm going to omit ZLIB / GZIP header support unless we can find a reason to add it later
15:39:22braewoodsbut it'll be possible to add it to the library
15:39:43braewoodsi mainly need raw stream processing
15:40:29braewoodsfrom what i understand ZIP doesn't need those headers since it already has a checksum in its archive metadata
15:42:21braewoods_bilgus: how big is the typical rockbox stack?
15:42:36_bilgusthats what I was just about to address
15:42:46_bilgusreading the tinflate lib
15:42:58_bilgusso you'd set up your thread
15:43:01braewoodsi was planning to allocate part of it dynamically
15:43:18_bilgusand feed it a stack I suppose
15:43:20braewoodsif i did, there's about 100 bytes that are stack allocated.
15:44:32_bilgustill it switches contexts I think every target has a default stack for threads
15:45:14_bilgusI'm not sure how that would work in core though
15:45:35braewoodsit's why my zip library puts most of the heavy stuff in a core_alloc buffer
15:45:50braewoodsi try to keep local stack usage below 60 bytes or so
15:46:33_bilguswell figure they all have a stack outlined in the map file but Ive no Idea how much you get of that before you blow it
15:47:15_bilgusI can get at least a file path on the stack in all targets
15:47:21_bilgusso 260 bytes
15:47:49braewoodsyea, i chose to put the file path in my zip buffer in the core_alloced handle
15:48:00braewoodsjust to reduce stress on the stack
15:49:11_bilgusI think you could still alloc a thread in core
15:49:27_bilgusit'd also allow you to set your stack
15:49:37braewoodswhy would I want to allocate a thread for this?
15:50:02_bilgusthen you get more control
15:50:28_bilgusits cooperative multi threading so you need to yield when ready
15:51:39_bilgusin fact you will be doing potentially long running actions
15:52:05braewoodsi thought that's what callbacks are for
15:52:42_bilgusI imagine you'd be yielding there
15:53:08_bilgusif you don't create your thread you would be running in the main thread
15:53:16braewoodsso i need to redesign my zip library to use threads?
15:53:20speachyhopefully the main thread.
15:53:24_bilgusso it'd still be the same diff I think just no control
15:53:55_bilguswell if you don't yield then it doesn't switch
15:54:38_bilgusso your callback would be the yield point
15:54:59_bilgusmostlikely call yield() the do the cb
15:55:37_bilgusI did something similar in lua
15:56:05braewoodsi'll yield but i think it best to stick to the caller's thread otherwise
15:56:44_bilgusyou shall find that out :)
15:57:07_bilgustheres a few docs that talk about it
15:57:11braewoodsi thought threads were mainly for long running background tasks
15:57:27braewoodszip isn't exactly intended to be running all the time
15:58:27 Quit ats (Quit: quieter GPU)
16:00:12braewoods_bilgus: what do you mean by that? lol
16:00:39_bilgusin terms of a dap a long running task is anything than the pb buffer
16:00:50_bilguslonger than.
16:02:56_bilgusstill I don't think that chnages your underlying code
16:03:20braewoodsunless i wanted to redesign it to put most stuff on the stack
16:03:22_bilgusits just going to be important to the next layer so something to keep in mind
16:05:43_bilguseh if you can keep it in its own buffer that seems much better
16:06:21_bilgusif you also set up that buffer to allow buflib to move the data then its pretty damn good
16:06:41braewoods_bilgus: erm... i saw the warning in comments about that.
16:07:08braewoodsbasically said don't use these with functions that yield
16:07:48braewoodsthat's why i opted for the unmovable data blocks while my zip code is running
16:07:54_bilgusthats a good point but I think you just have to se a mutex to do so
16:08:20braewoodsmy code is only intended to reserve memory for a brief while
16:08:44braewoodsbut it could take longer depending on the archive size
16:09:26braewoodsi'll add some yields to my code between major phases and in each callback run
16:09:48braewoodsi wasn't even aware how threading worked here
16:09:57braewoodsi'm used to regular threads which require little thought
16:10:17_bilguswell actually regual threads require so much more thought
16:10:27_bilgusits just glossed over
16:10:38_bilgusthese threads are v. simple
16:10:46braewoodsso more like fibers?
16:11:28_bilgusyeah I suppose from what I remember of them they weren't great either
16:12:02_bilgusyes in that definition exactly
16:12:09speachyit has occurred to me that since we no longer care about the really-limited sh parts, we could go to a full preemptible RTOS if we really wanted.
16:12:15_bilgusbut the fibers I remember were MS maybe
16:15:29_bilgusthe coop multitasking works really well here since we control all the source
16:34:27 Quit user890104 (Changing host)
16:34:27 Join user890104 [0] (~Venci@freemyipod/user890104)
16:34:34 Quit user890104 (Changing host)
16:34:34 Join user890104 [0] (~Venci@freemyipod/fmibot)
16:34:43 Quit user890104 (Changing host)
16:34:43 Join user890104 [0] (~Venci@freemyipod/user890104)
16:36:42 Join cockroach [0] (~blattodea@user/cockroach)
16:37:41 Join ats [0] (
17:03:01 Quit yosafbridge (Ping timeout: 265 seconds)
17:04:27 Join yosafbridge [0] (
17:06:42***Saving seen data "./dancer.seen"
17:15:18 Quit speachy (Quit: WeeChat 3.0.1)
17:15:32 Join speachy [0] (~speachy@
17:15:32Mode"#rockbox +v speachy" by ChanServ (
17:22:01 Quit speachy (Changing host)
17:22:01 Join speachy [0] (~speachy@rockbox/speachy)
17:22:01Mode"#rockbox +v speachy" by
17:25:14speachyok, cloaks are available. please let me know what you'd like.
17:26:22 Part speachy (WeeChat 3.0.1)
17:26:25 Join speachy [0] (~speachy@rockbox/speachy)
17:26:26Mode"#rockbox +v speachy" by ChanServ (
17:44:36 Quit lebellium (Quit: Leaving)
17:51:09 Quit ZincAlloy (Quit: Leaving.)
19:06:44***Saving seen data "./dancer.seen"
19:45:15 Join dconrad [0] (~dconrad@
21:06:48***No seen item changed, no save performed.
21:23:53 Quit cockroach (Quit: leaving)
23:06:52***Saving seen data "./dancer.seen"
23:31:38 Quit dconrad ()

Previous day | Next day