| 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" |
icon identifies that the person is a core developer (has commit access).