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-03-05

00:03:01_bilgusbout time
00:03:11_bilgusbuiltin and the all green
00:04:32***Saving seen data "./dancer.seen"
00:04:34braewoodsspeachy: i've researched the problem. i think hid power is the wrong solution... after reading linux source, i found out there's two protocols for device battery reporting over USB.
00:04:52braewoodsthe logitech one which appears to be bound to logitech product/vendor IDs...
00:04:57braewoodsso no buena for that reaso
00:05:13braewoodsand some kind of HID battery strength thing
00:05:27braewoodsit appears it can be grafted over the existing HID driver
00:05:30braewoodsi'll look into it
00:11:12braewoodswow. battery strength is in a part of the main HID spec.
00:11:27braewoodsreally obscure but it's there
00:13:08fs-bluebotBuild Server message: New build round started. Revision 925dc59126, 293 builds, 9 clients.
00:22:38fs-bluebotBuild Server message: Build round completed after 570 seconds.
00:22:42fs-bluebotBuild Server message: Revision 925dc59126 result: All green
02:04:34***No seen item changed, no save performed.
02:44:05 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
03:05:37 Quit Saijin-Naib (Ping timeout: 260 seconds)
03:21:10 Join Saijin_Naib [0] (
04:04:38***Saving seen data "./dancer.seen"
04:28:00braewoodsHuh. It was seriously that easy?
04:28:14braewoodswhy didn't we do this sooner?
04:28:48braewoodsspeachy: i have a working prototype, only issue is i'm not too sure when i should deploy the updates
04:46:09braewoodsi think we can enable usb hid in charging only mode if this works out acceptably
04:46:19braewoodsand just not send reports for the other HID types
04:46:26braewoodsonly send battery reports
04:50:37 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:31:42 Quit pamaury (Remote host closed the connection)
05:34:40 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
06:03:02speachybraewoods: once per second?
06:04:41***Saving seen data "./dancer.seen"
06:27:15 Quit ArsenArsen_ (Remote host closed the connection)
06:27:38 Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen)
06:33:02 Quit TorC (Ping timeout: 264 seconds)
06:38:33 Quit pamaury (Ping timeout: 258 seconds)
06:53:59 Join TorC [0] (~Tor@fsf/member/TorC)
07:03:30 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
07:19:09 Quit speachy (Quit: WeeChat 3.0.1)
07:47:36 Join massiveH [0] (
08:04:44***Saving seen data "./dancer.seen"
08:38:08_bilgusSo I think we need a plan for this voice file issue as you daid its only going to get worse
08:38:49_bilgusI'm thinking maybe better compression might buy us some time
08:39:30_bilgusprobably though its need to be that plugins have their own voice file that we load to the plugin buffer to keep it off of core
08:40:40_bilguseither that or we need to incrementally load the voices but that could quickly get hairy
08:44:03 Quit massiveH (Quit: Leaving)
09:56:56 Nick mendelmunkis is now known as mendel_munkis (
10:04:40 Join speachy [0] (40eebded@
10:04:46***Saving seen data "./dancer.seen"
10:06:32speachy_bilgus, It's a pretty hairy problem.. right now there's no way to specify string/voice scope, and given how much functionality is implemented via seamless plugin loads/unloads, it'll get rather hairy to swap voice stuff in and out.
10:07:29speachyin other words, do we generate per-plugin language+voice files, and [re]load that stuff every time we launch a plugin?
10:08:56speachybetter compression might help, but it'll come at the expense of overhead (has to coexist with the main audio codec running) −− and speex will be hard to beat.
10:21:52speachyOur only real avenue with speex is to drop quality (even if just going to 8KHz narrowband vs the current 16KHz).   If we are to ditch speex, our only real option is Opus, which will give us equivalent quality at a lower bitrate, but the codec is more heavyweight
10:31:59speachythe m200 has 1(!) MB only, the old sansa AMSes have 2MB, and the AMSv2s  have 8MB.    (most of the hosted targets are limited to 8MB too)
10:33:27speachyoh, for speex, going from the current 16KHz encoded stuff to 8KHz encoding knocks the voice size down by about 1/3
10:34:57speachyso maybe that's a compromise we can make in the short term −− for <=8MB players, switch to narrowband encoding for speech?
10:36:30_bilgusspeachy the voice subsystem has the ability to incrementally load voice files
10:37:32_bilgusbut I'm not so sure this is what is going on anymore either
10:38:00speachyyeah.. if the engine only loads voice stuff on demand, splitting things up shouldn't matter, right?
10:38:23_bilguswell it sets its own buffer
10:38:44_bilgusand I don't think that has changed
10:38:56_bilgusthe size of it that is
10:40:02_bilgusso I'm chasing a symptom but is that the cause or is someone else behaving badly now that the memory is getting tighter
10:40:06speachygoing from q7 to q6 saves about 10% only.
10:40:25speachythe voice buffer size shouldn't matter if it only loads what it needs
10:40:41speachysince individual voice strings haven't really changed
10:41:33_bilgusI backed off the dumping of the voice buffer to only < 1KB left and guess what it still returns -2
10:41:48speachyaha, so a red herring..
10:41:53speachybuffer fragmentation?
10:42:21_bilgusits supposed to compress and make contig what it can
10:42:28_bilgusbut maybe someone is stubborn
10:42:51speachystill, would be good to dump the buflib allocation state to see what's going on
10:43:31speachyother than your viewport rework I can't recall any major work to core functionality for some time
10:43:57speachyjust the incremental bloat of fixing bugs and feature additions
10:44:23_bilgusit could very well be that upping the memory pressure
10:44:33speachyoh!  since I made that audo_hard_stop() change in rolo I haven't had the x3 hang on rolo at all.
10:45:28speachy(except when I accidently loaded up an image with my WIP buffer realignment stuff in the FAT code)
10:45:49_bilgusI'm pretty sure the buf lib already has a sentinel plastered through it
10:45:53speachy(following the "it compiled therefore it must work" mentality)
10:49:26_bilgusspeachy do we have any older builds with voice files than whats up on rbdev?
10:50:08speachy_bilgus, IIRC each formal release had an english .voice that went along with it
10:50:29speachybut the infra only keeps one calendar month of dailies.
10:51:03_bilgusah ok so it'll be a slog to bisect
10:51:34speachyoh!  that reminds me −− you're using US Engrish?  Did you try the default English lang+voice?
10:51:58speachy(wondering if there's some sort of lingering issue caused from switching languages at startup)
10:51:58_bilgussadly if its a badly behaving existing bug that would solve nothing
10:52:17_bilgusthe us eng file doesn't work
10:52:25_bilgusit says wrong ver
10:52:47_bilgusbrit eng works and loaded at start through all
10:53:36speachydid you only try it on the clipzip, or does it also fail on the x3?
10:54:00speachy(meaning the english-us voice)
10:55:38_bilgusonly the clipzip I can try one of the others
10:58:57speachyI'm grabbing the dailies for the x3
11:00:43_bilgusrocker says: failed loading voice
11:01:05speachyx3 does it too.
11:02:14speachywtf.. when did this break?
11:09:19speachythe oldest daily breaks too
11:10:23speachy... which is one day after I rewrote the daily voice script to be parallelizable
11:12:37 Quit tomato (Quit: Ping timeout (120 seconds))
11:15:08speachythat's just the wrapper for the infra though; I built a new english-us just now and it's also failing, error 4
11:25:22speachyok, the expected/actual string IDs are wrong.
11:27:59_bilgushmm like how wrong?
11:28:43speachythis tells me the preprocessing pass that backfills missing strings is not working properly
11:29:11speachyid1 is 725 (expected 729), id2 is 130 (vs 131)
11:29:21 Quit Saijin_Naib (Read error: Connection reset by peer)
11:29:26_bilgusi thought that was done first for that reason
11:29:30speachycoincidentally english-us is missing 4 strings
11:32:57 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
11:41:20speachythe point where things broke appears to be the usb mode prompt
11:54:00 Join lebellium [0] (
12:04:47***Saving seen data "./dancer.seen"
12:09:06speachyfor some reason the language enum header isn't matching what genlang is generating.
12:10:09 Join ac_laptop [0] (~ac_laptop@
12:10:46speachyokay, the problem is in genlang.
12:16:04speachynope, I committed a bad english-us.
12:16:09speachyokay.  easy fix.
12:19:44braewoodsspeachy: sure, but not sure where to embed that.
12:20:29braewoodsspeachy: i tried embedding it in power history but it never got called
12:20:37fs-bluebotBuild Server message: New build round started. Revision 83111eeece, 293 builds, 9 clients.
12:21:01speachy_bilgus, this build will fix english-us voice generation.
12:21:39 Join Saijin_Naib [0] (
12:21:46speachygenlang should have handled this better but at the end of the day, it was bad data being fed into it.
12:23:14braewoodsoh wait
12:23:21braewoodspower history runs every minute
12:28:34speachyenglish-us has been broken since mid-november.  nice.
12:28:56speachyguess that shows how many folks actually used it.
12:30:07fs-bluebotBuild Server message: Build round completed after 570 seconds.
12:30:10fs-bluebotBuild Server message: Revision 83111eeece result: All green
12:37:58fs-bluebotBuild Server message: New build round started. Revision 0c958d2b4a, 293 builds, 8 clients.
12:38:39_bilguswell see by default they would use english gb
12:38:56_bilgusbut how many times was it downloaded?
12:40:20braewoods1, 2, 3, 3 downloads! uahahahaha
12:41:42braewoodsno idea
12:41:43 Quit ac_laptop (Ping timeout: 245 seconds)
12:42:02 Quit pamaury (Ping timeout: 264 seconds)
12:42:07speachyok, found a proper fix in the updatelang to compensate for this
12:42:16speachynow it'll get flagged properly
12:42:24braewoodscool, HID battery strength is working in my test build
12:43:33_bilgusI found my weird easily reproducible bug in announce_status I was deleting the wrong trackchange callback
12:47:50fs-bluebotBuild Server message: Build round completed after 593 seconds.
12:47:53fs-bluebotBuild Server message: Revision 0c958d2b4a result: All green
12:47:54fs-bluebotBuild Server message: New build round started. Revision bac897381c, 293 builds, 8 clients.
12:52:12_bilgusbraewoods, do you plan to integrate that with rbpatcher to show battery level?
12:52:28braewoods_bilgus: rbpatcher?
12:52:45braewoodswhat's that?
12:53:06_bilgusthe rb installer
12:53:21braewoodswhy would i need to support it in the installer?
12:53:48braewoodsright now my example just does this
12:54:06braewoodsi extend the hid driver so it can emit the battery strength reports
12:54:24braewoodsthen i add code to powermgmt.c so it will send those reports periodically as part of its thread code
12:54:49braewoodsif connected to usb those should always be sent
12:54:58braewoodsassuming hid is active
12:55:24_bilgusok maybe I misunderstand then who is your consumer on the pc side? the OS?
12:55:29braewoodsthe OS, yes
12:55:47braewoodsat least on Linux, the kernel consumes these reports to provide a battery device
12:55:53_bilgusad it will? show a battery level beside the device?
12:56:26braewoodsessentially, at least in the GUI for the DE
12:56:43braewoodswe might be able to send them to the installer as well?
12:56:51braewoodsthough i wouldn't know how
12:57:04braewoodsi mean, RB would have to be installed first
12:57:14_bilgusI think I remember seeing that in windows I didn't realize linux had it
12:57:29fs-bluebotBuild Server message: Build round completed after 575 seconds.
12:57:31braewoodsyes, it does, and there's multiple ways to achieve it over usb
12:57:31fs-bluebotBuild Server message: Revision bac897381c result: All green
12:57:48braewoodsHID Power is technically one but most would interpret that as a UPS which we ar enot
12:58:04braewoodswasn't sure it would work properly and is somewhat complex
12:58:05_bilgusI just figured you'd send it to the installer to decide if the battery level was too low and to display a meter next to a device
12:58:27braewoodswell, if the OS exposes it, the installer might be able to find it through host APIs
12:58:34braewoodson Linux it is definitely possible
12:58:51braewoodswe'll just have to see how this works out
12:59:09braewoodsi don't know enough about host APIs to know if Battery Strength is the best cross platform solution
12:59:11braewoodsright now
12:59:20braewoodsjust trying to keep it simple and get it working
12:59:44braewoodsthere was also the logitech protocol but that is tied to product and vendor IDS
12:59:48braewoodswhich i didn't want to tamper with
12:59:58braewoodsthe only standard method i found was battery strength
13:00:02braewoodsand obscure part of the HID spec
13:00:26braewoodsbut, devices CAN use it to report basic battery status
13:00:36braewoodsit's purely limited to a % report but that's enough
13:00:51braewoodsit works by having you define a range and send reports as a value in that range
13:00:58braewoodsthe % is derived from that
13:01:04braewoodsbut since we already work in percent
13:01:08braewoodsi made the range 0 to 100
13:01:57braewoods_bilgus: maybe we can use it but i'm not an expert in host APIs for this
13:02:11braewoodsjust getting the reports generated is a good place to start
13:03:35braewoods_bilgus: ^
13:07:33braewoodsthough it's weird
13:07:46braewoodsif the reports are right, my battery strength is decreasing while connected to USB
13:07:49braewoodswhat's up with that
13:11:03 Join J_Darnley [0] (
13:11:25braewoods_bilgus: can you test this on a windows host?
13:11:42 Quit jdarnley (Ping timeout: 260 seconds)
13:15:14_bilgusno I don't have one
13:15:28_bilgusand I haven't even set up a VM
13:22:10braewoodsok fair enough
13:22:14braewoodsi'll give it a spin later probably
13:22:19braewoodsi just don't have windows handy
13:22:28braewoodsor maybe speachy can do a test use
13:22:33braewoodsbut in any case
13:22:42braewoodsi'm kinda surprised this wasn't already implemented
13:22:57braewoodsit was available for over 20 years, though maybe not in the OS kernels
13:24:50braewoodsin any case though
13:25:10braewoodsif this works as expected we might be able to leverage it in rbutil, assuming that's what you meant?
13:25:33 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:26:42braewoodsonly helps if RB is already installed though so we can't rely on it to be present
13:26:51braewoodseven so
13:26:54braewoodswe can look for it
13:27:13braewoodsuse it if available but otherwise use old behavior
13:28:02braewoods_bilgus: just getting weird results. guess it's a side effect of the roller coaster that is the battery reporting stuff.
13:28:27braewoodsit dropped to 75% after being disconnected
13:28:35braewoodsreconnected it and it slowly rose to 83%
13:28:50braewoodsit was at 91% earlier and dropped to 83% after being connected
13:29:13braewoodsthe reporting is at least working correctly even if the internal battery data is a bit weird
13:31:14_bilgussounds about like the typical behavior
13:32:37braewoodsit won't be 100% accurate due to the simple nature of the protocol but it's probably the best option for RB
13:33:30braewoodsit's just funny to see upower says it is "discharging"
13:33:36braewoodswhen it's actually charging or so
13:36:37braewoodsupower report
13:37:18braewoodsit thinks it is a wireless keyboard battery or so
13:37:31braewoodsgood enough for me though
14:04:49***Saving seen data "./dancer.seen"
14:09:53 Quit pamaury (Ping timeout: 265 seconds)
14:22:52 Quit Saijin_Naib (Remote host closed the connection)
14:28:11speachybraewoods:  nice!
14:28:28braewoodsit was a lot simpler than i expected
14:28:39braewoodsat least to get a minimal reporting setup
14:28:50braewoodsif you want more detailed approach something more complex would have to be used
14:29:07braewoodsi do know though that HID Power has two disadvantages
14:29:23braewoodsmore complex and would require a second end point alongside regular HID
14:29:38braewoodsthis approach lets us just use the existing HID endpoint, conserving precious resources
14:30:52speachydo you know how upower comes up with that 'discharging' state?
14:31:35speachyor is it just "value went up[down] since the last one"?
14:31:51braewoodsspeachy: kernel report.
14:31:55braewoodslet me find the code.
14:32:26speachysince there doesn't seem to be anything in the HID definitions that let us indicate that
14:32:33braewoodsthere isn't
14:32:39braewoodsit only lets us report battery level
14:33:01braewoodshere it is
14:33:15braewoodsit is derived from the latest reported capacity
14:33:40braewoodsso it can only report full, discharging, or unknown
14:33:52speachyhmm, that's.. a little braindead.
14:34:09braewoodsit is, but that's common in Linux drivers when they don't have enough information.
14:34:20braewoodsthey have to fit the generic framework
14:34:34braewoodsand hid battery strength only reports the current level
14:35:22braewoodslogitech's protocol is more advanced but afaik only detected if we use logitech product ids
14:35:27speachyyeah, but by keeping aroudn the previous state you an at least tell if it's going up or down.
14:36:25braewoodsusually vendor extensions are gated to the vendor's products so
14:36:30braewoodswe'd have to pretend to be them to use them
14:37:00braewoodsthe only other way i know to report battery status is to use HID Power
14:37:18braewoodsbut, again, it uses a separate endpointer
14:37:28braewoodsand we might be confused for a UPS
14:37:30braewoodswhich we are ot
14:38:03braewoodslooking through upower, it considers HID Power to be a UPS if it uses the power device usage page
14:38:11braewoodsso we'd probably just implement the battery system usage page
14:38:24braewoodsspeachy: you want me to try to implement HID Power?
14:38:26braewoodsor is this enough?
14:38:33braewoodsHID Power would be more accurate
14:39:23braewoodsbut i think we should only have one of these methods
14:39:36braewoodsas they provide the same basic thing
14:40:45speachyI think this is plenty good
14:41:56braewoodsi still need to confirm how the other hosts interpret it
14:42:07braewoodsbut Linux reports it as a power supply under /sys
14:42:17braewoodswhich upower then picks up on
14:45:02 Join Saijin_Naib [0] (
14:45:06braewoodsspeachy: can you test it on a windows host?
14:45:20braewoodssee if the battery is even picked up
14:45:29speachyI only have a Win7 VM.
14:45:34braewoodsI see.
14:45:42braewoodsmaybe USB passthrough
14:45:44speachyand $dayjob Win10, but its USB is locked down.
14:46:04braewoodsin that case i'll do a test later
14:46:16braewoodsjust need to reinstall windows on a spare PC
14:46:16speachy(passthrough is fine, it's just that I don't have much faith in Win7 picking it up)
14:46:27braewoodsif it doesn't then it doesn't
14:46:32braewoodsmain concern i had was windows 10
14:51:21braewoodsspeachy: once this is merged I was hoping to change charging_only mode to enable HID as well but only send our battery reports in this mode
14:51:50braewoodsthat seems to work since our HID driver only sends reports when prompted by other parts of RB
14:52:09speachyit's a good idea in principle; in practice it may be a lot trickier −− IIRC chargeonly doesn't export _any_ endpoints.
14:52:27speachyyou may have to contend with individual target usb drivers
14:52:30braewoodsindeed it doesn't; perhaps we can just make that mode only enable HID driver
14:52:51speachybut yes, that is a good natural progression
14:52:53braewoodsin any case we do need to develop a way to selectively enable them due to endpoint limits
14:53:12braewoodsjust wasn't a problem before to a limited number of drivers
14:53:17braewoodsbut with me eventually adding MTP
14:53:25braewoodsa complex project for another day
14:53:35braewoodswe will need to revisit how we select the drivers to use
15:09:44 Quit TheLemonMan (Read error: Connection reset by peer)
15:10:09 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
15:13:07DEBUGReceived signal 15 (SIGTERM), terminating (snapshot: transfer.c line 304)
15:13:07***Saving seen data "./dancer.seen"
15:17:50***Started Dancer V4.16
15:17:50***Connected to on port 6667
15:17:50***Logfile for #rockbox started
15:17:54Mode"logbot :+Ri" by logbot
15:18:00***Server message 501: 'logbot :Unknown MODE flag'
15:18:01 Join logbot [0] (
15:18:01 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
15:18:01 Join Saijin_Naib [0] (
15:18:01 Join J_Darnley [0] (
15:18:01 Join lebellium [0] (
15:18:01 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
15:18:01 Join speachy [0] (40eebded@
15:18:01 Join TorC [0] (~Tor@fsf/member/TorC)
15:18:01 Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen)
15:18:01 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
15:18:01 Join f1refly [0] (
15:18:01 Join kadoban [0] (kadobanemp@gateway/shell/
15:18:01 Join mud [0] (kadobanmat@gateway/shell/
15:18:01 Join ccf-100 [0] (ccf-100mat@gateway/shell/
15:18:01 Join danielp3344 [0] (danielp334@gateway/shell/
15:18:01 Join mendel_munkis [0] (
15:18:01 Join fauweh [0] (
15:18:01 Join aevin [0] (eivindsy@unaffiliated/aevin)
15:18:01 Join XDjackieXD [0] (
15:18:01 Join Acou_Bass [0] (
15:18:01 Join Galois [0] (
15:18:01 Join Soap_ [0] (~Soap@rockbox/staff/soap)
15:18:01 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
15:18:01 Join atsampson [0] (
15:18:01 Join ParkerR [0] (ParkerR@unaffiliated/parkerr)
15:18:01 Join rudi_s [0] (
15:18:01 Join prg3 [0] (~prg@deadcodersociety/prg318)
15:18:01 Join Strife89 [0] (
15:18:01 Join spectrumanalyst [0] (~admin@
15:18:01 Join skrzyp [0] (
15:18:01 Join St3ak [0] (
15:18:01 Join pixelma [0] (marianne@rockbox/staff/pixelma)
15:18:01 Join amiconn [0] (jens@rockbox/developer/amiconn)
15:18:01 Join rasher [0] (~rasher@rockbox/developer/rasher)
15:18:01 Join copper [0] (~copper@unaffiliated/copper)
15:18:01 Join nast [0] (~nast@
15:18:01 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
15:18:01 Join daswf852 [0] (~daswf852@unaffiliated/dwf)
15:18:01 Join Tsesarevich [0] (sid83162@fluxbuntu/founder/joejaxx)
15:18:01 Join fs-bluebot [0] (
15:18:01 Join Romster [0] (~romster@unaffiliated/romster)
15:18:01 Join CR0W [0] (~narf@unaffiliated/em64t)
15:18:01 Join xcin [0] (~x@
15:18:01 Join mikroflops [0] (
15:18:01 Join toruvinn [0] (
15:18:01 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57)
15:18:01 Join ufdm [0] (
15:18:01 Join paulk-leonov [0] (
15:18:01 Join tchan [0] (~tchan@lunar-linux/developer/tchan)
15:18:01 Join trfl [0] (
15:18:01 Join Topy44 [0] (
15:18:01 Join shapeless [0] (shapeless@2001:41d0:401:3100::8a33)
15:18:01 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3)
15:18:01 Join jerwin [0] (~flippy-fl@unaffiliated/flippy)
15:18:01 Join klock [0] (~freeklock@unaffiliated/klock)
15:18:01 Join igitoor [0] (igitur@unaffiliated/contempt)
15:18:01 Join Lonoxmont [0] (
15:18:01 Join Moarc [0] (
15:18:01 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
15:18:01 Join M-iam-some0nee[m [0] (m-iam-some@gateway/shell/
15:18:01 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
15:18:01 Join KalBot1 [0] (
15:18:01 Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri)
15:18:01 Join plum [0] (~plum@unaffiliated/plum)
15:18:01 Join JanC [0] (~janc@lugwv/member/JanC)
15:18:01 Join melmothX [0] (~marco@unaffiliated/melmothx)
15:18:01 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567)
15:18:01 Join Natch [0] (
15:18:01 Join olspookishmagus [0] (
15:18:01 Join APLU [0] (
15:18:01 Join Rondom [0] (
15:18:01 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
15:18:01 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
15:18:01 Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods)
15:18:01 Join alexbobp [0] (
15:18:01 Join emacsoma1 [0] (
15:18:01 Join bleb [0] (~cm@unaffiliated/bleb)
15:18:01 Join bzed [0] (
15:18:01 Join asabas [0] (~asaba@
15:18:01 Join kirvesAxe [0] (
15:18:01 Join msc68 [0] (~quassel@
15:18:01 Join berber [0] (
15:18:01 Join lemon_jesus [0] (~lemon_jes@
15:18:01 Join benedikt93_ [0] (~quassel@unaffiliated/benedikt93)
15:18:01 Join __builtin [0] (~quassel@rockbox/developer/builtin)
15:18:01 Join k1w1 [0] (~k1w1@unaffiliated/k1w1)
15:18:01 Join Xeha [0] (~Xeha@unaffiliated/xeha)
15:18:01 Join hook54321 [0] (sid149355@gateway/web/
15:18:01 Join beencubed [0] (~beencubed@
15:18:01 Join ecs [0] (
15:18:01 Join RafiX [0] (
15:18:01 Join yosafbridge [0] (
15:18:01 Join Skyrider [0] (
15:18:01 Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549)
15:18:01 Join CommunistWitchDr [0] (
15:18:01 Join funman [0] (~fun@rockbox/developer/funman)
15:18:01 Join @ChanServ [0] (ChanServ@services.)
15:18:01 Join vup [0] (~~~~@
15:18:01 Join SammysHP [0] (
15:18:01 Join ps-auxw [0] (
15:18:01 Join kugel_ [0] (~kugel@rockbox/developer/kugel)
15:18:01 Join michaelni [0] (
15:18:01 Join Barlow [0] (~barlow@unaffiliated/barlow)
15:18:01 Join shrizza [0] (
15:18:01 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
15:18:01 Join gsora [0] (~gsora@unaffiliated/gsora)
15:18:01 Join dys [0] (
15:18:01 Join _bilgus [0] (
15:18:01 Join rogeliodh [0] (
15:18:01 Join user890104 [0] (
15:45:26 Quit jschwart (Ping timeout: 240 seconds)
15:52:08 Join bonfire [0] (
15:54:16 Join jschwart [0] (
16:10:34 Join jdarnley [0] (
16:12:33 Quit J_Darnley (Ping timeout: 264 seconds)
16:16:23 Quit speachy (Quit: Connection closed)
16:50:21braewoods_bilgus: did you ever find that supplemental manual for the JZ4760B?
16:56:25 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:05:18 Quit pamaury (Quit: No Ping reply in 180 seconds.)
17:06:35 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:09:09 Quit pamaury (Read error: Connection reset by peer)
17:11:47 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:17:54***Saving seen data "./dancer.seen"
17:29:44 Join ac_laptop [0] (~ac_laptop@
17:32:08 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
17:38:23_bilgusbraewoods, no unfortunately not
17:48:42braewoods_bilgus: what would it do for the RB ports?
17:48:51 Quit pamaury (Ping timeout: 272 seconds)
17:49:13braewoodsit's strange that it wasn't part of the vendor's public docs
17:55:16 Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257)
17:56:30_bilgusI think it covers dma and a few other things
17:57:03braewoodsi PMed someone i know that might be able to help but i haven't seen them active on IRC in awhile
17:57:28braewoodsone of the few times i wish we knew someone from China =p
18:12:48 Quit lebellium (Quit: Leaving)
18:15:05 Quit Saijin_Naib (Disconnected by services)
18:15:09 Join Saijin-Naib [0] (
18:29:39 Quit Huntereb (Read error: Connection reset by peer)
18:31:39 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7::69)
18:33:47 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
18:41:55 Quit Saijin-Naib (Ping timeout: 240 seconds)
19:08:39 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
19:17:58***Saving seen data "./dancer.seen"
19:18:09 Quit pamaury (Ping timeout: 272 seconds)
19:28:20 Quit Huntereb (Read error: Connection reset by peer)
19:30:52 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7::69)
19:33:02 Quit Huntereb (Read error: Connection reset by peer)
19:36:09 Join Huntereb [0] (
19:38:00 Quit Huntereb (Read error: Connection reset by peer)
19:41:24 Join Huntereb [0] (
20:04:08 Join speachy [0] (~speachy@
20:16:57 Join massiveH [0] (
20:29:38 Quit Huntereb (Ping timeout: 245 seconds)
20:32:59 Join Huntereb [0] (
20:34:51 Quit Huntereb (Read error: Connection reset by peer)
20:36:48 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57)
20:44:43 Quit Huntereb (Read error: Connection reset by peer)
20:44:56 Join Huntereb [0] (
21:14:31fs-bluebotBuild Server message: New build round started. Revision 9cf45374e0, 293 builds, 9 clients.
21:18:01***Saving seen data "./dancer.seen"
21:24:29fs-bluebotBuild Server message: Build round completed after 598 seconds.
21:24:33fs-bluebotBuild Server message: Revision 9cf45374e0 result: All green
21:26:48speachyI'm liking these 10min builds
21:33:11braewoodsspeachy: care to review the hid battery stuff?
21:33:30braewoodsor were you waiting for something eles
21:34:58speachywhat have you built it on?
21:44:16speachycleanly builds for simulators etc?
21:44:47braewoodsspeachy: just the sansafuzeplus
21:44:59braewoodsspeachy: i don't have anything setup to build so much at once
21:45:06braewoodsbut pretty sure it won't fail to build
21:45:18braewoodsi gated the HID stuff with the macro used to enable it
21:47:22braewoodsthe rest isn't gated and compiles for the sansafuzeplus just fine
21:47:26braewoodsso it should work
21:47:33braewoodsthe parts i added to the HID driver anyway
21:47:46braewoodsi figured powermgmt.c is only one that needed conditional compilation stuff
22:09:34braewoodsspeachy: adjusted
22:16:13speachyhmm. I think every second might be too often.
22:17:04braewoodsspeachy: how often should we send it then?
22:17:35braewoodsand we should send at least one upon initial connection
22:17:58 Quit ac_laptop (Ping timeout: 245 seconds)
22:18:00braewoodsso the host has some data and doesn't have to wait for first update
22:18:44speachysend the first timeout to be 1s but the subsequent ones can wait every 60s maybe?
22:18:51braewoodsspeachy: how about this then, we don't use ticks, just send updates when battery level change?
22:19:07braewoodsspeachy: well that's the thing, this tries to send regardless of usb connection status so
22:19:30braewoodsit's fine if done on a timer but the first update should probably be tied to the insertion event
22:19:40braewoodsif that makes sense
22:19:57braewoodswe could also makes the updates only sent out if the battery_level has changed
22:19:59speachyactually that's better, as long as we send out the first one (relatively) immediately.
22:20:00braewoodsor a timer
22:20:40speachymakes sense to update it as the charge changes, yeah. no more than once a minute.
22:21:24braewoodsi could scale back the current WIP to just have the hid driver changes
22:21:33braewoodsi could then work on the update process separately
22:22:25speachyif (usb_detect() == USB_INSERTED)
22:29:36speachyadd a function into powermgmt.c along the lines of enable_hid_battery_reporting(timeout) −− it sets the timer to be every N ticks, or 0 disables.
22:30:33speachythen in usb_hid_init() call enable_hid_battery_reporting(60), and in usb_hid_disconnect() call enab_hid_Battery_reporting(0)
22:30:33braewoodsfor what purpose? so it can be configured?
22:30:58speachyso it's tied to the hid driver, only firing when we have an active hid endpoint
22:31:36speachyand next_battery_strength would be initialized to 0.
22:32:11speachyand enable_hid_battery_reporting would set the initial timeout to 1 so it fires immediately.
22:32:17speachyif any of that makes sense
22:32:21 Join f1reflyylmao [0] (~f1refly@2a01:c22:907d:7a00:56e6:5d8a:23e6:b397)
22:32:51braewoodsi suppose so, but isn't usb_hid_init the wrong place to do that? that fires even if the driver is not used
22:33:23speachyI mean usb_hid_init_connection()
22:33:23braewoodssee usb_core_init and the comment
22:34:13 Quit f1refly (Ping timeout: 245 seconds)
22:34:14 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:907d:7a00:56e6:5d8a:23e6:b397)
22:35:13speachyI think 60s is a reasonable update interval since the battery level doesn't change _that_ quickly... alternatively you could change powermgmt.c to make it only emit upon changes
22:35:52braewoodswe can also make the frequency configurable at a later date
22:35:55speachyactually I like that better; screw the periodic tick. :)
22:36:22braewoodsi'll still need a way to send them immediately upon first insertion...
22:36:40braewoodsi can do that in powermgmt.c if i monitor usb changes there but still
22:36:46braewoodsi know what i'll do.
22:36:57speachyenable_hid_Battery_reporting(true) will trigger an immediate message
22:37:44braewoodsin any case
22:37:46braewoodsback to work on it
22:56:44braewoodsspeachy: implemented
22:59:14speachyyou can set battery_report_percent to -1 in set_battery_reporting() which will make (battery_report_percent == -1) superfluous. as battery_percent will never == -1
22:59:45speachyand the entire else (!battery_reporting) block
23:00:33speachysimplifies the code a bit
23:00:36braewoodsit'll become a global variable then
23:00:42braewoodssince i can't do that otherwise
23:01:12speachyit's in ram anyway
23:02:39speachyoh, move set_battery_Reporting(false) to immediately after the logf()
23:04:26braewoodsnot sure why it matters
23:04:28braewoodsbut ok
23:04:54speachyslightly racy −− you could conceivably have the HID start flight after the active=false etc
23:05:36braewoodsis that a problem? usb_hid_send doesn't send anything if the driver is inactive
23:05:44speachyjsut good practice to have the deinit() be the inverse order of your init()
23:06:15braewoodsbut ok
23:06:28braewoodsso uh
23:06:53speachyand I think I'll be done picking on your code
23:07:07speachyand beating it up for its lunch money
23:08:46braewoodshere it goes
23:10:38braewoodsi removed part of the code since your proposals made it irrelevant
23:10:54braewoodsi had a boolean set aside to push an update later since my logic was more involved
23:11:01braewoodsbut with it no longer being needed
23:11:06braewoodsmade sense to just merge the branches
23:11:39speachystill works? :D
23:14:38speachygood on the x3
23:15:04fs-bluebotBuild Server message: New build round started. Revision f647cde3c7, 293 builds, 9 clients.
23:15:58speachybraewoods: awesome little feature addition
23:17:44braewoodsspeachy: _bilgus wondered if it could be used by rbutils, but... why?
23:18:03***Saving seen data "./dancer.seen"
23:18:11braewoodsmaking sure there's enough battery to upgrade rockbox?
23:18:17speachyreport the device status, but I don't think we're able to get that info easily via windows at least.
23:18:29braewoodsit's easy on linux
23:18:32braewoodswe can probe /sys
23:18:40speachy(or macos, even..)
23:19:15braewoodswell it would be a way to verify that RB is installed correctly
23:19:18braewoodsand booting
23:24:06speachyit cna check that via the iManufacturer/iModel USB descriptors
23:24:25speachy(well, assuming rockbox is _running_ when it's plugged in...)
23:26:49fs-bluebotBuild Server message: Build round completed after 705 seconds.
23:26:59fs-bluebotBuild Server message: Revision f647cde3c7 result: All green
23:28:37braewoodsspeachy: so i found a battery with a thermistor for my hdd1630... it's labeled as 510mah, and the spec sheet says the battery current is 450 mah...
23:28:45braewoodswill there be problems when i charge it?
23:29:02braewoodscharging current*
23:29:04speachythe thermistor is going to be on a separate wire
23:29:10braewoodsindeed it is
23:29:15speachyso it doesn't matter
23:29:36braewoodsthe chip docs says it reduces charging current in response to thermal changes
23:30:09speachyif the charger doesn't hook up to the thermistor, then it's moot, unless the battery itself has protection circits
23:30:29 Quit ufdm (Ping timeout: 245 seconds)
23:30:49speachysweet, my FAT-layer realignment code no longer hangs the player outright.
23:31:25braewoodsspeachy: great. i'm going to work on MTP next probably.
23:31:42braewoodsabout time to get serious with that
23:31:53braewoodsjust this seemed an easy thing to get implemented
23:32:01braewoodsand most players can use it
23:32:07braewoodsprovided they already had HID support
23:37:51speachymost of the native targets do.
23:38:28speachyanyway, bedtime for the wicked. have a good rest-of-your-day!

Previous day | Next day