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-09-11

00:48:53 Quit Moriar (Quit: Leaving.)
01:19:20 Join lebellium [0] (
01:21:35 Join lebellium_ [0] (~lebellium@2a01:cb10:2e:2000:8c28:4598:d196:2d54)
01:24:38 Quit lebellium (Ping timeout: 260 seconds)
01:40:03***Saving seen data "./dancer.seen"
01:47:21 Join ZincAlloy [0] (
02:17:49 Quit massiveH (Quit: Leaving)
03:40:07***Saving seen data "./dancer.seen"
03:55:42 Quit bluebrother^ (Read error: Connection reset by peer)
03:55:42 Quit rb-bluebot_ (Read error: No route to host)
04:09:36 Join bluebrother [0] (~dom@user/bluebrother)
04:29:14 Join mendel_munkis [0] (
04:29:16 Quit munkis (Remote host closed the connection)
04:34:24blbro[m]How about: keep the last week, then only one per week?
05:40:11***Saving seen data "./dancer.seen"
05:50:49sporkthere has not been a commit, the last 6 daily builds are identical. seem there is room for optimizing that
05:51:04spork*there has not been a commit since sunday
06:01:32braewoodsis it just me or does daily builds seem silly if the input source has not changed?
06:02:22braewoodsnot that the alternative doesn't have its own flaws
06:21:33 Quit wolfshappen (Quit: later)
07:27:03speachyall other retention (and generation) strategies require more effort to set up.
07:27:28speachythe retention strategey right now is "delete anything older than X days"
07:27:38braewoodsspeachy: is it? if it's tied to git it could be tied to commit activity.
07:27:43speachyit's not.
07:27:55braewoodsthe source builds are. i take it the rest aren't
07:28:56speachyit simplifies other things −− "latest" always points towards "yesterday's date", for example.
07:29:44speachyso of course it's all fungible (it's "just software" after all) but as I said earlier, it's a matter of tradeoffs.
07:32:29braewoodsusually only the very latest dev build is used so i'm not sure why we even have an archive of those.
07:33:28braewoodswe often end up having to go back to make a custom build if we're testing when something broke anyway since it usually goes unnoticed
07:33:42speachywe don't generate voice files for dev builds
07:34:15braewoodsso that's what these daily builds are?
07:34:40speachyand having a swath of pre-built older binaries helps a lot for tracking regressions. especially for folks that don't/can't build stuff for themselves.
07:35:16speachythe starting point for the most recent daily build is the most recent dev build. then manuals and voice files are built for that commitid.
07:37:18braewoodsspeachy: how do you feel about the m3k? given what i've heard about its repairability i wonder how useful as a long term target it would be.
07:37:54braewoodsthe xduoo x3 at least is easier to repair
07:37:59braewoodsfor the battery anyway
07:38:15speachythe x3 is unobtanium now, and also (when new) cost more
07:38:38braewoodsyea but it's at least repairable when it does show up albeit rarely
07:38:43speachythe m3k has the undeniable advantage of being readily available today, and the cheapest thing on the supported list (new)
07:39:11speachylong-term depends entirely on how many fiio sells in the end
07:39:32braewoodsspeachy: also worth considering that many of rockbox's targets were super expensive when new
07:39:33speachymost modern-ish players aren't terribly repairable.
07:39:35braewoodslike the H120
07:40:13***Saving seen data "./dancer.seen"
07:40:19speachyyep. including the ipods.
07:40:38braewoodsi do like the xduoo x3, despite how rare it is right now. i at least can replace the battery with minimal fuss.
07:41:04braewoodsprobably the best stable target that's relatively new, assuming you can find one.
07:41:10speachyI like it a lot, but it's undeniably janky, hardware-wise.
07:41:23braewoodswhat's janky about it?
07:41:45braewoodsis that just from programming it?
07:41:47speachythe power supply and analog sections. sucker gets _hot_
07:42:09braewoodsmeaning hot to the touch?
07:42:26braewoodsis that why the case is aluminum?
07:42:32braewoodsit uses it for heat dissipation?
07:42:35speachyyep, even with that metal case it's poorly heat-sinked.
07:42:50speachythat's why the battery life is so poor
07:43:01speachy(and why the batteries seem to wear out prematurely)
07:43:17speachyall that heat is dumped unevenly into the battery
07:43:24braewoodsi see.
07:44:09braewoodsdoesn't look like there's any room for a heatsink inside.
07:44:36speachythere aren't even any thermal pads to make it more efficient
07:44:53speachyif you try to add any the extra pressure against the case causes the front buttons to stop working
07:45:44braewoodsi see. too bad.
07:46:06speachythe x3ii is _far, far_ better engineered
07:46:18braewoodswas the native port ever finished?
07:46:21speachynever started
07:46:42braewoodstoo much work?
07:46:51braewoodsi kinda wondered if the fiio m3k would allow it to work out.
07:46:58speachy"insufficient developer interest"
07:47:18speachythe base x1000 platform is very solid, just needs the target-specific stuff written
07:47:38braewoodssimilar to the xduoo x20?
07:48:32speachyx3ii and x20 are nearly identical from the linux port's perspective, but that hides a lot of stuff that a native port would have to care about
07:48:50speachy(eg very different DAC/audio path)
07:50:27braewoodsany way to reduce heat in the x3?
07:50:33braewoodslike running at a lower clockspeed?
07:50:49speachynope, the reclocking work I did made zero differente on battery lifetime
07:51:02braewoodsi didn't ask about battery life
07:51:07braewoodsi asked about actual heat
07:51:15speachyit's actually the same thing
07:51:27speachysince power that comes out of the battery gets radiated as heat
07:51:37speachysame life == same current draw == same heat
07:52:01speachy(or at least it was close enough to be considered a rounding error)
07:52:08braewoodsgiven the photos i'm seeing of the insides
07:52:25braewoodsit's also subjected to the heat given off by the processor
07:52:37braewoodsprobably the hottest chip
07:52:51speachyusing the battery as a heat sink is pretty common actually
07:53:17braewoodstoo bad it wasn't engineered to use the case itself for heat dissipation.
07:53:43speachywell, it does, sorta, since the battery is glued to the case. just not put together efficiently enough
07:54:09speachyI think a little extra engineering could have made a big difference
07:54:30braewoodsand nothing we can do after the fact?
07:54:35speachybut hey, should woulda coulda
07:54:52braewoodswhat charging current does the X3 use?
07:55:14braewoodsone idea might be to use a smaller battery and add your own heat spreader
07:55:32braewoodsbut it might need the pressure to keep stuff from falling in
07:55:49speachyon the front side could probably cut out a custom thermal pad, especially behind the main soc, which would provide better heatsinking and keep the buttons from getting mashed
07:56:41speachyand then doing something similar on the back side, to improve sinking to the battery
07:57:47speachynothing we can do about the underlying heat output
07:59:41speachyI can't comment on charging current specifically, but the whole thing does max out at 0.5a at the USB connector.
08:01:39speachydon't know which side is current-limiting that.
08:03:11speachywhole thing gets _hot_ when charging.
08:10:27braewoodsspeachy: so it doesn't use the BCS. interesting. but then its battery is so small that the BCS wouldn't help anyway.
08:11:10braewoodsBCS seems more often used by phones or tablets with beefier batteries to charge
08:11:34speachyI'm 75% sure the battery and charging circuitry is a bolted-on manual affair rather than integrated into a PMIC or whatnot.
08:21:31 Join wolfshappen [0] (
08:27:07 Quit wolfshappen (Ping timeout: 252 seconds)
08:27:41 Join wolfshappen [0] (
09:06:19 Join dconrad [0] (~dconrad@
09:07:44dconradare xduoo's linux sources published? maybe it is time to do a native port to the x3ii
09:09:22dconradI mean, the rb x1000 port is well set up enough that the hardest part is disassembling the OF, which wasn't as hard as I expected when I did it
09:16:13dconradassuming all the x1000 players use the same usb, msc, pmu, rtc, you really just need to find gpio and lcd info iirc
09:16:34dconraddac/audio stuff being known
09:28:27speachyno sources, but yeah, just the lcd and gpio stuff to sort out
09:28:50speachy(well, plus the DACs)
09:28:53dconradoh, and nand, assuming it uses the same nand
09:29:17speachyit probably does
09:29:44speachy(or at least a drop-in compatible replacement)
09:29:52dconradhmm, maybe if I'm looking for something to do haha
09:30:34dconradthough I really don't need another player
09:32:05speachyI think you're well past that point. :D
09:32:40dconradwell, besides the ones I intend to get rid of...
09:34:23dconradI've got "big serious player" and "small portable player", which I think is a good combo
09:35:24dconradironically the small one has a better dac, but I think the big one can put out more power, plus line out
09:36:22dconrad...and more rb themes, which is fun
09:40:15***Saving seen data "./dancer.seen"
09:57:47 Quit ZincAlloy (Quit: Leaving.)
10:08:54 Quit dconrad (Remote host closed the connection)
10:43:24 Join dconrad [0] (~dconrad@
10:44:13 Join ZincAlloy [0] (
10:46:28dconradhmm, both my m3k and erosq are limited to 100mA charging unless plugged into a real computer, then they'll do 450mA
10:46:42dconradno wonder they've seemed like they take forever to charge
10:47:24dconradI wonder how we determine the appropriate charging current?
11:33:42speachyI don't think we have any software control over that
11:36:00dconradthat seems surprising - does that info come from the axp?
11:36:20dconradthe current info
11:40:11speachyit might!
11:40:16***Saving seen data "./dancer.seen"
11:41:13speachyok, now switched to the new server
11:45:49 Quit dconrad (Remote host closed the connection)
11:46:15speachynext to move will be and
11:47:16speachybut that's going to require advance notice
11:57:05speachyand I've already banned the first new IP address from d.r.o :/
11:59:11 Quit lebellium_ (Quit: Leaving)
12:23:22 Join dconrad [0] (~dconrad@
12:45:54 Join Moriar [0] (
13:40:17***Saving seen data "./dancer.seen"
14:47:49 Quit dconrad (Remote host closed the connection)
15:40:20***Saving seen data "./dancer.seen"
16:41:57 Join dconrad [0] (~dconrad@
16:46:31 Quit dconrad (Ping timeout: 252 seconds)
17:09:51braewoodsdconrad: it sounds like you need a smart charger and not some dumb one. most usb chargers require this to know how much they can safely draw (BCS) or to negotiate the charging parameters (PD)
17:10:07braewoods(or the various proprietary implementations like QC)
17:10:29braewoodsthough mp3 players probably only need BCS at most
17:10:53braewoodsi can't see needing more than 5V or 1.5A
17:11:06braewoodsthat's already way more than most of our targets use over usb
17:11:16 Quit Moriar (Quit: Leaving.)
17:11:43braewoodsalthough in this case it may be the more basic USB negotiation for bus power draw
17:14:34braewoodsso that's probably what's going on.
17:14:56braewoodsa proper charger would allow for most if not all of these methods
17:15:31braewoodsit's probably the m3k's circuitry not wanting to draw more than 0.1A unless it can be convinced it is connected to a faster power source
17:15:37braewoodsor more powerful rather
17:40:22***Saving seen data "./dancer.seen"
18:57:28 Quit ZincAlloy (Quit: Leaving.)
19:40:26***Saving seen data "./dancer.seen"
20:35:18 Join massiveH [0] (
20:43:58 Join dconrad [0] (~dconrad@
20:48:40 Quit dconrad (Ping timeout: 252 seconds)
20:56:31 Join dconrad [0] (~dconrad@
20:57:08dconradbraewoods: I dunno, I've tried 3 different chargers and they all give the same results, including a name brand apple one, which I can't imagine wouldn't do the smart id thing
20:58:58dconradactually, one of the other ones is an lg one as well
21:08:47dconradwell, we do have a void axp_set_charge_current(int maxcurrent)
21:14:07dconradaha, yeah I think we definitely have control over charging current
21:15:05dconrad(see usb_core.c, l 1008 - usb_charging_maxcurrent())
21:40:29***Saving seen data "./dancer.seen"
22:27:52dconradso, uh, if somebody who actually knows how the usb driver works wants to peek at g#3779 and g#3780
22:28:39dconradthe first being setting the default current to 500mA, which does work but it breaks USB entirely, locking up the device
22:29:21dconradthe second... does work but I have a hard time believing it could be such a simple fix, I need to research where both of those checks get set
22:30:05dconrad(no gerrit bot?)
22:31:20dconradit would seem we don't do any sort of checking what the source is capable of, we just seem to assume we can get half an amp
22:31:45dconradwhich, to be fair, is probably a fairly safe assumption
22:36:47speachynot having looked at the code you wrote, I'd think the rule needs to be: default to 100mA. If we enter full USB mode (ie exchange descriptors) then we'll negotiate as part of that process. if after X amount of time we haven't negotiated anything, just bump the rate up to 500mA.
22:37:43speachy"Traditionally" higher-amperage chargers have just set a resistance across the data pins, which the device can read and interpret
22:37:56speachy("higher" meaning >100mA)
22:37:56dconradfrom what I can tell that was the intention, but I think it was just accidentally "&&" rather than "||" in our code
22:38:20speachyI don't know if the axp (or our USB controller) can actually detect/read that
22:39:39speachyfor #3779, the device probably locks up because it's trying to draw more current than the host port will supply, causing a brownout.
22:39:53dconradthat makes sense, the computer thinks its malfunctioning
22:40:28dconradbut it is using that default value rather than the "charge only" value, as it does change the behavior
22:40:35speachyI'll need to re-wade through that change in 3780. I've been through the usb code end-to-end multiple times and I still can't get it straight
22:41:22dconradits definitely a mess
22:41:57speachywe have multiple usb operational paradigms that are handled by the same core code. it's going to be a mess. :/
22:42:31speachyI think you're right re 3780
22:42:59speachybut it's been a _long_ day and I'm too fried to be sure of my reasoning
22:44:03dconradyeah I get that - I intend to look into where usb_charging_mode and usb_no_host get set to be more sure of what they're used to indicate
22:44:40dconradjust kind of a "there's no way it's that simple"
22:44:54speachybut as of a few minutes ago the migration of git+gerrit can resume again.
22:45:28dconradoh right, I'm sure thats a real big task
22:45:51speachyhad to migrate the VPS from one site to another, due to a communication mixup
22:47:01dconradare they going to the same place you moved downloads to?
22:47:38dconradit's all gonna end up on the same vps, I imagine is the current plan
22:47:42speachyyep, nearly everything will move there
22:48:42speachyalready had a successful dry-run for git+gerrit before I had to do the vps move
22:49:58dconradout of left field, do we use an old version of gerrit or something? it doesn't play nicely with safari - I have to open chrome specifically for it
22:50:51dconradnot a big deal, just weird to have that much browser incompatibility in this day and age
22:55:40speachydunno, it's still a supported version I think
22:56:08dconradhuh, probably just not part of their testing
22:57:13speachyjust re-switched downloads to the new VPS again
22:57:45speachyso we'll see how things go, I guess.
22:58:38speachyanyway, time to go pass out.
23:01:41*dconrad waves
23:40:33***No seen item changed, no save performed.
23:50:02 Quit dconrad ()

Previous day | Next day