--- Log for 03.10.122  Server: iridium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 2 months and 11 days ago

00.37.10 Quit    m01 (Quit: Konversation terminated.)
00.39.14 Join    m01 [0] (~quassel@vps-b172b88b.vps.ovh.net)
00.51.57 ***     Saving seen data "./dancer.seen"
02.51.58 ***     No seen item changed, no save performed.
04.52.00 ***     No seen item changed, no save performed.
04.52.41 Quit    hactar|ant (Ping timeout: 260 seconds)
04.55.16 Join    hactar|ant [0] (~zem@c-24-21-103-100.hsd1.or.comcast.net)
06.52.04 ***     Saving seen data "./dancer.seen"
08.25.49 Join    amachronic [0] (~amachroni@user/amachronic)
08.29.51 #       <rb-bluebot> Build Server message: 3New build round started. Revision fe6aa21e9e, 303 builds, 8 clients.
08.30.11 #       <amachronic> ...and there goes all the YUV blitting code.
08.31.02 #       <amachronic> i'm almost sad to see mpegplayer go
08.31.26 #       <amachronic> just from the sheer amount of effort put into it
08.31.44 #       <speachy> yeah, I know.  just getting it going at all was quite an accomplishment
08.32.09 #       <speachy> and making it _work_ (or should I say, "work") on some of those really underpowered systems..
08.37.20 #       <speachy> huh, this might have the benefit of freeing up some IRAM.  
08.51.18 Quit    JanC (Quit: 'k zien d'r mee weh zi)
08.52.04 Join    JanC [0] (~janc@user/janc)
08.52.08 ***     Saving seen data "./dancer.seen"
08.58.39 Join    massiveH [0] (~massiveH@2600:4040:a993:4900:4dc1:5864:f3c4:6e55)
09.06.32 #       <rb-bluebot> Build Server message: 3Build round completed after 2200 seconds.
09.06.39 #       <rb-bluebot> Build Server message: 3Revision fe6aa21e9e result: All green
09.08.36 #       <speachy> that's a lotta green
09.11.17 #       <speachy> amachronic: what do you think about adding erosqnative to the daiily builds?  And howw to go about differentiating them so folks don't inevitably download the wrong one?
09.13.24 #       <amachronic> i'm not sure. judging by the forums people seem to confuse the two already.
09.14.35 #       <speachy> I think the only advantages of the hosted port are exfat and line out (on the newest hardware)
09.14.56 #       <amachronic> and easier installation
09.15.52 #       <speachy> true, I consider the "binary patch" thing to be a barely-workable clusterf--- 
09.16.23 #       <speachy> but it at least "works" with rbutil.
09.16.55 #       <amachronic> we're distributing the prepatched binaries too.
09.17.09 #       <speachy> yeah, I don't really like that but  it's the least-worst optionn
09.17.39 #       <amachronic> how exactly does one go about generating the patched firmware anyway?
09.17.55 #       <speachy> plus it's not like those hibyplayer-based units have a moral leg to stand on wrt violating coptrights.
09.18.54 #       <amachronic> the original rights holder may have another opinion... but I doubt it'll be a problem.
09.19.02 #       <speachy> there's a script in teh repo, tools/hibypatcher.pl (I think) that does the work -- it extracts the outer ISO9660 wrapper, extracts the ubifs rootfs, patches it up, and repacks everything with updated checksums.
09.19.44 #       <speachy> if no vendor-supplied update was supplied, a new one can be fabricated from a flash dump.
09.19.49 #       <amachronic> ah, I didn't find hibypatcher mentioned on the wiki.
09.20.37 #       <speachy> hibipatcher needs to know the magic string the updater code is looking for.
09.20.58 #       <speachy> most of them started as 'erosq' but they've all gone to something unique
09.21.18 #       <speachy> (which is why the newer updates usually don't work on older players and vice versa)
09.21.58 #       <amachronic> i find it weird how despite ripping off the base system they all have a slightly different updater
09.22.24 #       <speachy> oh it's identical, they just changed the target string
09.23.11 #       <speachy> (I think because they wanted to prevent off-brand flashing perhaps due to different hibyplayer features being enabled on the cheaper targets)
09.23.29 #       <speachy> (such as the ability to interact with a smartphone app)
09.23.59 #       <amachronic> ok, makes sense
09.24.36 #       <speachy> alas I accidently blew away my archive of unpatched/extracted firmwares, and the script I used to generate the bootloaders, patch everything, and gneerateee bsdiffs en masse.
09.25.05 #       <speachy> haven't had the need to pump out a new loader binary so it hasn't mattered.  :)
09.25.58 #       <speachy> the biggest problem with the hosted port is that the base OS leaves so little RAM for us to play with
09.26.35 #       <speachy> (well, that horribly inefficient display updates, though I think that's technically our fault for not using native threading..)
09.27.13 #       <amachronic> i've made a little bit of headway cleaning up the upstream Linux JZxx code
09.27.36 #       <amachronic> nowhere near the point of running rockbox though
09.27.44 #       <speachy> nice.  
09.27.50 #       <spork> your buildroot project ?
09.28.02 #       <amachronic> yeah, i haven't worked on it in a while
09.28.24 #       <amachronic> missed a merge window or two
09.29.01 #       <amachronic> i don't think rockbox actually needs a lot of RAM anyway
09.29.15 #       <amachronic> that's more a thing for the HDD targets where you need to minimize spinups
09.29.27 #       <amachronic> with SD cards I doubt it matters anywhere near as much
09.31.40 #       <amachronic> linux itself has issues running with such low RAM
09.31.52 #       <speachy> it greatly restricts plugins/games, mainly, as we can't just eat into our "buffer" space
09.34.17 #       <amachronic> we probably don't need more than 1-2 megs for audio buffering
09.35.04 #       <amachronic> from my testing 128k-256k reads are good enough to max out available SD bandwith
09.40.49 #       <speachy> yeah
09.41.34 #       <speachy> I think we could dramatically improve the hosted/sdl target's performance by switching to native threading.  Or heck, even "native SDL" threading, instead of the sigalstack approach we've been using.
09.42.29 #       <speachy> fb updates in particular are pretty awful on the hiby targets
09.44.50 #       <braewoods> speachy: why? no DMA options?
09.45.39 #       <speachy> we can't switch to a different thread if we're blocked by a system call.
09.46.29 #       <braewoods> oh, cause of writes?
09.46.34 #       <speachy> yeah. 
09.46.45 #       <braewoods> Can the device be opened as async?
09.47.11 #       <braewoods> Oh. I see what you're saying now.
09.47.25 #       <amachronic> we're not using real threads so the OS has nothing to wake up
09.47.29 #       <braewoods> Yea, the current process is single threaded.
09.47.38 #       <speachy> audio works by callbacks, fortunately so it's effectively a second thread.
09.47.50 #       <speachy> audio buffering, that is
09.48.15 #       <braewoods> async changes how writes go but mainly helps for single threaded apps that can afford to pass before trying again.
09.48.40 #       <braewoods> Would that be compatible with the current thread model?
09.49.16 #       <braewoods> An async system call wrapper that works with the existing design.
09.50.22 #       <speachy> that wrapper will need proper threads in order to do be properly asynchronous.  because otherwise once you're in that write() syscall, you've blocked everything.
09.52.57 #       <speachy> (write, read, whatever.  When trying to improve the performance of the hosted x1000 port I discovered we were hammering sysfs constantly, for example.  open/read/close checking to see for headphone detection, and stuff like that.
09.53.43 #       <speachy> I tried to implenent proper double-buffered fbdev access only to discover the hiby kernel didnt' implement that properly.  :/
09.54.05 #       <speachy> (the write blocks until the data has been sent out to the SPI-attached display)
09.54.53 #       <braewoods> speachy: yea, the downside of running as a userspace program.
09.55.23 #       <speachy> whereas with a native port we are truly async; we set up the DMA and get on with something else until we get the interrupt saying it's done.
09.55.58 #       <speachy> (well, in theory.  stuff like the X3's display is bit-banged, but it's teeeny so doesn't slow us down appreciably)
10.10.52 Quit    amachronic (Quit: amachronic)
10.52.11 ***     Saving seen data "./dancer.seen"
11.01.19 Quit    massiveH (Quit: Leaving)
12.52.14 ***     Saving seen data "./dancer.seen"
14.40.53 Join    lebellium [0] (~lebellium@2a01cb040109a600c480511deea4a7b3.ipv6.abo.wanadoo.fr)
14.52.18 ***     No seen item changed, no save performed.
16.52.20 ***     No seen item changed, no save performed.
18.41.33 Quit    lebellium (Quit: Leaving)
18.52.24 ***     Saving seen data "./dancer.seen"
19.05.57 Quit    reductum_ (Ping timeout: 268 seconds)
19.09.47 Join    reductum_ [0] (~reductum@2603-8000-b400-8764-dea6-32ff-fe16-a622.res6.spectrum.com)
19.15.13 Quit    reductum_ (Ping timeout: 246 seconds)
19.18.28 Join    reductum_ [0] (~reductum@cpe-72-134-251-106.natsow.res.rr.com)
19.35.23 Join    Acou_Bass [0] (~eddie@cpc95736-bolt17-2-0-cust330.10-3.cable.virginm.net)
19.36.45 Quit    Piece_Maker (Ping timeout: 268 seconds)
19.36.45 Nick    Acou_Bass is now known as Piece_Maker (~eddie@cpc95736-bolt17-2-0-cust330.10-3.cable.virginm.net)
20.52.27 ***     Saving seen data "./dancer.seen"
21.20.46 Join    tertu [0] (~tertu@user/tertu)
21.24.12 #       <tertu> hi, so I'm trying to build the toolchain using rockboxdev.sh but it's failing out with an "error 2"
21.24.43 #       <tertu> (originally, i wasn't going to report this here because it was happening on my Mac, but it seems to be happening on my linux box also)
22.50.04 Quit    tertu (Quit: Client closed)
22.52.28 ***     Saving seen data "./dancer.seen"