--- Log for 10.10.124 Server: osmium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 1 month and 17 days ago 01.45.03 *** No seen item changed, no save performed. 02.19.20 Quit spork (Quit: leaving) 02.53.39 # <__builtin> speachy: you can't decode in chunks and scale on the fly? 02.53.47 # <__builtin> (also, hello.) 02.53.52 Join spork [0] (topic@77-164-207-8.fixed.kpn.net) 03.28.10 # speachy That's what progressive JPEG is all about, afaik you can stop decoding when your resolution is "good enough" 03.28.13 # https://stackoverflow.com/questions/33539225/prevent-progressive-jpeg-from-loading-completely 03.29.25 # Most of the Rockbox devices have small resolution screen, so even the first pass could be "good enough". Higher resolution devices also tend to have higher memory and processing power. 03.45.05 *** Saving seen data "./dancer.seen" 03.51.51 Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) 05.04.18 Quit jacobk (Ping timeout: 248 seconds) 05.04.53 Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) 05.45.10 *** Saving seen data "./dancer.seen" 06.11.33 Quit PheralSparky (Read error: Connection reset by peer) 07.18.03 Quit cnx (Ping timeout: 252 seconds) 07.26.14 Join cnx [0] (~cnx@tem.loang.net) 07.45.14 *** Saving seen data "./dancer.seen" 07.52.38 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 07.53.51 # edhelas_: It doens't work terribly well in practice. Even Apple's pictureflow stuff relied on pre-scaled stuff. 07.55.03 # "higher resolution devices" refers to stuff that's not a microcontroller-based DAP. 07.55.55 # and that patch throws out the existant scaling for non-progressive images, which also makes it a nonstarter. 07.59.23 # __builtin: you described the status quo; taking advantage of joeg's 8x8 block size. 08.00.30 # IIRC progressive decoding has each pass buildong on the other; ie if you scale as you go, latter passes won't work properly. 08.04.55 # if the first pass is "good enough" then great, but things fall apart otherwise. 08.07.18 # (as for PNG, we'd have to essentially write our own scanline-oriended decoder. Not impossible, but we're not exactly swimming in developers) 08.09.11 # (Though IIRC the main problem with PNG is its use of gzip compression that doesn't do so well with strict constraints on memory use) 09.15.57 Join dconrad [0] (~dconrad@152.117.104.217) 09.18.40 # speachy: yeah I saw that erosq_2024, kinda works out to give us some safety for our bootloader update file 09.19.21 # I hope to find some time this weekend to decompile this new update file... it's been a while since the first time so it'll be good practice :D 09.21.18 # Not sure if they changed power management chip or just moved some wires around on gpios or what... 09.21.55 # it's pretty surprising they changed the linux battery reporting as well 09.22.53 Join dys [0] (~dys@user/dys) 09.35.52 # yeah.. I wonder if they rebvased to a newer kernel release or something? seems like a fairly gratitutious change to rename 'battery' to 'axp_battery' 09.36.17 # still 3.10.14 09.36.53 # I'll get that change into the hosted port and we'll see what else breaks 09.37.26 # (I half expect the ALSA controls to be renamed or something..) 09.39.43 # axp_battery is good though, they're still using axpXXX 09.45.17 *** No seen item changed, no save performed. 09.48.22 # any specifics (lcd, axp version, dac, x1000[E/NoE]) we can learn from adb? 09.50.05 # I don't know offhand; it's been a while. 09.50.41 # (could ask for the usual assortment; dmesg, alsactl dump, etc..) 09.51.11 # ah 09.55.22 # bbiab 09.55.23 Quit speachy (Quit: WeeChat 4.4.2) 10.04.08 Join speachy [0] (~speachy@rockbox/developer/speachy) 10.04.08 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 10.14.05 # Build Server message: 3New build round started. Revision edbcf0b0f4, 345 builds, 10 clients. 10.14.05 # 3erosq: Initial PM support for "hw4" variant by Solomon Peachy 10.19.27 # ... the cynical side of me wonders if this is someone spinning new changes just to seem busy to their boss... I can respect that 10.19.53 # it's annoying, but I can respect it haha 10.20.18 # hopefully I didn't break existing players with that. :D 10.20.44 # don't worry, you'll know haha 10.23.18 # need to un-bury my v1 hardware from the bottom of my rockbox box 10.34.40 Quit dconrad (Remote host closed the connection) 10.34.45 # Build Server message: 3Build round completed after 1241 seconds. 10.34.47 # Build Server message: 3Revision edbcf0b0f4 result: All green 10.58.02 # dconrad: I doubt they'd revise the PCB just to appear busy. :D 11.05.03 # money 11.05.12 # costs less money do do nothing 11.05.32 # not if you can source cheaper parts or have run out of stock and cannot source the original 11.07.03 # of course, but that's not "appear busy" work 11.10.08 # true 11.45.20 *** Saving seen data "./dancer.seen" 11.58.54 Quit braewoods (Read error: Connection reset by peer) 11.59.03 Join braewoods_ [0] (~braewoods@user/braewoods) 12.02.38 Quit _bilgus (Remote host closed the connection) 12.02.49 Quit Trzyzet (Quit: The Lounge - https://thelounge.chat) 12.03.06 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 12.03.46 Join _bilgus [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) 12.04.56 Quit Trzyzet (Client Quit) 12.05.12 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 12.07.36 Quit Trzyzet (Client Quit) 12.08.48 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 12.39.43 Quit Trzyzet (Quit: The Lounge - https://thelounge.chat) 12.41.34 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 12.46.46 Quit Trzyzet (Quit: The Lounge - https://thelounge.chat) 12.47.34 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 13.01.13 Join lebellium [0] (~lebellium@2a01cb0405d07f0035f3c8468153dc53.ipv6.abo.wanadoo.fr) 13.02.35 # dconrad: at least with the AXP20x vs AXP192 we should be able to detect the difference at runtime. :) 13.04.23 # might be able to save some juice too by turning off HP/LO when they're not plugged. 13.05.03 # (I only have a rev1 hw, I'm curious what rev2 shows) 13.07.08 # hmm, hosted port should use the HW volume instead of SW volume on v2+. 13.08.19 Join dconrad_ph [0] (~dconrad_p@108.147.197.72) 13.09.21 # speachy: interesting, I was under the impression the hosted port always did its own volume scaling rather than calling alsa's volume adjustment 13.10.29 # depends on the DAC that was used. the other hibyos targets use hw controls, the sony targets are all sw... 13.14.29 # well I can get a dmesg output sometime from my player, I'll just have to put the hosted bl on it as well 13.16.40 Quit dconrad_ph (Quit: Client closed) 13.31.23 # now have a patch that uses HW volume control on the v2+ devices. 13.37.57 Join dconrad_ph [0] (~dconrad_p@205.237.113.8) 13.38.31 # rev1 doesn't log gpios like rev4 does 13.38.59 # well for all the work its been, my one big complaint with the hosted was not having hwvol... it certainly is easier to maintain the hosted... 13.39.56 # i think that was the whole reason to do the native port haha 13.42.18 # AXP192/20x are on the same i2c address, and report ID 0x03 and 0x4a, respectively. 13.42.34 # oh thats nice 13.45.05 # can't find corrobating info 13.45.23 *** Saving seen data "./dancer.seen" 13.49.16 # hmm. 13.58.14 Quit dconrad_ph (Quit: Client closed) 13.58.56 Join dconrad_ph [0] (~dconrad_p@205.237.113.8) 14.00.13 # so g#5963 is there for anyone wanting to try it 14.00.16 # 3Gerrit review #5963 at https://gerrit.rockbox.org/r/c/rockbox/+/5963 : 3erosqhosted: Support HW volume control on rev2 hardware by Solomon Peachy 14.01.00 # it doesn't regress on rev1 hardware 14.06.06 # I can try that in the next couple days, is there a debug menu readout for which system it detected? 14.06.34 # nope! :D 14.10.12 # haha well that should be pretty easy to add I think 14.10.40 # so with this I know how to distinguish between rev1, rev2/3 and rev4. 14.10.59 # amazing! 14.11.11 # only indirectly, of course. 14.11.37 Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) 14.15.56 # ...If I order a new F20 from Amazon now, will I get a v3.4 player? Ugh. 14.16.07 Quit dconrad_ph (Ping timeout: 256 seconds) 14.16.51 Join dconrad_ph [0] (~dconrad_p@205.237.113.8) 14.17.13 # I was wondering the same thing myself tbh 14.25.27 # would be nice to be able to tell the difference between v2/v3 as well. 14.25.54 # (I don't think anyone shared a dmesg dump that showed the display info) 14.48.00 Quit dconrad_ph (Quit: Client closed) 15.15.13 Join dconrad_ph [0] (~dconrad_p@205.237.113.8) 15.15.14 Quit dconrad_ph (Client Quit) 15.24.06 Quit jacobk (Ping timeout: 276 seconds) 15.24.20 Join jacobk_ [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) 15.45.24 *** Saving seen data "./dancer.seen" 16.26.30 Quit jacobk_ (Ping timeout: 276 seconds) 17.00.21 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) 17.45.28 *** Saving seen data "./dancer.seen" 17.54.16 Quit lebellium (Quit: Leaving) 18.11.40 Join dconrad [0] (~dconrad@152.117.104.217) 18.13.45 # with how easy it was to add support for the hw4 erosq, I am starting to question whether the effort to maintain the native port is worth it... 18.14.22 # I might take a second look at the hosted port if that hwvol works as intended 18.14.34 # fighting sunk cost fallacy hard here 18.16.46 # but first, I'll get that dmesg etc. output 18.19.49 # the hosted port is not that great; we only have access to about 1/4 of the RAM, the UI performance is sluggish, boot times are crappy.. 18.21.08 # ah, I thought it was on par 18.21.22 # performance-wise 18.21.35 # maybe it is worth it 18.22.14 # raw oomph it's roughly equivalent (really, a 1ghz mips core hides a lot of sins) but there's a lot of overhead due to linux itself plus the non-optimized underlying platform drivers. 18.22.28 # I see 18.22.46 # granted, we get some nice things (ntfs, exfat, bluetooth in theory, floating point codecs) 18.24.12 # Maybe these dmesg etc. outputs would be good to attach to the wiki page 18.24.13 # but the userspace platform is postively ancient, and while there's definitely some paths to better optimization we'd have to write a new threading layer first. 18.25.19 # (that would give us true multithreading, allow use of a blocking ALSA API that would enable passing audio to the BT layer, not get blocked on the slow UI updates, etc etc. 18.25.39 # (would also eat into our already-limited RAM headroom) 18.26.28 # re dmesg and alsa dumps, yes. 18.26.29 # any other adb stuff you're interested in on the v2 player? I've got it open and running right now 18.26.48 # I got dmesg and "amixer contents" 18.27.06 # that's what comes to mind. 18.27.58 # alright, it's easy to do if any other info is needed 18.28.22 # I'll put it up on the wiki 18.28.35 # thank you 18.29.33 # tbh I also want to do a native port to the xduoo x3ii, but I don't relish the prospect of REing how it's put together given that I may end up being the only one to use it. 18.31.29 # I'll take a look later tonight to see what I can glean from those dumps. 18.38.30 # I'm also thinking about pulling the trigger on a hw4 unit (or, more accurately, pulling the trigger on rolling the dice to get a hw4 unit) 18.48.40 # well it looks like if they took the time to remove networking stuff etc. from the linux kernel it could be /so/ much leaner 18.54.17 # I still dream of having usb-dac mode in rockbox... I was just thinking of that recently. It could be a plugin, but I suspect decoupling a plugin to allow it to do its own usb thing might be a struggle 18.54.56 # a personal usb dsp box, if you will 19.17.45 Quit dconrad (Remote host closed the connection) 19.29.08 Join dconrad [0] (~dconrad@152.117.104.217) 19.38.02 Quit dconrad () 19.45.32 *** Saving seen data "./dancer.seen" 19.49.01 Join massiveH [0] (~massiveH@2600:4040:a982:dc00:c2c:fc6c:960e:54c5) 21.39.35 Join jacobk [0] (~quassel@129.110.242.224) 21.44.04 Quit jacobk (Ping timeout: 260 seconds) 21.45.19 Join jacobk [0] (~quassel@129.110.242.173) 21.45.34 *** Saving seen data "./dancer.seen" 21.51.39 Quit jacobk (Ping timeout: 260 seconds) 21.54.04 Join jacobk [0] (~quassel@utdpat242024.utdallas.edu) 22.06.27 Quit jacobk (Ping timeout: 276 seconds) 22.11.14 Quit Moriar (Quit: Leaving.) 22.50.03 Join decky_e [0] (~decky_@69.9.139.14) 23.02.42 Quit massiveH (Quit: Leaving) 23.38.05 Join decky [0] (~decky_@69.9.139.14) 23.39.07 Quit Natch (Read error: Connection reset by peer) 23.39.46 Quit sam_d (Quit: Bye) 23.39.55 Quit wLLm (Remote host closed the connection) 23.39.58 Quit Bobathan_ (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) 23.40.13 Join wLLm [0] (~wLLm@wllm.connected.by.freedominter.net) 23.40.54 Quit jj5 (Remote host closed the connection) 23.41.19 Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) 23.41.47 Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) 23.41.50 Quit decky_e (Ping timeout: 252 seconds) 23.42.32 Join sam_d [0] (~sam@user/sam-d/x-8933526) 23.44.02 Quit dys (Ping timeout: 252 seconds) 23.44.02 Quit baltazar (Ping timeout: 252 seconds) 23.45.38 *** Saving seen data "./dancer.seen" 23.49.52 Join Natch [0] (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se)