| 00:18:55 | | Quit massiveH (Quit: Leaving) |
| 00:23:31 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 01:00 |
| 01:00:01 | | Quit massiveH (Quit: Leaving) |
| 01:01:55 | | Quit olspookishmagus (*.net *.split) |
| 01:02:05 | | Join pookie [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 01:03:58 | | Quit Topy44 (*.net *.split) |
| 01:03:58 | | Quit braewoods (*.net *.split) |
| 01:03:58 | | Quit ats (*.net *.split) |
| 01:04:04 | | Join Topy [0] (ylKyK9sn6S@bellatrix.uberspace.de) |
| 01:04:45 | | Join braewoods [0] (~braewoods@braewoods.net) |
| 01:05:16 | | Quit dbohdan (*.net *.split) |
| 01:05:16 | | Quit scorche (*.net *.split) |
| 01:05:16 | | Quit ddevault (*.net *.split) |
| 01:05:16 | | Quit gsora_ (*.net *.split) |
| 01:05:17 | | Quit Ckat (*.net *.split) |
| 01:05:26 | | Join Ckatt [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 01:05:46 | | Join scorche [0] (~scorche@184-98-25-134.phnx.qwest.net) |
| 01:05:54 | *** | Saving seen data "./dancer.seen" |
| 01:06:17 | | Quit jackie (*.net *.split) |
| 01:06:17 | | Quit leachim6 (*.net *.split) |
| 01:06:53 | | Join leachim6 [0] (~leachim6@neptune.cosmicforge.org) |
| 01:10:55 | | Join dbohdan [0] (~dbohdan@2a00:d880:3:1::a6e3:a64e) |
| 01:11:25 | | Quit dbohdan (Changing host) |
| 01:11:25 | | Join dbohdan [0] (~dbohdan@user/dbohdan) |
| 01:11:36 | | Nick scorche is now known as Guest5135 (~scorche@184-98-25-134.phnx.qwest.net) |
| 01:13:44 | | Join XDjackieXD [0] (~jackie@banana-new.kilobyte22.de) |
| 01:13:54 | | Join ddevault [0] (znc@sourcehut/staff/ddevault) |
| 01:13:56 | | Nick leachim6 is now known as Guest9931 (~leachim6@neptune.cosmicforge.org) |
| 01:14:13 | | Join ats [0] (~ats@cartman.offog.org) |
| 01:16:40 | | Join gsora [0] (~gsora@140.238.174.213) |
| 01:51:43 | | Join eminguez [0] (~eminguez@196.red-79-159-201.dynamicip.rima-tde.net) |
| 03:00 |
| 03:05:55 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:22:03 | desowin | it looks like Rockbox lcd_enable() is what Sansa Connect OF calls sleep/wake while Rockbox lcd_sleep() is power off/on |
| 04:38:31 | | Quit eminguez (Quit: Ping timeout (120 seconds)) |
| 05:00 |
| 05:05:58 | *** | Saving seen data "./dancer.seen" |
| 05:23:20 | | Join eminguez [0] (~eminguez@196.red-79-159-201.dynamicip.rima-tde.net) |
| 07:00 |
| 07:05:55 | | Quit braewoods (Quit: WeeChat 2.8) |
| 07:05:55 | | Nick Ckatt is now known as Ckat (~Ckat@xn--z7x.xn--6frz82g) |
| 07:05:59 | *** | Saving seen data "./dancer.seen" |
| 07:06:20 | | Join braewoods [0] (~braewoods@user/braewoods) |
| 07:08:04 | | Nick Ckat is now known as Ckatt (~Ckat@xn--z7x.xn--6frz82g) |
| 07:08:16 | | Nick Ckatt is now known as Ckat (~Ckat@xn--z7x.xn--6frz82g) |
| 09:00 |
| 09:06:01 | *** | No seen item changed, no save performed. |
| 09:20:42 | | Quit eminguez (Quit: Connection closed) |
| 09:39:22 | rb-bluebot | Build Server message: New build round started. Revision 2acf8db3e1, 297 builds, 8 clients. |
| 09:40:04 | desowin | that's a few mA saved when hold is on (screen off), so the runtime gap between OF and Rockbox should now be smaller |
| 09:40:41 | desowin | I wonder how much throttling can save |
| 09:44:27 | speachy | desowin: probably low double-digit percentages at best |
| 09:45:52 | speachy | the analog path tends to be the dominant power drain, and with the codecs going pretty much everything other than the CPU has to keep running. |
| 09:48:33 | speachy | on the xduoo x3 (which admittedly is worst than most) I saw negligible power savings from downclocking the CPU to ~25% |
| 09:52:48 | desowin | well, OF tends to most heavily downclock the SDRAM |
| 09:52:58 | desowin | they have throttle for cpu, sdram, axl and dsp |
| 09:53:34 | braewoods | hah. gotta love how chain assignments don't really work without warnings when mixing pointer and integer types even when the original value is a 0 constant |
| 09:53:41 | speachy | on the X3 the reclocking also introduced audible audio artifacts, which is why I was ultimately never enabled. |
| 09:53:52 | braewoods | which would normally go without warning |
| 09:54:31 | speachy | (slight pop everytime the clock was changed.. changing only the core CPU clock divider; the PLL, bus, sdram, etc didn't change) |
| 09:57:56 | rb-bluebot | Build Server message: Build round completed after 1113 seconds. |
| 09:57:59 | rb-bluebot | Build Server message: Revision 2acf8db3e1 result: All green |
| 10:00 |
| 10:01:11 | braewoods | It's not easy being green~ |
| 10:02:02 | desowin | in sansa connect dsp sends data over i2s, so as long as dsp clock stays constant and sdram is not too heavily downclocked, there shouldn't be any pops |
| 10:03:58 | braewoods | reminds me of the time i had to disable Linux dmix in order to eliminate audio issues on an ARM based device using a USB sound device |
| 10:04:07 | braewoods | dmix was too much for it |
| 10:04:33 | braewoods | and was overkill anyway for what i was doing |
| 10:05:32 | braewoods | though on most Linux hardware i've used dmix causes no issues |
| 10:09:55 | | Quit pookie (Quit: All for nothing) |
| 10:11:36 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 10:58:16 | | Quit akaWolf (Ping timeout: 258 seconds) |
| 11:00 |
| 11:06:05 | *** | Saving seen data "./dancer.seen" |
| 11:07:03 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 12:00 |
| 12:25:32 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 12:42:44 | | Quit Natch (Remote host closed the connection) |
| 12:49:34 | | Join Natch [0] (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) |
| 12:52:47 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 12:53:02 | | Quit ufdm (Read error: Connection reset by peer) |
| 13:00 |
| 13:06:09 | *** | Saving seen data "./dancer.seen" |
| 13:11:06 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:e9ca:38cc:83d9:a9a6) |
| 13:13:47 | braewoods | g#3519, any comments? |
| 13:13:48 | rb-bluebot | Gerrit review #3519 at https://gerrit.rockbox.org/r/c/rockbox/+/3519 : zip: import initial zip module by James Buren |
| 13:15:02 | braewoods | i've tested it already and it seems to work but i still need to write integration code. |
| 13:44:12 | braewoods | desowin: what kind of battery does the connect have? i know it's lion since pretty much everything uses that but how is it connected to the board? |
| 13:48:12 | braewoods | from the pictures there's no obvious cable going from it |
| 13:48:19 | braewoods | it looks like like a cell phone battery |
| 13:49:13 | braewoods | makes me think replacing it woudln't be easy |
| 13:50:09 | braewoods | no after markets made for it... |
| 13:53:34 | braewoods | hm. the closest i could find is the E280 or so. |
| 13:53:45 | braewoods | in any case |
| 14:00 |
| 14:27:39 | braewoods | oh wow it seems this is even worse than the soldered batteries in newer sansas |
| 14:28:39 | braewoods | that's one thing we'd need to solve for this port to be practical today |
| 14:28:45 | braewoods | battery replacement |
| 14:30:30 | _bilgus | I've had luck re-using the frame and filling it with a bag from a similar sized pack |
| 14:31:00 | braewoods | _bilgus: time to review some code? :) |
| 14:31:36 | _bilgus | not but if its up I may tonight |
| 14:31:42 | braewoods | ok |
| 14:31:44 | braewoods | it's up already |
| 14:31:46 | braewoods | g#3519 |
| 14:31:48 | rb-bluebot | Gerrit review #3519 at https://gerrit.rockbox.org/r/c/rockbox/+/3519 : zip: import initial zip module by James Buren |
| 14:32:10 | braewoods | fairly large by my regular commits |
| 14:34:11 | _bilgus | on the public api (.h) could you add comments for them? at least brief desc expected args |
| 14:34:33 | braewoods | ok. |
| 14:35:37 | | Quit munkis (*.net *.split) |
| 14:35:37 | | Quit richbridger (*.net *.split) |
| 14:35:37 | | Quit bluebrother (*.net *.split) |
| 14:35:37 | | Quit advcomp2019 (*.net *.split) |
| 14:35:37 | | Quit tchan (*.net *.split) |
| 14:35:37 | | Quit Galois (*.net *.split) |
| 14:35:37 | | Quit SammysHP (*.net *.split) |
| 14:35:37 | | Quit Retr0id (*.net *.split) |
| 14:35:38 | | Quit Airwave (*.net *.split) |
| 14:35:38 | | Quit bertrik (*.net *.split) |
| 14:36:05 | braewoods | _bilgus: just most rockbox headers don't even have that |
| 14:37:34 | _bilgus | open and close are self explanatory read shallow and deep need something |
| 14:39:07 | _bilgus | we also don't use typedefs |
| 14:39:44 | * | braewoods raises an eyebrow. |
| 14:39:51 | braewoods | I see those littered all over the firmware. |
| 14:39:58 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 14:39:58 | | Join richbridger [0] (~richbridg@213-225-32-103.nat.highway.a1.net) |
| 14:39:58 | | Join bluebrother [0] (~dom@55d4dc16.access.ecotel.net) |
| 14:39:58 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 14:39:58 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 14:39:58 | | Join bertrik [0] (~bertrik@revspace/participant/bertrik) |
| 14:39:58 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 14:39:58 | | Join Airwave [0] (~Airwave@ti0006a400-1599.bb.online.no) |
| 14:39:58 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 14:39:58 | | Join Retr0id [0] (~Retr0id@user/retr0id) |
| 14:40:33 | | Quit richbridger (Max SendQ exceeded) |
| 14:40:58 | | Join richbridger [0] (~richbridg@213-225-32-103.nat.highway.a1.net) |
| 14:41:37 | braewoods | i see typedefs for function pointers... plain integers... |
| 14:41:48 | _bilgus | https://git.rockbox.org/cgit/rockbox.git/tree/docs/CONTRIBUTING |
| 14:43:06 | braewoods | well... there's port specific code that doesn't follow that rule. so which is it? |
| 14:43:35 | _bilgus | there are rules broken here and there but in core rarely |
| 14:44:00 | braewoods | https://github.com/Rockbox/rockbox/blob/master/firmware/target/hosted/samsungypr/ypr0/sc900776.h |
| 14:44:30 | braewoods | ok... it's just going to mean a shitload of reworking this then. |
| 14:44:38 | braewoods | i used the aliases all over the place |
| 14:45:03 | _bilgus | I've been here done this when I started as well |
| 14:45:18 | _bilgus | I'm sure its in the IRC logs :) |
| 14:45:25 | braewoods | i'm just used to using typedefs to keep names short. |
| 14:46:33 | _bilgus | problem being as I have come to realize over time is it has the potential to introduce really hard to find bugs and makes it hard to follow code |
| 14:47:21 | _bilgus | now in the plugins eh do whatever and vendor code well sometimes it is what it is? |
| 14:48:13 | braewoods | No code in .h |
| 14:48:16 | braewoods | files or #defines. |
| 14:48:21 | braewoods | i guess all headers break the latter rule. |
| 14:48:31 | braewoods | header guards technically break no defines |
| 14:58:31 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 15:00 |
| 15:06:13 | *** | Saving seen data "./dancer.seen" |
| 15:30:50 | braewoods | _bilgus: done. |
| 15:31:43 | braewoods | i only have one typedef now, for the function pointer |
| 15:43:35 | | Quit dconrad (Remote host closed the connection) |
| 15:59:20 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 16:00 |
| 16:03:29 | | Quit dconrad (Ping timeout: 252 seconds) |
| 16:03:56 | _bilgus | braewoods, looks good to me its not touching anything else so ill push it |
| 16:04:42 | rb-bluebot | Build Server message: New build round started. Revision b87e75f768, 297 builds, 8 clients. |
| 16:05:05 | braewoods | _bilgus: thanks... i mainly needed to see that it would build on all ports. |
| 16:05:13 | braewoods | i tested it on some of mine |
| 16:05:28 | _bilgus | well without anything hooking it I doubt it'll touch much |
| 16:05:37 | braewoods | yea, i hope so. |
| 16:05:57 | braewoods | my next initiative is adding a high level API for some common uses |
| 16:06:29 | braewoods | this level was just to provide the foundation for people to customize their interface to it |
| 16:07:17 | braewoods | i also need to find an inflate library i can use or modify for transparent decompression |
| 16:08:02 | _bilgus | if you need more room you could do a plugin overlay |
| 16:08:24 | desowin | braewoods: it is glued with the tiny pcb to the back case. The battery pcb is https://www.rockbox.org/wiki/pub/Main/SansaConnect/pcb-battery.jpeg |
| 16:08:32 | _bilgus | basically it loads a plugin sets everything up and then extracts code over the initial plugin |
| 16:08:36 | desowin | the B- and B+ are the terminals for the cell |
| 16:09:19 | braewoods | looks like it was spot welded originally |
| 16:09:41 | braewoods | those big plates are normally for spot welding to |
| 16:10:18 | braewoods | so yea, replacing the battery is non-trivial... |
| 16:10:24 | desowin | everything is wrapped with non-conductive black something |
| 16:10:48 | desowin | only the four pads that make contact with the connector on main pcb are not covered |
| 16:11:03 | braewoods | you basically need to use a pouch cell that fits the terminals |
| 16:11:26 | desowin | you'd have to program the bq27000 to get good readings as well |
| 16:11:28 | braewoods | no cylindrical cell would fit there |
| 16:11:45 | braewoods | why? because it's tuned for the old battery? |
| 16:12:09 | desowin | it knows quite a lot about the cell, so it gives you really nice data |
| 16:12:11 | braewoods | i'm assuming you mean that the battery needs to be power cycled |
| 16:12:31 | desowin | like compensated state of charge, time to empty and so on |
| 16:12:33 | braewoods | i've heard some systems can "learn" the battery through power cycling it |
| 16:12:45 | braewoods | fill it up, drain it full, repeat a few times |
| 16:13:11 | braewoods | is that same here or does it literally have to be reprogramed |
| 16:13:33 | braewoods | i'm just thankful the gigabeat S has such an easy to replace battery |
| 16:14:38 | desowin | bq27000 does learn over the cycles, not sure how the initial parameters affect it |
| 16:18:25 | desowin | I think the temperature compensation gain and offset is not "learnable" |
| 16:18:57 | rb-bluebot | Build Server message: Build round completed after 854 seconds. |
| 16:19:00 | rb-bluebot | Build Server message: Revision b87e75f768 result: All green |
| 16:48:06 | | Quit pablocastellanos (Remote host closed the connection) |
| 16:49:43 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 16:53:48 | | Quit cockroach (Client Quit) |
| 16:53:49 | | Join cockroac1 [0] (~blattodea@user/cockroach) |
| 17:00 |
| 17:04:22 | | Quit lebellium (Quit: Leaving) |
| 17:06:15 | *** | Saving seen data "./dancer.seen" |
| 17:09:26 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 17:58:11 | braewoods | _bilgus: i'm trying to create a mkdir recursively routine but i realized i don't even know how the volume/drive works in regards to the path. |
| 17:58:25 | braewoods | so my code would fail for multi-volume or multi-drive ports |
| 17:58:28 | braewoods | (or both) |
| 17:58:36 | braewoods | _bilgus: is it documented anywhere? |
| 17:59:29 | _bilgus | in the source? i'm not sure exactly what you are asking |
| 17:59:49 | braewoods | under Linux, all paths uses the same root file tree. |
| 18:00 |
| 18:00:01 | braewoods | but how do you specify the volume/drive in rockbox paths? |
| 18:00:08 | _bilgus | 0 1 2 |
| 18:00:15 | braewoods | so like |
| 18:00:20 | braewoods | 1/foo/bar ? |
| 18:00:26 | _bilgus | 0/ is root 1/ is first sd |
| 18:00:44 | braewoods | what if partitions are involved? |
| 18:01:04 | _bilgus | I think you can enumerate them by checking for validity |
| 18:01:12 | _bilgus | not sure |
| 18:01:27 | braewoods | mostly just wanted to know how it is specified so i can handle the path processing correctly |
| 18:01:32 | _bilgus | Ive yet to run into partitions |
| 18:01:47 | braewoods | i'm planning to add a new pathfuncs function for mkdir recursive |
| 18:01:55 | braewoods | since i suspect it may prove useful elsewhere |
| 18:02:01 | braewoods | it would basically emulate mkdir -p |
| 18:02:10 | _bilgus | I assume its the same but perhaps its another scheme |
| 18:04:48 | __builtin | braewoods, _bilgus : "no code in .h files or defines" means that you should not define functions inside header files or macros |
| 18:05:10 | __builtin | obviously you must have #defines in header files |
| 18:05:27 | _bilgus | yep and ive done so but I think its in a plugin |
| 18:05:43 | braewoods | macros still must be used for things. |
| 18:05:49 | braewoods | some kinds of constants or so |
| 18:06:00 | braewoods | does it mean function-like macros? |
| 18:06:12 | braewoods | those i've already seen used in rockbox headers |
| 18:06:25 | __builtin | not strictly |
| 18:06:53 | braewoods | about the only function that might be added to a header is inline functions, an alternative to function macros sometimes |
| 18:07:02 | __builtin | you can define function-style macros such as LOGF, IF_COP, etc |
| 18:07:22 | __builtin | but only in select circumstances |
| 18:07:43 | braewoods | at least goto isn't off the table |
| 18:08:06 | __builtin | obviously you can use your discretion about stuff like this |
| 18:08:11 | braewoods | i use it when i want to reuse local code segments |
| 18:08:26 | __builtin | sometimes goto is the best way, but you should think very carefully about it |
| 18:08:37 | braewoods | i already have a pretty good idea when to use goto |
| 18:08:52 | braewoods | i mainly use it to consolidate on a single exit path when i have resources to manage |
| 18:09:09 | __builtin | yeah, that's about the only case I can think of |
| 18:09:26 | __builtin | that and breaking out of a deeply nested block |
| 18:59:54 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:00 |
| 19:02:27 | | Quit dconrad (Remote host closed the connection) |
| 19:06:16 | *** | Saving seen data "./dancer.seen" |
| 19:09:52 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 19:14:10 | | Quit dconrad (Ping timeout: 240 seconds) |
| 19:31:32 | | Join Pl3x6 [0] (~Pl3x6@ip4d165a16.dynamic.kabel-deutschland.de) |
| 19:31:59 | Pl3x6 | hi all |
| 19:36:07 | Pl3x6 | i need hlp to install rockbox on cowon D2 |
| 19:36:11 | Pl3x6 | :D |
| 19:37:31 | speachy | Pl3x6: https://www.rockbox.org/wiki/CowonD2Info |
| 19:38:42 | speachy | I'm pretty sure that nobody active here has ever owned a D2, so those instructions are the best we can suggest. |
| 19:39:12 | braewoods | speachy: question about volumes. it seems rockbox treats partitions and drives both as a volume. is that correct? |
| 19:40:23 | braewoods | just trying to understand how the volume/drive specifier fits into all this |
| 19:40:30 | braewoods | in paths |
| 19:42:14 | Pl3x6 | hi all . |
| 19:42:19 | Pl3x6 | thanks i chek this |
| 19:47:51 | | Quit Pl3x6 (Quit: Client closed) |
| 20:00 |
| 20:20:36 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 20:58:36 | speachy | braewoods: each drive+partition gets a unique volumeid, IIRC. paths are always relative to that volumeid. |
| 21:00 |
| 21:00:11 | _bilgus | is there a enum function for them or is it 0-? |
| 21:00:20 | speachy | 0-whatever, I think |
| 21:00:58 | _bilgus | so in theory you've no clue if its a volume or a partition at end user code? |
| 21:01:09 | speachy | don't recall if there are convenience functions to enumerate them; each entry in the volume structure has an "active" flag or whatnot |
| 21:01:30 | speachy | I think so, yes. Now down in the filesystem code that's different. |
| 21:01:52 | _bilgus | yeah IIRC set a loop to max volumes + max partition and went to 0 |
| 21:02:20 | _bilgus | then you check if valid for a sanity check |
| 21:06:17 | *** | Saving seen data "./dancer.seen" |
| 21:11:40 | | Quit dbohdan (Quit: ZNC 1.7.2+deb3 - https://znc.in) |
| 21:11:52 | | Join dbohdan [0] (~dbohdan@user/dbohdan) |
| 21:12:36 | speachy | it does get messy with respect to removable media. |
| 21:13:15 | speachy | but IIRC we only enable "multivolume" on stuff whose OF used more than one paritition; otherwise we just assume one partition per device. |
| 21:33:09 | | Quit cockroac1 (Quit: leaving) |
| 23:00 |
| 23:06:20 | *** | Saving seen data "./dancer.seen" |
| 23:08:36 | | Join aquijoule_ [0] (~richbridg@213-225-13-36.nat.highway.a1.net) |
| 23:10:52 | | Quit richbridger (Ping timeout: 246 seconds) |
| 23:29:43 | | Quit dconrad () |
| 23:32:30 | braewoods | ok third gigabeat S repaired |
| 23:32:34 | braewoods | :} |
| 23:36:30 | braewoods | bluebrother: i've found my solution for rbutil's support for gigabeat S. |
| 23:37:12 | braewoods | i'm working on adding ZIP support to the bootloader so we can send the ZIP archive we'd normally extract over MTP for the bootloader to deal with |
| 23:37:37 | braewoods | bluebrother: what would that require out of rbutil? |
| 23:37:52 | braewoods | after that it can just use rockbox's usb storage driver |
| 23:41:54 | braewoods | on second thought i just realized |
| 23:42:13 | braewoods | given how ZIP archives directories i don't need to make a mkdir recursive setup |
| 23:42:26 | braewoods | it'll re-create the parent directories for me |
| 23:42:34 | braewoods | before i ever need to process the regular files |
icon identifies that the person is a core developer (has commit access).