--- Log for 15.07.120 Server: tolkien.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 13 hours and 50 minutes ago 00.07.07 # Nope, attempting to build gcc 4.5.2 quits for the same reason 00.07.47 # c'est la vie 00.17.00 *** Saving seen data "./dancer.seen" 00.33.51 Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net) 00.57.54 Quit reductum (Quit: WeeChat 2.8) 01.22.30 Join __Bilgus_ [0] (41ba23be@65.186.35.190) 01.22.46 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 01.26.06 # <__Bilgus_> RasPI; I had pretty good luck booting from the sdcard with a RO FS w/ Berryboot then the OS runs off a large format SD Card its been fine for going on 2 or 3 years now 01.26.59 Quit ZincAlloy (Ping timeout: 240 seconds) 01.29.19 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 01.31.53 # <__Bilgus_> g#2534 would be better off in a plugin especially with voices in plugins 01.31.54 # Gerrit review #2534 at http://gerrit.rockbox.org/r/2534 : FS#11541 - Add Voice Announcement of Summary Info to WPS hotkey options by Igor B. Poretsky 01.37.25 Quit ubervison (Ping timeout: 272 seconds) 01.38.17 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:491e:90a8:a8d3:55d5) 01.43.07 Quit ZincAlloy (Ping timeout: 272 seconds) 01.52.45 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 01.53.22 # Does rb have any meaningful support for touchscreen at all? Most X1000[E] targets right now are touchscreen devices without meaningful hardware buttons (other than volume and power I guess). 01.57.22 Quit ZincAlloy (Ping timeout: 256 seconds) 02.15.29 # <__Bilgus_> efqw there are settings to allow button emulation by zone for some players 02.16.57 # <__Bilgus_> like touch on right side = right arrow key press 02.17.04 *** Saving seen data "./dancer.seen" 02.17.04 # I've read about it on the wiki but the TouchscreenInterface page was last updated 10 years ago :P 03.21.49 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 04.17.07 *** No seen item changed, no save performed. 04.51.44 Quit ac_laptop (Ping timeout: 258 seconds) 04.52.50 Quit gevaerts (Ping timeout: 272 seconds) 05.02.46 Quit mendelmunkis (Ping timeout: 265 seconds) 05.04.17 Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net) 06.17.11 *** Saving seen data "./dancer.seen" 06.36.23 Join miner49er [0] (5cec5d32@92.236.93.50) 06.36.54 # Hi there people! Can I ask a question regarding getting an SDL build of Rockbox on the Pocket Go? 06.38.59 # Well, I'll try anyway: My build is having problem loading codecs. 06.39.10 # It's failing with SDL error "Dynamic loading not supported" 06.39.31 # Would my theory that the building of SDL on my device simply doesn't have this function implemented? 07.00.52 Join vmx [0] (~vmx@ip5f5ac60f.dynamic.kabel-deutschland.de) 07.05.34 Quit __Bilgus_ (Remote host closed the connection) 08.02.06 Quit miner49er (Remote host closed the connection) 08.09.09 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:8982:4653:148b:9d8e) 08.10.54 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 08.17.14 *** Saving seen data "./dancer.seen" 08.54.14 Join massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net) 09.03.17 Quit MrZeus (Ping timeout: 272 seconds) 09.16.17 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 09.29.05 Join petur [0] (~petur@199.59.5.111) 09.29.05 Quit petur (Changing host) 09.29.06 Join petur [0] (~petur@rockbox/developer/petur) 09.29.23 # Build Server message: New build round started. Revision 8577d5a, 295 builds, 12 clients. 09.34.07 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be) 09.34.33 Join __Bilgus_ [0] (41ba23be@65.186.35.190) 09.35.47 Quit J_Darnley (Ping timeout: 258 seconds) 09.37.06 Join miner49er [0] (5cec5d32@92.236.93.50) 09.43.08 # __Bilgus_, I know next to nothing of how plugins get invoked; is it realistic/feasible to have a plugin launched from within the wps that just speaks without pausing the wps while the voice is still going? 09.44.14 # efqw, there's no "real" touchscreen support, as in treating it as a mouse-like absolute pointer 09.44.40 # <__Bilgus_> I believe so yes with the caveat that it be run as TSR as to not have to handle dealing with the WPS 09.45.50 # efqw plus the entire UI stack has no provisions for non-button-based navigation. so no point-n-click, so to speak. 09.46.34 # <__Bilgus_> give me a few days and I'll try to work out a template or at least some POC 09.49.12 # <__Bilgus_> I have had lua running TSR as an experiment at one point so I'm at least passingly (more by the day) familar with the TSR stuff 09.49.39 # oh, __Bilgus_, I dusted off g#1932 for benchmarks on the mini2g 09.49.41 # Gerrit review #1932 at http://gerrit.rockbox.org/r/1932 : opus: shrink stack usage by nearly 700 bytes by Solomon Peachy 09.52.06 # <__Bilgus_> that was just moving the structures around right? something was out of iRam on a particular target was that the mini? 09.52.15 # still have no way of running it on the worst-case coldfires. a while back you fixed the giant stack-sucking seeking-related overflow/crash. 09.53.14 # __Bilgus_: what's TSR? 09.53.32 # <__Bilgus_> Personally I'd just do the patch and make sure its easily revert-able in case complaints take a year to surface 09.53.45 # <__Bilgus_> terminate and stay resident old DOS acro. 09.54.07 # ah yes. I am familiar with it it just didn't exactly spring to mind. 09.54.19 # my memory is a little fuzzy now but several of the MIPS targets didn't have enough space for the expanded stack needed to play opus reliably. 09.54.44 # they'd overflow sometimes doing disk accesses, etc. 09.55.09 # (even without seeking) 09.55.16 # __Bilgus_: if you get TSR working I think a few other plugins can benefit from the treatment. 09.55.24 # <__Bilgus_> oh it already works 09.55.41 # <__Bilgus_> have a look at the alpine plugin 09.57.40 # <__Bilgus_> https://github.com/Rockbox/rockbox/blob/master/apps/plugins/alpine_cdc.c#L1115 09.58.07 # miner49er, yes, I believe you are correct. 09.58.37 # I find that odd though. 09.59.41 # anyone with a m68k target around that can do a codec benchmark? 10.12.14 # __Bilgus_, do you see any inherent reason to not merge that pull-stuff-off-the-stack opus patch? wodz's comment about possible impact on m68k not withstanding. 10.17.18 *** Saving seen data "./dancer.seen" 10.17.32 # <__Bilgus_> no. 10.19.55 # speachy, thanks for that. The only alternative I see is that the codec was built incorrectly - or does SDL_LoadObject just load the file regardless? 10.20.40 # it's basically a wrapper around dlopen(). if the file was busted then I imagine you'd see an error to that effect. 10.22.19 # Hmmm, I think I need to look at the source-code for that function as "Dynamic loading not supported" would suggest it's not been implemented. Thanks, that has made me think a bit more on this. 10.22.24 Quit massiveH (Quit: Leaving) 10.22.54 # libsdl needs to be built with --enable-dlopen (not the default) 10.23.59 # miner49er, you're using the generic hosted arm cross-compiler to do the build? 10.24.09 # s/generic/rockbox/ 10.25.01 # I'm using a cross-compiler specifically for the Pocket Go. I've hacked a MakeFile (for now, I'll fix the configure file properly eventually) to point towards my cross-compiler 10.25.54 # well, you could always recompile libsdl too 10.26.31 # Yes, that's on my list of things to try...maybe even statically link it as well? 10.27.09 # ...or make it start with a script that points at my compiled libsdl. 10.29.00 # pocketgo v1 or v2? 10.30.34 # ah, it's mips-based. 10.32.43 # pocketgo V1 10.32.58 # mips? 10.35.08 # As far as I can tell, it's AllWinner F1C100S ARM9 based 10.40.05 # I take that back; the v1 is an allwinner ARM SoC. but v2 is an Ingenic jz4770 10.41.27 # Ah good...that confused me for a moment! 10.41.42 # surprising they'd swap out the guts like that. 10.42.34 # then again it's all linux (and opensource software on top too) so there are no software dependencies 10.42.50 # I think I shall try just implementing my own SDL_LoadObject that calls dlopen...to try it out. I don't need to rebuild the entire SDL as it's wokring mostly - the Rockbox GUI is displaying, sound is working (if I enable menu-clicking sound) 10.43.59 # pocketgo V1 is a very cheap device right now - potentially a pretty good replacement for those who's Rockboxable h/w is failing them. 10.44.27 # ...but will probably have terrible sound or battery life! I just want to see (and hear!) it running 10.46.26 # also on the large side 10.48.17 # what you can do instead is build lc-unix.c instead of sdl/load_code-sdl.c 10.48.21 # in SOURCES 10.48.28 # that's a native dlopen() implementation 10.48.32 # It's actually pretty dinky to be honest 10.49.20 # in the Rockbox source-code? 10.49.47 # I don't have it here at the moment...on my work laptop. 10.49.51 # yes 10.49.57 # cool, thanks. 10.50.03 # it's relatively tiny but it's quite large for a DAP 10.50.45 # yes, same height as my sansa clip but 4 times the width 10.51.34 # ...plus it doesn't have a clip, which is quite useful when cycling. 10.51.38 # granted the clip is tiny 10.52.30 # I love my clip...I'm on my 5th one, so when this one dies, I'll be lost. 10.56.41 # heh. I have my very own tower of rockbox here. with a cat on top. 10.57.19 # miner49er, if you haven't already started using the multiboot loader and runing entirely off the SD card, you should do it 10.57.20 # My original archos recorder is still here...but the headphone socket is janky 10.58.14 # what advantage does that give me? I don't care about the original software...in fact it's annoying when I accidentally cause it to start! 10.58.29 # it means you won't wear out the onboard flash 10.58.39 # (that's what killed my original clip+) 11.00.10 # Ah, the internal storage is being written to...where .rockbox resides? 11.00.15 # yes 11.00.27 # ah, thanks - this is good information! 11.09.12 # Build Server message: New build round started. Revision 82943ea, 295 builds, 14 clients. 11.11.28 # hmm, never noticed but the X3 buttons in "USB multimedia mode" doesn't don't do anything. 11.13.49 # As a bonus, after setting up multiboot, if you turn on "USB Hide Internal Drive" in Rockbox, you can pretty much pretend that the internal storage doesn't exist from that point forward. 11.20.34 Quit ac_laptop (Ping timeout: 240 seconds) 11.20.59 # Build Server message: Build round completed after 708 seconds. 11.21.01 # Build Server message: Revision 82943ea result: All green 11.23.40 # I wonder how long the fastest build round was 11.24.27 # Maybe not of all time, but in the project's modern history (since, say, release 3.0) 11.27.59 # since I've been involved I've considerably expanded the number of builds going on 11.31.05 # Yeah, you've breathed a lot of life back into Rockbox 11.35.56 # we can't fix what we don't know is broken 11.45.56 # Build Server message: New build round started. Revision 058ba97, 295 builds, 14 clients. 11.47.22 # okay, let's see if the irq stack bump helps with the only one still reporting X3 usb stability issues 11.47.58 # and HID mappings are now there. Excellent. 11.53.17 # I 11.53.28 # looks like I'm going to have to completely ban the bing crawler 11.54.37 # already had to do that for part of the forum, but for some reason it's now up to over 1000 complete crawls of the bug tracker in the past two weeks 11.55.00 # That's ... excessive 11.55.40 # it's responsible for 9% of the main www site traffic all by itself. 11.58.08 # Build Server message: Build round completed after 732 seconds. 11.58.10 # Build Server message: Revision 058ba97 result: All green 12.02.45 # <__Bilgus_> g#2542 12.02.47 # Gerrit review #2542 at http://gerrit.rockbox.org/r/2542 : Voice TSR Plugin Demo by William Wilgus 12.03.05 # <__Bilgus_> I'll flesh it out more later but theres the idea 12.04.38 # <__Bilgus_> speachy could you clue me in a bit on what all 2534 accomplishes? 12.04.55 # someone on tor is trying to mirror the themesite. (wtf..) 12.05.24 # <__Bilgus_> I guess it could have a cfg on first run that allows you to set the hotkey and which data you want announced 12.05.49 # <__Bilgus_> I've mirrored the themsite before when it was going down alot 12.06.25 # the main thing is that voices status as one would find on the WPS -- eg date/time, battery life, current track or playlist info 12.06.30 # <__Bilgus_> a lot.. maybe they have the same concern or its of nefarious intent though i'm not sure of the eventual payoff.. 12.06.31 # so the plugin would need to be able to access that 12.07.55 # <__Bilgus_> easy enough i'll let you know when i've fleshed it out a bit 12.09.46 # I think everything but playlist_get_display_index() is already in the plugin api 12.10.13 # (ie which entry of the playlist we're currently on) 12.11.55 # it currnetly reads what to voice via a config key 12.12.14 # and would also need to be launched via a wps hoetkey 12.12.54 # <__Bilgus_> we can choose any hotkey after the initial launch or the same one 12.13.15 # same one. the idea is to be transparent 12.14.39 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6933:271b:1ef7:a8e8) 12.14.54 # so WPS_HOTKEY action would check to see if the thread is running or not, and if it already is, tell it to run 12.15.24 # it would always be the same action, so the thread would just block until woken back up. 12.15.31 # <__Bilgus_> thats taken careof automagically 12.15.37 Quit petur (Quit: Connection reset by beer) 12.16.25 # <__Bilgus_> if the app gets rerun it hands control back to the already 'running thread 12.16.41 # <__Bilgus_> if another app is run it exits 12.17.19 *** Saving seen data "./dancer.seen" 12.17.51 # now for the actual voicing, would it cause the wps screen to block until the voicing is done or is that all backgrounded/mixed/etc? 12.18.21 # <__Bilgus_> i think it doesn't block but i'd have to test it to be sure 12.25.51 Join miner49er38 [0] (5cec5d32@92.236.93.50) 12.26.13 Quit miner49er38 (Remote host closed the connection) 12.26.24 # sweet 12.27.26 # speachy, so I tried bypassing the SDL_LoadObject and basically just copied in the function you talked about - I get the same error (it comes from dlerror()) 12.28.13 # So...can linux itself not be allowing the loading of the library - or is much more likely I'm actually not building the codecs with the correct compiler...can't understand that though, as the main executable runs fine. 12.28.21 # was about to say that. 12.28.34 # run 'ldd' on the rockbox binary and one of the .codec files 12.28.42 # or 'file' rather 12.29.17 # okay, on the actual device obviously...it'll take a while with the stupid on-screen keyboard but I shall try! 12.29.34 # no, you can do it on your pc 12.29.44 # $ file rockbox.elf 12.29.46 # rockbox.elf: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, with debug_info, not stripped 12.29.48 # y 12.29.53 # $ file lib/rbcodec/codecs/speex.elf 12.29.54 # lib/rbcodec/codecs/speex.elf: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, with debug_info, not stripped 12.30.09 # (from the x3ii build) 12.30.18 # oh, okay...right I'll be back...gonna log out of laptop 12.30.23 Part miner49er 12.31.25 Join miner49er [0] (5cec5d32@92.236.93.50) 12.33.21 # for rockbox I get: rockbox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped 12.33.35 # codec: sid.codec: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped 12.35.04 # would be interesting to run 'ldd' on that codec executable to see if it's "missing" anything. 12.35.28 # managed to fiddle with on-screen k/b on device - ldd returns not a dynamic executable! 12.36.15 # oh, says same on PC too! 12.36.51 # even for the main rockbox binary? 12.36.58 # (on the PC I'd expect that) 12.37.43 # whoops, nevermind 12.37.58 # okay, the problem is that the codec is being linked dynamically 12.38.03 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 12.39.10 # both on PC and device - I get not dynamic executable - but rockbox is _just_ an executable so isn't that correct 12.39.31 # But codecs and rocks are meant to be aren't they? 12.39.41 # look at the top-level Makefile 12.39.46 # SHARED_LDFLAG 12.39.47 Quit jdarnley (Ping timeout: 240 seconds) 12.40.23 # I have: export SHARED_LDFLAG=-shared 12.40.41 # and SHARED_CFLAGS 12.40.52 # I have: export SHARED_CFLAGS=-fPIC -fvisibility=hidden 12.41.35 # I based this makefile off the one generated for the linux SDL build btw 12.43.10 # on the target, 'ldd' on the plugin/codec says it's not dymanimc? 12.43.31 # yes 12.44.01 # should I be using -dynamiclib 12.44.12 # for SHARED_LDFLAG 12.44.17 # no 12.44.23 # oh 12.44.31 # that saved me a build then! 12.44.58 # I'd be willing to bet that some library that the codec relies on is not available for static linking. 12.45.21 # so should all the codecs be getting linked with the main executable? 12.45.50 # nope, everything is a loadable module 12.46.09 # that's not how the linux SDL build works - it still dynamically loads the codecs, doesn't it? 12.48.28 Quit michaelni (Ping timeout: 256 seconds) 12.49.52 # So is the result of ldd "not a dynamic executable" (when run on device) correct or incorrect? 12.50.19 # static-linked vs dynamic-linked refer to an individual binary. one can dynamically load a statically-linked library. 12.50.57 # Okay, that sounds strange but I will take it as given! 12.51.43 # the "not a dynamic executable" is odd. it very well might not be linked properly. 12.52.21 # It's highly probably that my MakeFile hackery is the cause! 12.52.22 # dynamic-link vs static-link basally determine if the given binary is self-contained 12.52.34 # ie doesn't require anything else in order to load properlyt. 12.52.45 # (eg the basic C library, SDL, or whatever) 12.53.01 # the plugins are supposed to completely self-contained 12.54.00 # afk for a moment 12.58.31 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 13.00.59 # I had to remove -lpulse-simple -lpulse from LDOPTS in order to get it building - could that be the cause? 13.03.10 Join PimpiN8 [0] (~PimpiN8@213.232.87.64) 13.07.41 # lol, I just noticed on the build table that the estimated RAM usage for one device appears to hit 1.5 GB 13.07.47 # it's probably picking that up from the host pkg-config. if the main executable works then I'd expect the plugins to be okay as well. 13.08.55 # Strife89, yeah, that happens because of non-linear memory maps 13.08.59 # what are the updates with the new release? 13.09.52 # AFAIK there aren't even soft plans for a 3.16 release 13.10.17 # https://www.rockbox.org/wiki/MajorChanges shows what's changed since the last release 13.10.17 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 13.10.26 # the last couple of months aren't there yet. 13.10.40 # * speachy pokes everyone 13.10.43 # * speachy pokes himself 13.13.37 Quit PimpiN8 (Ping timeout: 246 seconds) 13.14.05 Join petur [0] (~petur@rockbox/developer/petur) 13.28.18 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) 13.37.05 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 13.44.24 # wiki updated with most of what's happened since may. 13.44.48 # it seems simultaneously too verbose and not enough. 13.45.26 # some of the "improvements" could probably be changed to "new features" 13.47.27 # mendelmunkis, any further movement on g#2428? or g#2469? 13.47.38 # Gerrit review #2428 at http://gerrit.rockbox.org/r/2428 : Add support for ID3 tags embedded in AIFF files by Moshe Piekarski 13.47.38 # Gerrit review #2469 at http://gerrit.rockbox.org/r/2469 : imx233: rtc: Explicitly clear the soft reset bit when initializing by Solomon Peachy 13.47.59 # I think you listed a good amount, it's nice to know about so many under-the-hood changes 13.59.56 # speachy, do you have any more insights regarding my codec issue before I give up for the evening? 14.00.14 # not at the moment. my primary attention for now is $dayjob alas 14.00.40 # ah, like me earlier! 14.01.28 # Okay, well I try and process what you've shared on a low priority background thread for now then. Thanks for you help :-) 14.01.43 Quit livvy (Ping timeout: 240 seconds) 14.05.26 Quit vmx (Quit: Leaving) 14.09.21 # hey, what was that 1.5GB RAM target? 14.11.06 # One of them was ihifi760 14.11.26 # 1,611,823,760 14.12.25 # creativezenxfistyle: 1,611,905,888 14.12.53 # fixed the imx233 (eg fuze+) and the hosted binaries 14.13.55 # let's see if that fix also affected the 760 14.14.17 # All of the ihifis have similar numbers 14.15.14 # And most of the Creative Zens 14.17.00 # <__builtin> speachy: re MajorChanges, looks good to me 14.17.19 # <__builtin> though on the verbose side for sure 14.17.23 *** Saving seen data "./dancer.seen" 14.18.09 # <__builtin> regarding a release I think there should be some discussion 14.18.51 # <__builtin> about both an upcoming release and how we want to approach them going forward 14.20.24 # Build Server message: New build round started. Revision 650eaa3, 295 builds, 14 clients. 14.20.40 # this build will show drastic reductions in ram size for several targets. 14.21.50 # I'd like to see fewer manual steps involved in a release. hopefully the infra changes over the past few months will have helped with that 14.22.34 # but .. for 3.16 IMO we need to get the rocker/x3ii/x20 into rbutil so they can become "supported" 14.23.09 Quit TheEaterOfSouls (Remote host closed the connection) 14.24.55 # <__builtin> there was talk before doing 3.14 of eventually dropping HWCODEC support for the 4.x branch 14.25.04 # speachy: g#2428 is ready to go I think. 14.25.05 # Gerrit review #2428 at http://gerrit.rockbox.org/r/2428 : Add support for ID3 tags embedded in AIFF files by Moshe Piekarski 14.25.35 # we can drop hwcodec at any time, really. 14.25.57 # <__builtin> do we actually want to, though? 14.25.59 # 2469 I think is a good idea but I plan to hold off putting it in my prsonal build untill i see the bug again (which may be a few years.) 14.26.21 # (untill than==en I can't prove it fixes the relevent bug.) 14.26.27 # hwcodec isn't actually interfering with anything right now. not even the toolchain bump I'm still working on 14.26.57 # <__builtin> exactly, all our new features are #ifdef'd out on HWCODEC 14.26.57 Join TheEaterOfSouls [0] (~souls@unaffiliated/theeaterofsouls) 14.27.50 # <__builtin> so they aren't interfering with anything, correct 14.27.57 # the infra side of things already can handle "retired" targets properly 14.28.16 # <__builtin> but by the same token they haven't gotten any changes for years 14.28.37 # other than global bugfixes, no. 14.28.38 # <__builtin> and we don't even have capability to test on them anymore 14.29.09 # the recorderv1 hasn't even been compileable since 3.13 14.29.22 # though with the toolchain bump and a couple more features removed I was able to make it fit 14.29.36 Quit shrizza (Ping timeout: 244 seconds) 14.29.56 Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) 14.30.53 # it's probably safe to say that we lack the ability to test 2/3rds of the targets these days. 14.31.39 # Build Server message: Build round completed after 675 seconds. 14.31.41 # Build Server message: Revision 650eaa3 result: All green 14.31.42 # Build Server message: New build round started. Revision ff8cca7, 295 builds, 14 clients. 14.33.22 # <__builtin> yes, but we can be reasonably confident because the targets we can't test share most of the mid- to high-level code with other targets 14.33.50 # okay, binary sizes should be gnerally saner. ihifi shrank by 1.5GB! such progress! 14.34.15 # <__builtin> so as long as low-level, target-specific changes are tested by the author, things are usually fine 14.37.06 # Oh neat, you *can*add a build client in the middle of a round 14.38.04 # i5-M520, 8GB RAM, SanDisk SSD 14.39.12 # Debian 10 under WSL 14.42.04 # speaking of builders -- of the active set, I think only one can do the android and ibasso builds. 14.42.24 # Build Server message: Build round completed after 643 seconds. 14.42.25 # Build Server message: Revision ff8cca7 result: All green 14.42.26 # Build Server message: New build round started. Revision e884140, 295 builds, 15 clients. 14.43.45 # I'll try to add those to one of my builders soon 14.44.16 # My fastest builder is stuck at home while my slowest builder (the one I just added) is the only one I'm willing to leave at work) 14.47.14 # Strife89: WSL2? 14.47.28 # I'd expect version 1 to be horrendously slow 14.47.37 # WSL1. I haven't used this laptop in so long that it's still on 1809 14.47.47 # Ouch 14.47.59 # Background upgrading to 1909 right now 14.48.37 # I suppose I should just wipe it and load a Linux distro 14.49.23 # WSL2 is nice for what it is, but I'm considering switching to headless VMs in VirtualBox (as I did before WSL) because they behave more like actual Linux systems (mainline kernel and systemd) and I can interact with hardware 14.49.59 # Not 2004? 14.50.55 # I use Windows on the desktop exclusively because of accessibility 14.51.08 # I want to get it on 2004, but it's getting fed 1909 automatically 14.51.18 # No button to upgrade it to 2004 yet 14.51.34 # And I don't have an installer stick handy to jump it straight there. 14.51.42 # a11y on Linux is a mess and may not be a thing for much longer, at least not with GUI toolkits 14.52.00 # Yeah, I just used the ISO 14.52.22 # Not downloading that on multiple machines 14.52.42 # the GNOME folks keep trying on the a11y front but.. what's the saying about herding cats? 14.53.03 # Build Server message: Build round completed after 637 seconds. 14.53.04 # Build Server message: Revision e884140 result: All green 14.53.06 # Actually not sure 14.53.12 # (since dumping on GNOME is how the KoolKids(tm) pass their time these days...) 14.53.29 # Well, not really. part of the problem is that there just aren't many people to maintain it 14.53.43 # yeah. not unlike rockbox, eh? :) 14.54.54 # Much, much worse than Rockbox 14.55.09 # A lot of the code still says "Copyright 2001 Sun Microsystems Inc." 14.55.13 # there are advantages to big top-down corporate budgets. 14.55.22 # Indeed 14.55.41 # Whether they outweigh the cons I can't say 14.56.13 # I would try and help maintain it, but I lack the skills currently 14.56.15 # the entire traditional desktop stack is slowly bitrotting everywhere, even on Windows. 14.56.58 # And in its place is the modern web, which is so much worse 14.57.22 # yeah. and the most recent abobination, "electron apps" 14.57.41 # what is ally? 14.57.46 # I don't do Electron. Just won't use anything written in it 14.57.52 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net) 14.58.26 # how about a hardware driver tha the only semi usable version I found was electron! 14.58.51 # just why. 14.58.53 # mendelmunkis accessability. aka a[11 letters]y 14.59.06 # not unlike i18n (internationalization) 14.59.15 # Oh, I was confused about that question 14.59.31 # TIL: my font has 1 and l too similar. 15.00.10 # But yeah, it's way too buggy for me on Linux. Almost all the attention of the one Orca dev (screen reader) is focused on web handling, and it's still terrible 15.00.56 # I'm grateful people at least try, but the current stack won't work in GTK4. There's an issue to rework it, but I really don't think it'll happen 15.02.15 # Console accessibility (without a display server) is better, even though the most lightweight screen reader is in the kernel, where IMO it does not belong 15.02.31 # plumbing layers everywhere are being starved. why work on that when you can build a datamining app instead? 15.02.35 # Maybe one day I'll reject the web entirely and just do that :D 15.03.26 # Yes, complexity and rushed garbage are in now 15.03.44 # kids these days, I swear.. 15.03.52 # But we do have a very good open-source screen reader on Windows that gets attention, and UX is pleasant 15.03.55 # * speachy waves his cane and shouts at a cloud. 15.04.12 # speachy: I take offense at that. 15.04.15 # Apologies, I'm rambling 15.04.36 # * TheEaterOfSouls waves white cane and accidentally hits someone 15.04.51 # mendel_munkis, no offense intended. 15.05.13 # don't worry. my opinion of my generation isn't very high either. 15.05.44 # I don't think it's a generational problem 15.06.23 # I think big companies just scoop up most of the talent and...people are into this terrible stuff for some reason 15.06.26 # The scramble 15.06.53 # Basically, capitalism engulfed the tech world 15.06.53 # Who cares about quality? We need features features features! 15.07.05 # And don't forget DRM! 15.07.09 # Big profits, shun quality 15.07.27 # Yep 15.07.42 # Memory? Resources? What are those? 15.07.42 # I remember thinking that, during the tech bubble that popped in 2000, that it was odd that "tech news" actually meant "financial market news" 15.07.43 # Especially the "give us money, every month, forever"-enabling DRM 15.08.24 # Our rockbox players will outlast them all 15.08.28 # I can't fault folks for chasing things they perceive as making them money. 15.08.28 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) 15.08.43 # it's quite rational 15.08.51 # Yeah, gotta play the game, and all that 15.09.03 # I mean, yeah, it's perfectly reasonable to want to make a living off of whatever you do 15.09.07 # where I object is when they forget they depend on us mountain trolls. 15.09.29 # IMO it's not an end in itself, though. There are better things to pursue than money 15.09.42 # the ideals of Free Software enabled this DRM-infested, adware-laden world. 15.09.52 # TheEaterOfSouls: Yep. You can't take it with you. 15.10.26 Quit J_Darnley (Ping timeout: 258 seconds) 15.10.34 # But maybe I'm just trying to make myself feel better. I'm not career-oriented, so will probably be poor forever 15.16.58 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:f41f:55f2:65ef:d305) 15.19.04 # lol, eefi is so slow that it built exactly ONE item in the last round :D 15.19.49 # It underperformed even gevaerts' Atom machine 15.19.49 # eefi? 15.20.03 # The laptop with WSL 15.20.19 # Figures 15.20.35 # don't forget ccache 15.20.38 # strife89: you are making me feel really bad that I haven't managed to get linux running on my planned build machine. 15.21.01 # mendel_munkis: Sorry about that 15.23.16 # I'm really thinking of going the VirtualBox route again. VMs are slower to boot than WSL2, but it's tolerable 15.23.17 # TheEaterOfSouls: Also, "eefi" is basically the romaji version of the Japanese name for "Espeon" 15.23.57 # Interesting 15.24.11 # I'm not imaginative with my hostnames 15.24.22 # Currently on t460s. Guess what that is? 15.24.35 # souls-t460s? :) 15.25.24 # I just wanted something more memorable than a model number (because I easily forget those). 15.25.48 # Haha 15.25.54 # Makes sense 15.25.56 # And I once saw someone's list of their computers, listed by hostname, and all of them were Japanese Pokemon names. 15.26.06 # So, as a Pokemon fan, I copied that 15.26.29 # My VPS has an arbitrary name. Nothing else, though 15.27.38 # I currently have menashe, chizkiyahu, shlomo, and am trying to get a bootable uzziya. 15.28.07 # Those sound cool. What's your naming scheme? 15.28.29 # Interesting 15.28.34 # Israeli kings. 15.28.45 # (it goes well with my domain name.) 15.28.49 # Neat! 15.29.37 # TheEaterOfSouls: sorry if your reader couldn't handle those. 15.31.05 # The only things it doesn't handle are non-Latin languages 15.46.27 # in a former life we had our database servers named "chomp, bachomp, chewy, bachewy" 15.59.48 # Maybe I'll just stick with WSL for now 16.04.35 Quit jdarnley (Ping timeout: 240 seconds) 16.06.01 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 16.07.35 Quit miner49er (Ping timeout: 245 seconds) 16.17.25 *** Saving seen data "./dancer.seen" 16.23.10 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 16.29.32 Quit J_Darnley (Ping timeout: 256 seconds) 16.29.51 Quit MrZeus (Read error: No route to host) 16.31.18 Join MrZeus [0] (~MrZeus@4e6942be.skybroadband.com) 16.32.56 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 16.37.47 Quit ac_laptop (Ping timeout: 240 seconds) 16.43.20 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.02.23 Quit livvy (Ping timeout: 240 seconds) 17.05.21 Quit ac_laptop (Ping timeout: 265 seconds) 17.12.10 Quit lebellium (Quit: Leaving) 17.13.03 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.23.05 # <__builtin> heh, lambda-builtin is crawling slow, but at least the UL speed is crazy fast :) 17.30.14 # I'm rather disappointed lunchbox-speachy doesn't have a much faster upload speed. probably points at some sort of bottleneck in the upload script. 17.30.46 # (it's plugged into the same GigE switch as the buildmaster..) 17.39.33 # <__Bilgus_> why the flip flop on removing HWCODEC? 17.42.39 Quit __Bilgus_ (Remote host closed the connection) 17.43.36 # it still works, I guess 17.44.54 # speaking personally it's not in the way of what I'm trying to deal with 17.45.27 # <__builtin> yeah, I'm not sure if we really have a pressing need to remove it 17.45.57 # I don't want a half-assed measure like simply disabling the build; if it's going to go away, it needs to be *gone*. 17.46.35 # <__builtin> the question we need to answer is whether people still care about HWCODEC 17.47.19 # there's probably still a couple of 'em out there. might be able to drill into the server logs to see if anything vaguely human-like is downloading 'em 17.47.28 # <__builtin> especially whether any devs still care 17.48.07 # just the "don't break stuff that's working" principle 17.49.11 # <__builtin> and that too, of course 17.50.31 # there's no maintainence advantage to removing 'em unless we strip out all the code too. 17.53.12 # oh, it's not just hwcodec, it's non-bitmap displays too. :) 17.54.41 # there's also still a _ton_ of documentation that considers the archos players the primary targets 18.15.52 Quit blackyus17 (Quit: AFK) 18.16.58 Join blackyus17 [0] (~blackyus1@ip189.ip-144-217-213.net) 18.17.26 *** Saving seen data "./dancer.seen" 18.21.14 Join kugel_ [0] (~kugel@ip5b40caf8.dynamic.kabel-deutschland.de) 18.21.14 Quit kugel_ (Changing host) 18.21.14 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 18.22.14 Quit kugel (Ping timeout: 260 seconds) 18.37.13 Quit sakax (Quit: Leaving) 18.40.26 Quit J_Darnley (Ping timeout: 256 seconds) 18.40.55 Quit ZincAlloy (Quit: Leaving.) 18.41.50 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 18.54.35 Quit kugel_ (Ping timeout: 240 seconds) 18.58.33 Join __Bilgus_ [0] (41ba23be@65.186.35.190) 19.00.22 # <__Bilgus_> the idea IIUC was to branch off or archive at least HWCODEC and then remove all ifdefs & code on a grep basis then finally remove vestiges left over as we run into them 19.13.10 Join kugel [0] (~kugel@ip5b40cbe9.dynamic.kabel-deutschland.de) 19.13.10 Quit kugel (Changing host) 19.13.10 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.38.53 Quit petur (Quit: Leaving) 19.41.37 # ok, here's a start: g#2545 19.41.40 # Gerrit review #2545 at http://gerrit.rockbox.org/r/2545 : WIP: Remove sh support and all archos targets by Solomon Peachy 19.42.42 # over 30K lines deleted. Still haven't excised the keypad mappings in the plugins or large parts of the ocumentation 19.43.17 Join reductum [0] (~weechat@cpe-104-175-169-123.socal.res.rr.com) 19.43.45 # nearly all HWCODEC and LCD_CHARCELL stuff is still present 19.44.23 Quit reductum (Client Quit) 19.57.52 Quit MrZeus (Ping timeout: 272 seconds) 20.17.28 *** Saving seen data "./dancer.seen" 20.20.27 # up to over 36K lines now. 20.20.45 # git status 20.31.23 # okay, that's the first passs. 20.45.46 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 21.32.49 # HAVE_LCD_CHARCELL is another ~4.8K LoC. 21.34.59 Join aenertia [0] (~aenertia@116.251.148.216) 21.35.09 # Hi all. 21.35.34 # Am trying to figure out if there is a usable target for the action-semi based mp4/mp3 players that seem prolific 21.35.53 # form factor wise they appear very similar to the AGPtek playres 21.35.54 # https://www.rockbox.org/wiki/AgptekRocker 21.36.03 # but generally have 8gb of EMMC 21.36.42 # They appear as : Bus 001 Device 009: ID 10d6:1101 Actions Semiconductor Co., Ltd D-Wave 2GB MP4 Player / AK1025 MP3/MP4 Player 21.37.14 # The Tool fear innoculum Limited Edition uses a similar SoC 21.39.57 # I don't think anyone has looked into it. it's a reasonably capable SoC, even without using the decoder engines 21.46.22 # assuming most of the hardware out there is using that reference schematic, the only real question seems to be how to get one's own code in there. 21.47.48 # got a link to one? 21.54.26 # This is the one I bought: https://www.trademe.co.nz/Browse/Listing.aspx?id=2699892832 21.54.44 # Its branded as : Geruida on the Screen 21.55.08 # although it powers on with a graphic that says Finesound by Akor 21.56.23 # Info screen shows: US212C Software Version; and has www.actions-semi.com as support website 21.57.01 # Version V1.101.10 21.57.48 # I want to customize menu layouts and replace BMPs/start-up screens for use as a Mixtape/Gift 21.57.56 Join bonfire [0] (~bonfire@c-73-52-134-66.hsd1.ut.comcast.net) 21.58.00 # good luck with that.. 21.58.03 # heh 21.58.53 # Its been a long time since I looked at Rockbox, 2006/7 I had archos20 and iriver; but they are pricey as single shot mixtape gifts ;) 21.59.29 # I have been doing a lot of esp32 development over the last 2 years 21.59.39 # I am wondering if an esp32 port might be possible. 22.00.31 # Lack of USB host on the original esp32 is a problem, but the ESP32s includes hardware USB host now, so even without external DAC you can pretty much have a fully usable player 22.04.31 # pretty sure this is the same unit : https://www.trademe.co.nz/Browse/Listing.aspx?id=2699892832 22.04.34 # oopps 22.04.40 # https://www.head-fi.org/threads/the-ruizu-x02-dap-thread.744865/page-19 22.04.58 # ruizu-x2 22.06.10 # except with a csr bluetooth chip in addition 22.06.18 # that ruizu-x2 is based on a different SoC, rockchip nano-b. 22.07.51 # Looks excactly the same heh, with the exception of a 6th lock/return button 22.08.18 # down to the shitty plastic slidre power switch on the bottom and the holographic logo and font 22.09.55 # possibly its the d51... 22.10.15 # http://www.ruizutek.com/D51.html 22.10.29 # although that looks like it has a couple of extra buttons on the sides 22.17.30 *** No seen item changed, no save performed. 22.18.58 # the nano-b isn't really up for rockbox either, but the nano-c could probably manage, barely 22.19.23 # I just shimied it open 22.19.39 # Give me a few mins Ill take some pictures 22.19.48 # Figure out what exactly the chips are 22.21.49 # I have a really cheapie no-name dap here based on another Actions AK2117 22.25.06 # atj2127 22.27.20 # the atj2127 will never see a rockbox port. it has something like 88KB of RAM total. 22.30.47 # https://photos.app.goo.gl/owbpgZisZDk7Xewo6 22.33.42 # yeah, it's a lost cause for rockbox. 22.33.54 # dang 22.34.11 # Say, did Rockbox ever get ported to any swcodec players with alkaline batteries? 22.34.39 # I guess you could have put alkalines in the original Archos models.. 22.35.35 # there were very few players that could run on standard batteries. I recall an early Creative model that ran on one AA (or AAA?) cell. 22.35.47 # not for long, mind you. 22.36.23 # Just mulling over the longevity aspect 22.37.20 # LIon batteries are really much better than everything else; much better power density, higher current capacity, more form-factor options.. 22.37.34 # there are two SOIC8 on the back of this board... /me wonders if I SPI dump them; is there any tools for firmware analysis for this platform. There are a couple of hits on Github that appear abandonded 22.37.46 # Yeah but we depend on suppliers to make them for each device 22.38.02 # And you definitely can't grab a new one from a nearby store 22.38.14 # 18650s are easily available 22.38.18 # from any vape shop 22.38.19 # ;) 22.38.27 # yeah, they're generally pretty bulky 22.38.44 # but they do need smart chargers lest things go all explode-y 22.39.48 # I have a bunch of Palm OS devices, see. Most of them use rechargables, and a lot of those are dead. There are so many different ones to replace that I've boxed a few of them to take care of later. 22.39.52 # back to previous comment around esp32 22.40.09 # a lot if not most of the dev boards have lipo charge cicuits built into them 22.40.49 # Meanwhile, I have two Visors and a couple of 3-Com-era models that run on two AAAs and have no problem keeping on with rechargable or alkaline ones 22.41.25 # for an off-the-shelf microcontroller, we'd need one with enough pins to handle external DRAM, boot flash, external mmc/sd, display, i2s (or builtin codec), and of course gpios or equivalent for buttons. 22.41.47 # though we can probably get away with using internal flash for base firmware 22.42.37 # it would also need to have the oomph comparable to at least a 100MHz ARM7 to be minimally viable 22.42.54 # oh, high speed USB2 (therefore ULPI) 22.43.18 # esp32s are 320Mhz 22.43.20 # by the time you add that together, plus the external DRAM, the BoM cost is already scary even before one considers physical cases 22.43.28 # dual core and have offloads 22.43.35 # we'd be better off building a case around a RPi Zero. :) 22.43.51 # 320k usable RAM ; and the WROVER-D modules have an additiona 8Mbit of PSRam 22.44.01 # offloads are pretty useless for rockbox. 22.44.06 # for 4$ they wipe the floor with similar cortex m0 boards 22.44.13 # oh and they have full bluetooth and wifi stack 22.44.18 # I for one would be fine with a RPi0 player 22.44.27 # eugh gross 22.44.37 # You then have a full OS you have to manage 22.45.00 # not really -- the full OS is someone else's problem. 22.45.19 # Ive completely gone off PI for IOT/Home Automation stuff because they break in all sorts of interesting ways I dont want to have to deal with for permanent install single purposes stuff 22.45.21 # we can always go bare-metal too 22.45.53 # I mean, porting rockbox to a new hardware platform (and cpu platform too, in the esp32 case) is qutie a lot of work 22.46.06 # and far be it for me to tell folks what to do with their spare time 22.46.26 # is there any stm32 target? 22.46.29 # but something like that won't be generally useful to other folks that want to put music in their pockets. 22.46.42 # nope, though I'm toying with writing one 22.47.16 # Generally from AVR code to espresif or Stm32 ... it tends to be a couple of defines and pin changes to port 22.47.38 # 320K IRAM is usable, but only 8Mbit of PSram would make it the lowest-end port, memory-wise. even worse than the archos targets. 22.47.57 # really? 22.48.04 # not 8mbit 22.48.10 # 64mbt 22.48.13 # 8MB 22.48.21 # ah, ok. you said 8Mb :) 22.49.09 # I consider 8MB to be the minimum viability point with a full RB feature set (color screen, voice) 22.49.17 # There are heap of Dev boards which have I2C oled, 18650 , rocker switch and TF card slots 22.49.32 # A couple with touch tft etc 22.49.47 # by the time you find one with all the bells and whistles the price isn't so cheap any more. 22.50.12 # Pins are all software definable bar for a couple of special pins for hall effect sensor and capacitive adc samples 22.50.23 # 10$ gets you a WROVER-D cam kit 22.50.31 # I have 5 sitting on my desk 22.50.45 # And that is with a 1600x1200 webcam you can throw away 22.51.42 # fully open toolchain and libraries? 22.51.56 # yup 22.52.02 # with the exception of the wifi stack 22.52.20 # i pretty much dont touch the avr/arduino stuff. 22.52.34 # or the stm32 - because the esp32 is so much nicer to work with due to the wifi 22.53.03 # i have a couple of stmf7 discovery boards, that are gathering dust next to the h3 SBC Pi clones 22.54.38 # I was thinking of going with one of the stm32h7 boards 22.55.30 # I have a fond spot for the stm32 family, having done a ton of work with 'em in a former life. 22.56.31 # Yeah - they are nice ; especially if you are doing high precision analog/pwm 22.56.37 # but even then it would still be a time-consuming vanity project 22.57.04 # the h7 is vast overkill cpu-and-peripheral-wise, but I like it's large amount of IRAM. 22.57.13 # Just - when the Wifi SoC has more oomph than the target, kinda makes it pointless 22.57.35 # such is the reality of modern wifi. 22.58.11 # Definately grab a wrover-d board off aliexpress and have a tinker. For the price of a cup of coffee 22.58.24 # I cut my teeth making wifi modules based around the stm32f1 and their cw12xx wifi chipset. 23.00.15 # if I'm being honest and wearing a "rockbox coder" hat, my time would be better spent getting rockbox ported to commercially-available hardware. 23.00.33 # much as the idea of rolling my own appeals to me. 23.00.57 # * speachy looks over at a closet full of half-finished microcontroller projects 23.11.21 # ah, the PSRAM is SPI-attached. that's going to incur a substantial performance penalty. 23.14.18 # and only 4MB is actually usable at a time. hmm. 23.21.43 Quit livvy (Ping timeout: 240 seconds) 23.34.06 # https://usercontent.irccloud-cdn.com/file/62zeEIPF/JPEG_20200715_220035.jpg 23.34.20 # I have no patience 23.38.00 # (Still waiting for the replacement battery so I can actually *use* the mini.) 23.40.54 Quit [7] (Disconnected by services) 23.41.00 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)