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 | 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 2022-10-03

00:37:10 Quit m01 (Quit: Konversation terminated.)
00:39:14 Join m01 [0] (
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] (
06:52:04***Saving seen data "./dancer.seen"
08:25:49 Join amachronic [0] (~amachroni@user/amachronic)
08:29:51rb-bluebotBuild Server message: New build round started. Revision fe6aa21e9e, 303 builds, 8 clients.
08:30:11amachronic...and there goes all the YUV blitting code.
08:31:02amachronici'm almost sad to see mpegplayer go
08:31:26amachronicjust from the sheer amount of effort put into it
08:31:44speachyyeah, I know. just getting it going at all was quite an accomplishment
08:32:09speachyand making it _work_ (or should I say, "work") on some of those really underpowered systems..
08:37:20speachyhuh, 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:32rb-bluebotBuild Server message: Build round completed after 2200 seconds.
09:06:39rb-bluebotBuild Server message: Revision fe6aa21e9e result: All green
09:08:36speachythat's a lotta green
09:11:17speachyamachronic: 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:24amachronici'm not sure. judging by the forums people seem to confuse the two already.
09:14:35speachyI think the only advantages of the hosted port are exfat and line out (on the newest hardware)
09:14:56amachronicand easier installation
09:15:52speachytrue, I consider the "binary patch" thing to be a barely-workable clusterf−−-
09:16:23speachybut it at least "works" with rbutil.
09:16:55amachronicwe're distributing the prepatched binaries too.
09:17:09speachyyeah, I don't really like that but it's the least-worst optionn
09:17:39amachronichow exactly does one go about generating the patched firmware anyway?
09:17:55speachyplus it's not like those hibyplayer-based units have a moral leg to stand on wrt violating coptrights.
09:18:54amachronicthe original rights holder may have another opinion... but I doubt it'll be a problem.
09:19:02speachythere's a script in teh repo, tools/ (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:44speachyif no vendor-supplied update was supplied, a new one can be fabricated from a flash dump.
09:19:49amachronicah, I didn't find hibypatcher mentioned on the wiki.
09:20:37speachyhibipatcher needs to know the magic string the updater code is looking for.
09:20:58speachymost of them started as 'erosq' but they've all gone to something unique
09:21:18speachy(which is why the newer updates usually don't work on older players and vice versa)
09:21:58amachronici find it weird how despite ripping off the base system they all have a slightly different updater
09:22:24speachyoh it's identical, they just changed the target string
09:23:11speachy(I think because they wanted to prevent off-brand flashing perhaps due to different hibyplayer features being enabled on the cheaper targets)
09:23:29speachy(such as the ability to interact with a smartphone app)
09:23:59amachronicok, makes sense
09:24:36speachyalas 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:05speachyhaven't had the need to pump out a new loader binary so it hasn't mattered. :)
09:25:58speachythe biggest problem with the hosted port is that the base OS leaves so little RAM for us to play with
09:26:35speachy(well, that horribly inefficient display updates, though I think that's technically our fault for not using native threading..)
09:27:13amachronici've made a little bit of headway cleaning up the upstream Linux JZxx code
09:27:36amachronicnowhere near the point of running rockbox though
09:27:50sporkyour buildroot project ?
09:28:02amachronicyeah, i haven't worked on it in a while
09:28:24amachronicmissed a merge window or two
09:29:01amachronici don't think rockbox actually needs a lot of RAM anyway
09:29:15amachronicthat's more a thing for the HDD targets where you need to minimize spinups
09:29:27amachronicwith SD cards I doubt it matters anywhere near as much
09:31:40amachroniclinux itself has issues running with such low RAM
09:31:52speachyit greatly restricts plugins/games, mainly, as we can't just eat into our "buffer" space
09:34:17amachronicwe probably don't need more than 1-2 megs for audio buffering
09:35:04amachronicfrom my testing 128k-256k reads are good enough to max out available SD bandwith
09:41:34speachyI 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:29speachyfb updates in particular are pretty awful on the hiby targets
09:44:50braewoodsspeachy: why? no DMA options?
09:45:39speachywe can't switch to a different thread if we're blocked by a system call.
09:46:29braewoodsoh, cause of writes?
09:46:45braewoodsCan the device be opened as async?
09:47:11braewoodsOh. I see what you're saying now.
09:47:25amachronicwe're not using real threads so the OS has nothing to wake up
09:47:29braewoodsYea, the current process is single threaded.
09:47:38speachyaudio works by callbacks, fortunately so it's effectively a second thread.
09:47:50speachyaudio buffering, that is
09:48:15braewoodsasync changes how writes go but mainly helps for single threaded apps that can afford to pass before trying again.
09:48:40braewoodsWould that be compatible with the current thread model?
09:49:16braewoodsAn async system call wrapper that works with the existing design.
09:50:22speachythat 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:57speachy(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:43speachyI tried to implenent proper double-buffered fbdev access only to discover the hiby kernel didnt' implement that properly. :/
09:54:05speachy(the write blocks until the data has been sent out to the SPI-attached display)
09:54:53braewoodsspeachy: yea, the downside of running as a userspace program.
09:55:23speachywhereas 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:58speachy(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] (
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] (
19:15:13 Quit reductum_ (Ping timeout: 246 seconds)
19:18:28 Join reductum_ [0] (
19:35:23 Join Acou_Bass [0] (
19:36:45 Quit Piece_Maker (Ping timeout: 268 seconds)
19:36:45 Nick Acou_Bass is now known as Piece_Maker (
20:52:27***Saving seen data "./dancer.seen"
21:20:46 Join tertu [0] (~tertu@user/tertu)
21:24:12tertuhi, so I'm trying to build the toolchain using but it's failing out with an "error 2"
21:24:43tertu(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"

Previous day | Next day