| 00:48:53 | | Quit Moriar (Quit: Leaving.) |
| 01:00 |
| 01:19:20 | | Join lebellium [0] (~lebellium@lfbn-str-1-613-4.w90-126.abo.wanadoo.fr) |
| 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] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 02:00 |
| 02:17:49 | | Quit massiveH (Quit: Leaving) |
| 03:00 |
| 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:00 |
| 04:09:36 | | Join bluebrother [0] (~dom@user/bluebrother) |
| 04:29:14 | | Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 04:29:16 | | Quit munkis (Remote host closed the connection) |
| 04:34:24 | blbro[m] | How about: keep the last week, then only one per week? |
| 05:00 |
| 05:40:11 | *** | Saving seen data "./dancer.seen" |
| 05:50:49 | spork | there has not been a commit, the last 6 daily builds are identical. seem there is room for optimizing that |
| 05:51:04 | spork | *there has not been a commit since sunday |
| 06:00 |
| 06:01:32 | braewoods | is it just me or does daily builds seem silly if the input source has not changed? |
| 06:02:22 | braewoods | not that the alternative doesn't have its own flaws |
| 06:21:33 | | Quit wolfshappen (Quit: later) |
| 07:00 |
| 07:27:03 | speachy | all other retention (and generation) strategies require more effort to set up. |
| 07:27:28 | speachy | the retention strategey right now is "delete anything older than X days" |
| 07:27:38 | braewoods | speachy: is it? if it's tied to git it could be tied to commit activity. |
| 07:27:43 | speachy | it's not. |
| 07:27:55 | braewoods | the source builds are. i take it the rest aren't |
| 07:28:00 | braewoods | ? |
| 07:28:56 | speachy | it simplifies other things −− "latest" always points towards "yesterday's date", for example. |
| 07:29:44 | speachy | so 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:29 | braewoods | usually only the very latest dev build is used so i'm not sure why we even have an archive of those. |
| 07:33:28 | braewoods | we 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:42 | speachy | we don't generate voice files for dev builds |
| 07:34:15 | braewoods | so that's what these daily builds are? |
| 07:34:40 | speachy | and 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:16 | speachy | the 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:18 | braewoods | speachy: 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:54 | braewoods | the xduoo x3 at least is easier to repair |
| 07:37:59 | braewoods | for the battery anyway |
| 07:38:15 | speachy | the x3 is unobtanium now, and also (when new) cost more |
| 07:38:38 | braewoods | yea but it's at least repairable when it does show up albeit rarely |
| 07:38:43 | speachy | the m3k has the undeniable advantage of being readily available today, and the cheapest thing on the supported list (new) |
| 07:39:11 | speachy | long-term depends entirely on how many fiio sells in the end |
| 07:39:32 | braewoods | speachy: also worth considering that many of rockbox's targets were super expensive when new |
| 07:39:33 | speachy | most modern-ish players aren't terribly repairable. |
| 07:39:35 | braewoods | like the H120 |
| 07:40:13 | *** | Saving seen data "./dancer.seen" |
| 07:40:19 | speachy | yep. including the ipods. |
| 07:40:38 | braewoods | i do like the xduoo x3, despite how rare it is right now. i at least can replace the battery with minimal fuss. |
| 07:41:04 | braewoods | probably the best stable target that's relatively new, assuming you can find one. |
| 07:41:10 | speachy | I like it a lot, but it's undeniably janky, hardware-wise. |
| 07:41:23 | braewoods | what's janky about it? |
| 07:41:45 | braewoods | is that just from programming it? |
| 07:41:47 | speachy | the power supply and analog sections. sucker gets _hot_ |
| 07:42:09 | braewoods | meaning hot to the touch? |
| 07:42:26 | braewoods | is that why the case is aluminum? |
| 07:42:32 | braewoods | it uses it for heat dissipation? |
| 07:42:35 | speachy | yep, even with that metal case it's poorly heat-sinked. |
| 07:42:50 | speachy | that's why the battery life is so poor |
| 07:43:01 | speachy | (and why the batteries seem to wear out prematurely) |
| 07:43:17 | speachy | all that heat is dumped unevenly into the battery |
| 07:43:24 | braewoods | i see. |
| 07:44:09 | braewoods | doesn't look like there's any room for a heatsink inside. |
| 07:44:36 | speachy | there aren't even any thermal pads to make it more efficient |
| 07:44:53 | speachy | if you try to add any the extra pressure against the case causes the front buttons to stop working |
| 07:45:44 | braewoods | i see. too bad. |
| 07:46:06 | speachy | the x3ii is _far, far_ better engineered |
| 07:46:18 | braewoods | was the native port ever finished? |
| 07:46:21 | speachy | never started |
| 07:46:42 | braewoods | too much work? |
| 07:46:51 | braewoods | i kinda wondered if the fiio m3k would allow it to work out. |
| 07:46:58 | speachy | "insufficient developer interest" |
| 07:47:18 | speachy | the base x1000 platform is very solid, just needs the target-specific stuff written |
| 07:47:38 | braewoods | similar to the xduoo x20? |
| 07:48:32 | speachy | x3ii 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:50 | speachy | (eg very different DAC/audio path) |
| 07:50:27 | braewoods | any way to reduce heat in the x3? |
| 07:50:33 | braewoods | like running at a lower clockspeed? |
| 07:50:49 | speachy | nope, the reclocking work I did made zero differente on battery lifetime |
| 07:51:02 | braewoods | i didn't ask about battery life |
| 07:51:07 | braewoods | i asked about actual heat |
| 07:51:15 | speachy | it's actually the same thing |
| 07:51:18 | braewoods | oh |
| 07:51:27 | speachy | since power that comes out of the battery gets radiated as heat |
| 07:51:37 | speachy | same life == same current draw == same heat |
| 07:52:01 | speachy | (or at least it was close enough to be considered a rounding error) |
| 07:52:08 | braewoods | given the photos i'm seeing of the insides |
| 07:52:25 | braewoods | it's also subjected to the heat given off by the processor |
| 07:52:35 | speachy | yep |
| 07:52:37 | braewoods | probably the hottest chip |
| 07:52:51 | speachy | using the battery as a heat sink is pretty common actually |
| 07:53:17 | braewoods | too bad it wasn't engineered to use the case itself for heat dissipation. |
| 07:53:43 | speachy | well, it does, sorta, since the battery is glued to the case. just not put together efficiently enough |
| 07:54:09 | speachy | I think a little extra engineering could have made a big difference |
| 07:54:30 | braewoods | and nothing we can do after the fact? |
| 07:54:35 | speachy | but hey, should woulda coulda |
| 07:54:52 | braewoods | what charging current does the X3 use? |
| 07:55:14 | braewoods | one idea might be to use a smaller battery and add your own heat spreader |
| 07:55:32 | braewoods | but it might need the pressure to keep stuff from falling in |
| 07:55:49 | speachy | on 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:41 | speachy | and then doing something similar on the back side, to improve sinking to the battery |
| 07:57:47 | speachy | nothing we can do about the underlying heat output |
| 07:59:41 | speachy | I can't comment on charging current specifically, but the whole thing does max out at 0.5a at the USB connector. |
| 08:00 |
| 08:01:39 | speachy | don't know which side is current-limiting that. |
| 08:03:11 | speachy | whole thing gets _hot_ when charging. |
| 08:10:27 | braewoods | speachy: so it doesn't use the BCS. interesting. but then its battery is so small that the BCS wouldn't help anyway. |
| 08:11:10 | braewoods | BCS seems more often used by phones or tablets with beefier batteries to charge |
| 08:11:34 | speachy | I'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] (~waff@irc.furworks.de) |
| 08:27:07 | | Quit wolfshappen (Ping timeout: 252 seconds) |
| 08:27:41 | | Join wolfshappen [0] (~waff@irc.furworks.de) |
| 09:00 |
| 09:06:19 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 09:07:44 | dconrad | are xduoo's linux sources published? maybe it is time to do a native port to the x3ii |
| 09:09:22 | dconrad | I 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:13 | dconrad | assuming all the x1000 players use the same usb, msc, pmu, rtc, you really just need to find gpio and lcd info iirc |
| 09:16:34 | dconrad | dac/audio stuff being known |
| 09:27:39 | speachy | nope |
| 09:28:06 | dconrad | bummer |
| 09:28:27 | speachy | no sources, but yeah, just the lcd and gpio stuff to sort out |
| 09:28:50 | speachy | (well, plus the DACs) |
| 09:28:53 | dconrad | oh, and nand, assuming it uses the same nand |
| 09:29:17 | speachy | it probably does |
| 09:29:44 | speachy | (or at least a drop-in compatible replacement) |
| 09:29:52 | dconrad | hmm, maybe if I'm looking for something to do haha |
| 09:30:34 | dconrad | though I really don't need another player |
| 09:32:05 | speachy | I think you're well past that point. :D |
| 09:32:40 | dconrad | well, besides the ones I intend to get rid of... |
| 09:33:06 | dconrad | :-P |
| 09:34:23 | dconrad | I've got "big serious player" and "small portable player", which I think is a good combo |
| 09:35:24 | dconrad | ironically the small one has a better dac, but I think the big one can put out more power, plus line out |
| 09:36:22 | dconrad | ...and more rb themes, which is fun |
| 09:40:15 | *** | Saving seen data "./dancer.seen" |
| 09:57:47 | | Quit ZincAlloy (Quit: Leaving.) |
| 10:00 |
| 10:08:54 | | Quit dconrad (Remote host closed the connection) |
| 10:43:24 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 10:44:13 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 10:46:28 | dconrad | hmm, both my m3k and erosq are limited to 100mA charging unless plugged into a real computer, then they'll do 450mA |
| 10:46:42 | dconrad | no wonder they've seemed like they take forever to charge |
| 10:47:24 | dconrad | I wonder how we determine the appropriate charging current? |
| 11:00 |
| 11:33:42 | speachy | I don't think we have any software control over that |
| 11:36:00 | dconrad | that seems surprising - does that info come from the axp? |
| 11:36:20 | dconrad | the current info |
| 11:40:11 | speachy | it might! |
| 11:40:16 | *** | Saving seen data "./dancer.seen" |
| 11:40:42 | dconrad | hmm |
| 11:41:13 | speachy | ok, download.rockbox.org now switched to the new server |
| 11:45:49 | | Quit dconrad (Remote host closed the connection) |
| 11:46:15 | speachy | next to move will be gerrit.rockbox.org and git.rockbox.org |
| 11:47:16 | speachy | but that's going to require advance notice |
| 11:57:05 | speachy | and I've already banned the first new IP address from d.r.o :/ |
| 11:59:11 | | Quit lebellium_ (Quit: Leaving) |
| 12:00 |
| 12:23:22 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 12:45:54 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 13:00 |
| 13:40:17 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:47:49 | | Quit dconrad (Remote host closed the connection) |
| 15:00 |
| 15:40:20 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:41:57 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 16:46:31 | | Quit dconrad (Ping timeout: 252 seconds) |
| 17:00 |
| 17:09:51 | braewoods | dconrad: 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:07 | braewoods | (or the various proprietary implementations like QC) |
| 17:10:29 | braewoods | though mp3 players probably only need BCS at most |
| 17:10:53 | braewoods | i can't see needing more than 5V or 1.5A |
| 17:11:06 | braewoods | that's already way more than most of our targets use over usb |
| 17:11:16 | | Quit Moriar (Quit: Leaving.) |
| 17:11:43 | braewoods | although in this case it may be the more basic USB negotiation for bus power draw |
| 17:14:34 | braewoods | so that's probably what's going on. |
| 17:14:56 | braewoods | a proper charger would allow for most if not all of these methods |
| 17:15:31 | braewoods | it'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:37 | braewoods | or more powerful rather |
| 17:40:22 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:57:28 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:00 |
| 19:40:26 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:35:18 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 20:43:58 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 20:48:40 | | Quit dconrad (Ping timeout: 252 seconds) |
| 20:56:31 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 20:57:08 | dconrad | braewoods: 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:58 | dconrad | actually, one of the other ones is an lg one as well |
| 21:00 |
| 21:08:47 | dconrad | well, we do have a void axp_set_charge_current(int maxcurrent) |
| 21:14:07 | dconrad | aha, yeah I think we definitely have control over charging current |
| 21:15:05 | dconrad | (see usb_core.c, l 1008 - usb_charging_maxcurrent()) |
| 21:40:29 | *** | Saving seen data "./dancer.seen" |
| 22:00 |
| 22:27:52 | dconrad | so, uh, if somebody who actually knows how the usb driver works wants to peek at g#3779 and g#3780 |
| 22:28:39 | dconrad | the first being setting the default current to 500mA, which does work but it breaks USB entirely, locking up the device |
| 22:29:21 | dconrad | the 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:05 | dconrad | (no gerrit bot?) |
| 22:31:20 | dconrad | it 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:45 | dconrad | which, to be fair, is probably a fairly safe assumption |
| 22:36:47 | speachy | not 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:43 | speachy | "Traditionally" higher-amperage chargers have just set a resistance across the data pins, which the device can read and interpret |
| 22:37:56 | speachy | ("higher" meaning >100mA) |
| 22:37:56 | dconrad | from what I can tell that was the intention, but I think it was just accidentally "&&" rather than "||" in our code |
| 22:38:20 | speachy | I don't know if the axp (or our USB controller) can actually detect/read that |
| 22:39:39 | speachy | for #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:53 | dconrad | that makes sense, the computer thinks its malfunctioning |
| 22:40:28 | dconrad | but it is using that default value rather than the "charge only" value, as it does change the behavior |
| 22:40:35 | speachy | I'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:22 | dconrad | its definitely a mess |
| 22:41:57 | speachy | we have multiple usb operational paradigms that are handled by the same core code. it's going to be a mess. :/ |
| 22:42:31 | speachy | I think you're right re 3780 |
| 22:42:59 | speachy | but it's been a _long_ day and I'm too fried to be sure of my reasoning |
| 22:44:03 | dconrad | yeah 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:40 | dconrad | just kind of a "there's no way it's that simple" |
| 22:44:54 | speachy | but as of a few minutes ago the migration of git+gerrit can resume again. |
| 22:45:28 | dconrad | oh right, I'm sure thats a real big task |
| 22:45:51 | speachy | had to migrate the VPS from one site to another, due to a communication mixup |
| 22:47:01 | dconrad | are they going to the same place you moved downloads to? |
| 22:47:38 | dconrad | it's all gonna end up on the same vps, I imagine is the current plan |
| 22:47:42 | speachy | yep, nearly everything will move there |
| 22:48:42 | speachy | already had a successful dry-run for git+gerrit before I had to do the vps move |
| 22:49:58 | dconrad | out 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:51 | dconrad | not a big deal, just weird to have that much browser incompatibility in this day and age |
| 22:55:40 | speachy | dunno, it's still a supported version I think |
| 22:56:08 | dconrad | huh, probably just not part of their testing |
| 22:57:13 | speachy | just re-switched downloads to the new VPS again |
| 22:57:45 | speachy | so we'll see how things go, I guess. |
| 22:58:38 | speachy | anyway, time to go pass out. |
| 23:00 |
| 23:01:41 | * | dconrad waves |
| 23:40:33 | *** | No seen item changed, no save performed. |
| 23:50:02 | | Quit dconrad () |
icon identifies that the person is a core developer (has commit access).