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:00 |
02:51:58 | *** | No seen item changed, no save performed. |
04:00 |
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:00 |
06:52:04 | *** | Saving seen data "./dancer.seen" |
08:00 |
08:25:49 | | Join amachronic [0] (~amachroni@user/amachronic) |
08:29:51 | rb-bluebot | Build Server message: New 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:00 |
09:06:32 | rb-bluebot | Build Server message: Build round completed after 2200 seconds. |
09:06:39 | rb-bluebot | Build Server message: Revision 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:00 |
10:10:52 | | Quit amachronic (Quit: amachronic) |
10:52:11 | *** | Saving seen data "./dancer.seen" |
11:00 |
11:01:19 | | Quit massiveH (Quit: Leaving) |
12:00 |
12:52:14 | *** | Saving seen data "./dancer.seen" |
14:00 |
14:40:53 | | Join lebellium [0] (~lebellium@2a01cb040109a600c480511deea4a7b3.ipv6.abo.wanadoo.fr) |
14:52:18 | *** | No seen item changed, no save performed. |
16:00 |
16:52:20 | *** | No seen item changed, no save performed. |
18:00 |
18:41:33 | | Quit lebellium (Quit: Leaving) |
18:52:24 | *** | Saving seen data "./dancer.seen" |
19:00 |
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:00 |
20:52:27 | *** | Saving seen data "./dancer.seen" |
21:00 |
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:00 |
22:50:04 | | Quit tertu (Quit: Client closed) |
22:52:28 | *** | Saving seen data "./dancer.seen" |