| 00:00:37 | | Quit explore ("Lost terminal") |
| 00:00:53 | | Quit snuupy ("CGI:IRC") |
| 00:01:10 | moos | Buschel_: woot, nice works on ATRAC, congrates. |
| 00:01:21 | | Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 00:02:30 | kugel | moos: performance is affected (but not really noticeably). The skin engine isn't exactly little code. I'm currently limiting the updates a bit so that the statusbar doesn't redraw at each item selection in the list |
| 00:03:26 | moos | sounds nice, and looks sexy :) |
| 00:04:09 | kugel | and it doesn't really have any cost if it's unused (except binsize and ramusage of course) |
| 00:05:08 | gevaerts | *and* it allows AA on the menu screen (if you're careful) |
| 00:05:19 | Buschel_ | moos: thanks :) |
| 00:05:22 | moos | kugel: We are closer to see custumizable skin for recording and radio it seems with all your reworks (you and Jd), right? |
| 00:05:22 | kugel | but it's probably all imagination. My targets don't really allow to even get a feeling if the statusbar affects anything |
| 00:05:28 | mt | Buschel_: I am now. I have seen the patch, but haven't tried it yet. But definitely great work ! :) |
| 00:05:40 | moos | Buschel_: merci to you :) |
| 00:06:06 | kugel | moos: I'll leave the radio and recording somebody else :p |
| 00:06:22 | moos | hehe, already nice :) |
| 00:06:44 | kugel | the problem with those screens is that actual information is different |
| 00:07:17 | kugel | the sb is just a wps within the UI, the information (i.e. metadata and stuff) is all shared with the wps |
| 00:08:11 | Buschel_ | mt: perfect :) From what I understand from the code the dewindow-coefs are s0.31 format. Reducing it to s0.16 should be no real problem... The output must be compared of course. |
| 00:08:33 | kugel | moos: scrolling through a giant list doesn't seem to be slower |
| 00:08:49 | moos | kugel: your works (with Jd) could make things a bit easier for futur adventureres :) |
| 00:09:03 | kugel | meh, the fuze's scrollwheel isn't responsive enough in general |
| 00:10:32 | kugel | AAF will be nice also :) |
| 00:11:19 | kugel | but yea, the sb is awesome :) I really like it |
| 00:11:35 | * | moos likes too a bit of eyes candy when possible |
| 00:11:47 | gevaerts | kugel: it does point to some missing features elsewhere :) |
| 00:12:03 | * | moos hides from amiconn :) |
| 00:12:04 | * | gevaerts wants multiple-sized AA |
| 00:12:07 | kugel | gevaerts: how did the album art adventure turn out? |
| 00:12:13 | moos | (joke here of course :) |
| 00:12:15 | kugel | that's a job for Unhelpful :) |
| 00:12:41 | gevaerts | kugel: it seems to be mostly working, provided you only have one %Cl, in the wps file |
| 00:12:42 | kugel | moos: he's already bitter about the AAF, the sb might get unnoticed :p |
| 00:13:01 | kugel | sorta what I expected |
| 00:13:12 | | Part iamben |
| 00:13:23 | moos | kugel: how about bin/RAM cost? He surely will see the reds ;P |
| 00:13:32 | gevaerts | I think it can be considered as working by accident. Maybe it's best to disable it in the sb (if possible) |
| 00:13:33 | kugel | it's not much |
| 00:14:05 | kugel | not exactly working by accident, I always had it in my mind, but ignored it for now :p |
| 00:14:08 | * | gevaerts imagines that the custom status bar could be really fun on the mr500 |
| 00:14:23 | mt | Buschel_: I'll take a quick look at the dewindow coefficients now. I also thought about making use of the symmetry in the mdct window but didn't think it was going to make a noticeable difference ? |
| 00:14:43 | kugel | I wouldn't even disable it. Saying only "%C" is allowed in the seems OK to me |
| 00:15:04 | gevaerts | conditional seems to work as well |
| 00:15:13 | kugel | gevaerts: yea, the touchregion stuff doesn't work though |
| 00:15:20 | mt | Buschel_: But surely I should've avoided the mutiplies where the window coefs were unity. |
| 00:15:40 | kugel | I meant the tag, which includes the conditional version of it :) |
| 00:15:49 | saratoga | Buschel_: back |
| 00:15:53 | *** | Saving seen data "./dancer.seen" |
| 00:20:00 | Buschel_ | mt/saratoga: I am still not sure about the precision of the dewindowing. e.g. mpc/mp3 use s1.16 but do only have 1 iqmf stage. atrac3 uses 2 stages and may therefore be more sensitive to rounding errors. |
| 00:20:08 | kugel | moos: what target(s) do you have? Are you testing/running the custom sb patch already? |
| 00:20:21 | Buschel_ | mt/saratoga: but 8MHz sound interesting ;-) |
| 00:21:06 | mt | Buschel_: Definitely ! |
| 00:21:32 | * | mt has to go for a while .. bbl |
| 00:21:37 | kugel | Buschel_: I saw your ASM'ifying patch, and thought "the C versions already don't look really optimized" |
| 00:22:10 | Buschel_ | kugel: which parts of it? |
| 00:22:37 | kugel | fixmul* |
| 00:23:07 | Buschel_ | kugel: you are talking of the macros themselves? |
| 00:23:24 | kugel | the C versions (the ones you replace by asm for arm) |
| 00:23:44 | kugel | I have no idea if that asm can be done better or worse :p |
| 00:24:23 | Buschel_ | those asm versions are more or less standard in our other codecs. so, I am pretty sure they are efficient enough ;-) |
| 00:24:42 | moos | kugel: I always use plain SVN build but for testing purpose. I use my beast those last weeks (have few others targets for test too). I I have chance, I'll have a go later tonight (have to go in a few...) |
| 00:25:25 | kugel | 453 open patches is a sad amount |
| 00:25:27 | saratoga | kugel: the 32.0 one evaluates to a single instruction, so its as fast as you can do |
| 00:25:50 | saratoga | the others use 2 or 3 ops, which is also about as fast as possible without hardware support for fixed point math |
| 00:25:56 | kugel | the C code? |
| 00:29:23 | saratoga | no the asm versions |
| 00:29:43 | kugel | I'm talking about the C code all the time :/ |
| 00:29:52 | saratoga | oh they're quite slow |
| 00:30:06 | saratoga | I think you save 30 or 40MHz getting rid of them |
| 00:30:45 | kugel | yea, I'm thinking the C code doesn't look very effective. maybe those can be done a little faster without asm |
| 00:30:53 | Buschel_ | there is also fast asm available for coldfire. someone should adapt an test it. |
| 00:31:15 | saratoga | hmm i wonder if the D2 cache on codec load is the same as the one on AMS due to lack of cache coherency |
| 00:35:33 | kugel | :? |
| 00:35:37 | kugel | D2 cache? |
| 00:36:11 | saratoga | sorry crash |
| 00:36:46 | kugel | possibly |
| 00:37:32 | Buschel_ | ok guys, I need some sleep now... keep me updated about the precision and symmetry stuff :o) good night! |
| 00:37:33 | saratoga | anyone with a D2 want to try something |
| 00:37:41 | saratoga | thanks for your help |
| 00:37:51 | | Quit Buschel_ () |
| 00:48:10 | | Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) |
| 00:52:32 | * | Unhelpful really thinks that pretty much anybody could handle loading an AA multiple times with different sizes. :P |
| 00:53:16 | kugel | is buffering prepared for that? |
| 00:53:21 | | Quit FOAD ("I'll be back") |
| 00:53:39 | | Join FOAD [0] (n=dok@dinah.blub.net) |
| 00:53:46 | kugel | I think only you can do it :p |
| 00:55:09 | | Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 00:58:25 | | Quit stoffel (Remote closed the connection) |
| 01:00 |
| 01:01:24 | Unhelpful | i think that there are already quite enough things in RB that only one person knows enough about to modify. :/ |
| 01:01:47 | kugel | haha |
| 01:02:14 | kugel | well, I'll have a look...later |
| 01:02:15 | | Quit jgarvey ("Leaving") |
| 01:02:21 | kugel | in a month or so :) |
| 01:03:32 | scorche|sh | Unhelpful: bus factor =/ |
| 01:03:41 | Unhelpful | if you don't care for the maximum efficiency, you can really just do it now by bufopen-ing the image file a few more times... and making the size passed to bufopen instead of grabbed from the WPS. |
| 01:04:50 | * | kugel still dreams of tiny album art pics all around the place |
| 01:07:03 | | Join JdGordon_ [0] (i=483e79d3@gateway/web/freenode/x-zkmgnnjaafiqhiyz) |
| 01:10:06 | gevaerts | kugel: RAM usage increas on gigabeat F is 4208 bytes |
| 01:10:23 | kugel | that's all? |
| 01:10:36 | gevaerts | apparently |
| 01:10:40 | kugel | remembers something about 6k on his sansa |
| 01:11:52 | | Quit Hillshum ("Ex-Chat") |
| 01:12:02 | JdGordon_ | lame, freeze time next week? |
| 01:12:53 | kugel | 3.5 will be an awesome release :D |
| 01:13:03 | JdGordon_ | theme wise yes |
| 01:13:10 | JdGordon_ | especially if wfm gets in for that also |
| 01:13:54 | JdGordon_ | by the way... the filenames should be sbs and fms.... statusbar skin and fm skin... |
| 01:13:59 | Unhelpful | kugel: not specifying a standard works fine. -std=gnu89 also works fine, perhaps we should be explicit in case defaults change at some point? |
| 01:14:16 | | Quit faemir (Read error: 54 (Connection reset by peer)) |
| 01:14:27 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 01:15:23 | kugel | Unhelpful: is it even a good idea to autobuild convttf? it has external dependencies |
| 01:16:24 | kugel | also, could it be used for monofonts? It's way more convenient than the ttf2bdf + convbdf combo |
| 01:17:04 | | Join unfair83 [0] (n=opera@CPE0013108b928e-CM000f9fa81f60.cpe.net.cable.rogers.com) |
| 01:17:08 | Unhelpful | i think we should at least have rules in the build system to allow us to build it easily. maybe it shouldn't be auto-built until we start shipping some ttf fonts. :) |
| 01:19:08 | unfair83 | hey, does rockbox support m4b files well? i tried playing some and it didn't work |
| 01:19:31 | JdGordon_ | m4b?! |
| 01:21:43 | | Quit bertrik (Read error: 113 (No route to host)) |
| 01:24:24 | unfair83 | m4b is m4a for audiobooks |
| 01:27:13 | Unhelpful | did you try renaming it? if it's *really* an mpeg-4 container with AAC audio, it *should* play, but RB probably doesn't know what it is with a funny extension like that. |
| 01:29:24 | | Quit unfair83 (Remote closed the connection) |
| 01:29:58 | rasher | I thought the m4b extension was added ages ago |
| 01:30:09 | gevaerts | as far as I can see, rockbox should support m4b. Of course, there's the usual DRM caveat |
| 01:30:18 | rasher | That seems more likely |
| 01:30:55 | Unhelpful | don't we also have some issues with mp4 containers having unusual ordering of atoms? |
| 01:34:17 | | Quit JdGordon_ (Ping timeout: 180 seconds) |
| 01:44:21 | JT|work | fyi look what I found: http://shop.froobi.com/SanDisk-Sansa-e280-MP3Media-Player-Factory-Recertified-Rockbox-Ready_p_78-32283.html=DEALNEWS081003 |
| 01:44:32 | JT|work | "Using the code ROCKBOX10 it brings the price down to 49.99" |
| 01:44:35 | JT|work | :) |
| 01:47:13 | Unhelpful | JT|work: they have them in stock again? ;) |
| 01:49:35 | Unhelpful | kugel: i don't think that adding mono rendering of vector fonts would be a huge problem. handling bitmap fonts might be troublesome, or at least messy, as their metrics are handled differently. |
| 01:50:36 | * | kugel sees that wikipedia lists "a simple markup language can be used to create themes for the menu and while-playing screens" |
| 01:50:53 | kugel | for *menus* also? |
| 01:52:15 | | Join Thundercloud_ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 01:53:12 | | Quit Thundercloud (Read error: 60 (Operation timed out)) |
| 01:55:51 | CIA-43 | New commit by kkurbjun (r22523): Brickmania: Try to clean up some of the paddle collision code and add comments. Gameplay should be the same. |
| 01:57:38 | * | kugel slaps kkurbjun |
| 01:57:48 | kkurbjun | ouch |
| 01:57:49 | kugel | enum members in UPPER CASE please :) |
| 02:00 |
| 02:00:30 | kugel | as per docs/CONTRIBUTING |
| 02:00:39 | kkurbjun | aye aye, I'm changing it |
| 02:02:07 | CIA-43 | New commit by kkurbjun (r22524): Brickmania: Capitalize the enum. |
| 02:03:33 | kugel | kkurbjun, JdGordon: Anyone keen on looking into touchregions for the custom statusbar (maybe after it's in). They're unhandled right now, since all the handlers are in the wps and I haven't really focused on that |
| 02:04:07 | JdGordon | we need to think about if it even makes sense to have them |
| 02:04:56 | kugel | I'd definitely want that if I had such a target |
| 02:04:58 | kkurbjun | I think it could be useful - it could add all of the functionality other targets have when you're viewing a list |
| 02:05:09 | kkurbjun | or menu |
| 02:05:19 | | Quit GeekShadow (Read error: 104 (Connection reset by peer)) |
| 02:05:21 | kugel | even more |
| 02:06:04 | | Quit ender` (" The reason they call it the American Dream is because you have to be asleep to believe it. -- George Carlin") |
| 02:09:06 | Unhelpful | kugel: doing the math, word-at-a-time reads from glyph data cost an extra instruction per pixel, because (++x) %y can be done as a single instruction if y=2, but takes a second instruction otherwise. so, for each 8 pixels read, that's 8 extra instructions, and 3 reads saved. if cache works well, it's pretty easy to see how this could be a loser. :/ |
| 02:10:20 | kugel | indeed, but it could still be worthwhile on cf |
| 02:10:43 | Unhelpful | and that's why i've got that revision stashed. does CF have no cache? :/ |
| 02:10:49 | kugel | not all ARMs have cache either, IIRC |
| 02:11:21 | kugel | no idea actually |
| 02:11:59 | Unhelpful | if the 3 saved reads are from DRAM without cache, this sounds much more winning :) |
| 02:12:36 | | Join Sajber^ [0] (n=Sajber@c-923571d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 02:14:22 | | Join saratoga_home [0] (i=463f90ed@gateway/web/freenode/x-qwkcrhokioljclvz) |
| 02:15:04 | saratoga_home | so it costs 8 pipelined instructions to save 3 loads? |
| 02:15:55 | *** | Saving seen data "./dancer.seen" |
| 02:16:14 | | Quit lyngaas (Remote closed the connection) |
| 02:18:25 | Unhelpful | saratoga: yes, because with byte-at-a-time reads the counter for the pixel within the current data is either 0 or 1, and can be updated with subcol ^= 1, a single instruction that can also set the flag for the condition test to read a new byte or shift the current one over. |
| 02:19:08 | saratoga_home | Unhelpful: on armv4, a load takes 2 clock cycles if theres a cache hit or IRAM, more if theres a miss |
| 02:19:27 | saratoga_home | so you have a best case of 6 clocks and a worst case of much more |
| 02:19:59 | | Quit domonoky1 (Read error: 104 (Connection reset by peer)) |
| 02:21:10 | Unhelpful | saratoga: good to know the numbers. since the reads are sequential, i'm mostly expecting cache hits... so the 3 reads save 6 cycles per 8 pixels, while the extra bookkeeping costs 8. and that's just in the inner loop, there's a little bit of per-bitmap work extra as well. |
| 02:21:19 | Unhelpful | for sequential reads with cache i'd say this is a pretty clear loser |
| 02:21:54 | Unhelpful | unless there's some bounded increment instruction for ARM that i don't know about, or something like that? |
| 02:23:24 | kugel | saratoga: iram is as fast as cache? |
| 02:23:49 | Unhelpful | if i invert the sense of subcol, so that it's counting pixels remaining, rather than the index within the current byte or word, i think i could reduce the per-pixel cost to 1/8 cycle |
| 02:24:46 | | Join mark_____ [0] (n=mark@c-71-235-215-123.hsd1.ct.comcast.net) |
| 02:25:46 | | Join langzeitstudent_ [0] (n=langzeit@p5B17D2F0.dip.t-dialin.net) |
| 02:29:43 | saratoga_home | kugel: they're very very close but not exactly the same under all conditions |
| 02:29:55 | saratoga_home | since disabling cache and running out of IRAM is a bit slower then running with cache and IRAM |
| 02:30:32 | saratoga_home | on PP |
| 02:30:41 | saratoga_home | AMS IRAM doesn't seem much different then DRAM |
| 02:31:04 | kugel | soem other ARMs don't even use their IRAM |
| 02:31:26 | JdGordon | kkurbjun: yeah, it would be great, but there is a fair bit of complexity we need to think about... like somehow we need to link a viewport with a touch handler... |
| 02:32:06 | kugel | the skin_engine could handle touchregiouns on its own |
| 02:32:16 | | Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) |
| 02:32:16 | saratoga_home | according to the datasheet, the DRAM on the e200v2 can be clocked at 2x the speed of the IRAM, so that might have something to do with it |
| 02:32:26 | | Quit Lss (Read error: 131 (Connection reset by peer)) |
| 02:35:04 | mark_____ | how stable is rockbox for a clip v1? |
| 02:35:58 | saratoga_home | not very stable at all |
| 02:36:22 | mark_____ | thanks |
| 02:38:06 | mark_____ | I use it on a regular basis with a c200 and a e280 and love it. |
| 02:38:15 | | Quit jfc (Read error: 54 (Connection reset by peer)) |
| 02:41:49 | | Quit jboy_ (Read error: 110 (Connection timed out)) |
| 02:43:55 | Hillshum | mark_____: I disagree, if you use if for low bitrate mp3s (podcasts etc.) like I do, you might have to tolerate a few crashes, but it's not too bad |
| 02:45:27 | mark_____ | I was thinking og trying it with audiobooks and podcasts. |
| 02:46:29 | Hillshum | mark_____: You'll have to compile it yourself of course |
| 02:48:39 | mark_____ | I have never done that before but I do have the development environment on my linux system. |
| 02:52:43 | Hillshum | The hardest part is getting a Unix system |
| 02:53:04 | Hillshum | mark_____: There's docs in the wiki |
| 02:53:50 | | Join jfc [0] (n=john@66.82.208.2) |
| 02:54:40 | mark_____ | I have read them and I do not think I will have much of a problem. They also discuss it over at ABI. |
| 02:59:40 | mark_____ | Building a linux system is not that big of a problem. Any older hardware will work fine. |
| 03:00 |
| 03:02:34 | saratoga_home | having a reasonably fast machine is nice though given the amount of files to be compiled |
| 03:06:36 | mark_____ | True. My linux system is built on mini itx format running at 800mzh. Will eventually build a faster system. |
| 03:11:12 | saratoga_home | did anyone ever try to reproduce teh clip deadlocks in the Sim by reducing its compressed audio buffer? |
| 03:14:42 | Unhelpful | saratoga: hrm, what's the cost of skipped conditional instructions on ARM? 1 cycle? |
| 03:15:04 | saratoga_home | Unhelpful: I'm not sure |
| 03:15:23 | saratoga_home | i think on ARMv4 there would be no cost at all |
| 03:15:43 | saratoga_home | since the PC is unchanged and no stall should be needed |
| 03:16:14 | Unhelpful | none? surely some time is spent reading all of these instructions and deciding not to execute them? |
| 03:19:34 | Unhelpful | per arm7tdmi docs: "Any instruction whose condition code is not met does not execute and adds one cycle to the execution time of the code segment in which it is embedded" |
| 03:19:59 | Unhelpful | that's the flavor of quite a few of our armv4 devices, right? |
| 03:20:12 | saratoga_home | its all ARMv4 |
| 03:20:18 | | Join kamlurker [0] (n=chatzill@24.144.116.47) |
| 03:20:31 | saratoga_home | odd though, i'd expect it to just not write out the results at the end of the cycle if the code isn't true |
| 03:20:49 | saratoga_home | perhaps the lack of a write back stage prevents that |
| 03:21:23 | Unhelpful | i think it's saying that the time to (not) execute the instruction is 1 cycle... not 1 cycle + whatever execution would've cost. |
| 03:24:15 | saratoga_home | sorry i meant no additional cost |
| 03:24:18 | Unhelpful | this explains why i'm *still* not seeing an improvement by counting down instead of up. the reset of the counter to its maximum value is still costing a cycle each pixel, even though it's only executed when the counter hits zero. :/ |
| 03:26:25 | Unhelpful | gcc must have decided that the body of the two branches of the if() was too small to use a branch instruction... instead it's just subs and then a bunch of instructions with eq or ne conditions |
| 03:28:19 | | Quit saratoga_home ("Page closed") |
| 03:31:00 | | Quit mark_____ ("leaving") |
| 03:31:35 | | Part JT|work ("bought what I *think* is a sansa e280 v1 off tigerdirect. cross your fingers!") |
| 03:31:44 | kugel | Unhelpful: I had a quick look, playback/buffering is badly prepared for multiple AA sizes |
| 03:32:59 | | Quit Thundercloud_ (Remote closed the connection) |
| 03:36:07 | | Quit kugel (Remote closed the connection) |
| 03:36:36 | Unhelpful | kugel: ideally, we want a nicer way to load the same file at multiple sizes, too. |
| 03:37:24 | | Quit togetic ("WeeChat 0.3.0-rc2") |
| 03:51:16 | | Quit chandoo ("Leaving") |
| 03:52:29 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 03:53:04 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 03:54:45 | | Quit Dhraakellian ("Kernel patch in a recent batch of updates... rebooting") |
| 04:00 |
| 04:01:23 | | Quit togetic ("WeeChat 0.3.0-rc2") |
| 04:05:48 | | Quit TheSeven (Nick collision from services.) |
| 04:06:05 | | Join The_Seven [0] (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 04:06:09 | | Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 04:16:00 | *** | Saving seen data "./dancer.seen" |
| 04:27:07 | | Nick intrados_ is now known as intrados (n=intrados@cpe-71-67-138-190.woh.res.rr.com) |
| 04:33:09 | | Join MG_Man [0] (n=MGMan@11.208.101.97.cfl.res.rr.com) |
| 04:33:27 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 04:37:24 | MG_Man | well, my theme didnt get taken off, so I guess it's all good |
| 04:38:50 | | Join dys` [0] (n=andreas@95.115.76.241) |
| 04:43:27 | | Quit Rondom (Nick collision from services.) |
| 04:43:37 | | Join Rondom [0] (n=Rondom@dslb-084-057-184-198.pools.arcor-ip.net) |
| 04:54:19 | | Quit dys (Connection timed out) |
| 04:55:36 | | Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 05:00 |
| 05:07:37 | | Quit Llorean ("Leaving.") |
| 05:08:55 | | Join decayedcell [0] (n=decayed_@60-241-92-53.static.tpgi.com.au) |
| 05:09:24 | | Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 05:13:42 | | Quit Rob2222 () |
| 05:14:00 | | Join Rob2222 [0] (n=Miranda@p4FDCD446.dip.t-dialin.net) |
| 05:20:35 | | Quit MG_Man (Read error: 110 (Connection timed out)) |
| 05:32:06 | | Join __lifeless [0] (n=lifeless@188.17.70.71) |
| 05:32:37 | | Quit kamlurker ("ChatZilla 0.9.85 [Firefox 3.0.13/2009080315]") |
| 05:42:11 | | Quit Hillshum (Read error: 110 (Connection timed out)) |
| 05:47:28 | | Join Llorean [0] (n=DarkkOne@99-32-77-163.lightspeed.hstntx.sbcglobal.net) |
| 05:49:06 | | Quit _lifeless (Read error: 113 (No route to host)) |
| 06:00 |
| 06:16:03 | *** | Saving seen data "./dancer.seen" |
| 06:20:54 | | Join MoD2 [0] (n=anonym@ppp-93-104-182-201.dynamic.mnet-online.de) |
| 06:22:25 | | Quit MoD2 (Client Quit) |
| 06:33:31 | | Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) |
| 06:36:39 | | Quit Hillshum (Read error: 104 (Connection reset by peer)) |
| 07:00 |
| 07:06:20 | | Join MoD2 [0] (n=mod@ppp-93-104-182-201.dynamic.mnet-online.de) |
| 07:07:26 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 07:09:08 | | Part MoD2 |
| 07:25:40 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 07:26:30 | | Join NooB23 [0] (n=noob23@ppp-93-104-182-201.dynamic.mnet-online.de) |
| 07:28:54 | | Quit jfc (Read error: 131 (Connection reset by peer)) |
| 07:47:15 | Unhelpful | any thoughts on having the depth field in the font struct / header be an enum for formats instead? i don't see us supporting a huge range of depths, anyway, and we might want to later have special formats that differ in ways other than pixel depth... such as fonts for subpixel AA and the like. |
| 07:48:45 | Unhelpful | also, i'm pretty sure i know how to generate glyphs for those, and have them done more nicely than just making them 3x too wide or too tall. |
| 08:00 |
| 08:03:03 | n1s | Unhelpful: unless you already figured it out, no the cf's we use have no dcache at all |
| 08:03:57 | Unhelpful | n1s: ouch. so reading four bytes on one of them instead of a word would hurt pretty hard, then? |
| 08:05:23 | n1s | think so |
| 08:05:57 | Unhelpful | also, as near as i can tell, CF doesn't have any conditional execution, which means it'll have to branch in UPDATE_SOURCE anyway, which means i can completely hide the extra bookeeping cost, except for every 8th pixel. |
| 08:11:03 | | Join Windeh [0] (n=Windlord@cm66.sigma104.maxonline.com.sg) |
| 08:16:04 | *** | Saving seen data "./dancer.seen" |
| 08:17:13 | | Quit Windlord (Nick collision from services.) |
| 08:17:17 | | Nick Windeh is now known as Windlord (n=Windlord@cm66.sigma104.maxonline.com.sg) |
| 08:25:12 | | Quit BlakeJohnson86 (Remote closed the connection) |
| 08:40:21 | | Join Rob2223 [0] (n=Miranda@p4FDCFC24.dip.t-dialin.net) |
| 08:57:27 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:00 |
| 09:03:54 | kkurbjun | amiconn, I started writing a new pixel format driver for the screen orientation of the M:Robe. I have everything working more or less except the native bitmap drawing. Right now everything calls that function with a stride that's equal to the image width which makes sense if the pixels are horizontally sequential. |
| 09:05:27 | kkurbjun | Unfortunately that stride value doesn't work if the pixels are vertically sequential. Right now the change I had in mind was to make it so that lcd_bitmap_part is always passed the full image height/width so that the driver can make the call on what should be the stride, but that is going to take alot of changes to the code |
| 09:05:48 | kkurbjun | I was wondering if you had any other thoughts on a way to handle the stride for the native drawing |
| 09:07:54 | kkurbjun | As a note, I originally implemented it so that it just translated the bitmaps when you call that function, but it won't work for the backdrop since it has to be re-oriented at least the way that I setup the new driver. I hacked in a re-orientation operation within backdrop.c, and that works, but it's not exactly clean.. |
| 09:13:24 | | Join stoffel [0] (n=quassel@p57B4F124.dip.t-dialin.net) |
| 09:20:22 | | Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) |
| 09:34:01 | amiconn | [03:20:12] <saratoga_home> its all ARMv4 <== Not true. The ARM920T (gigabeat F/X) is ARMv4 too, as are the AS3525 targets |
| 09:34:50 | amiconn | But to answer the original question, all conditional instructions with unmet condition take 1 cycle on all our arm targets |
| 09:36:04 | NooB23 | where is ACTION_STD_ defined? |
| 09:36:12 | amiconn | kkurbjun: Hmm, that's indeed a problem I didn't foresee |
| 09:36:59 | amiconn | You pretty much need the height as a stride if the pixels are ordered vertically. Passing both width and height on all targets would be a waste though |
| 09:38:20 | amiconn | The only solution I can think of right now is to make lcd_bitmap_part a macro which gets passed both width and height, and translates that to a stride of either width or height depending on target (i.e. simply drops the unnecessary parameter) |
| 09:38:52 | amiconn | That wouldn't change binsize at all for the other targets, but will need a lot of rework |
| 09:39:33 | kkurbjun | amiconn, can't you specify that a parameter is not used in a function? I thought kugel or someone was looking at that for some other functions that had unused parameters on some targets |
| 09:39:53 | kkurbjun | it was something more than just a (void) |
| 09:39:59 | amiconn | Hmm, a better idea would be to introduce a STRIDE() macro, which is used in the parameter list of all lcd_bitmap_part() calls |
| 09:40:51 | amiconn | Afaik that's not possible |
| 09:41:14 | kkurbjun | hmm, I guess the stride macro could take both the height and width and pass what's needed on to the function call |
| 09:41:22 | amiconn | yep |
| 09:41:45 | amiconn | Same idea as making the function call a macro, but less hiding of what's really happening |
| 09:43:54 | kkurbjun | yeah, I like that better than making it a full macro |
| 09:44:27 | kkurbjun | the only thing that's unfortunate is it makes the function more complex in that it depends on a macro to use it properly |
| 09:44:53 | kkurbjun | I guess gcc isn't smart enough to fully optimize out unused parameters? |
| 09:44:59 | amiconn | The resulting macro is in fact trivial. #define STRIDE(w, h) (w) or #define STRIDE(w, h) (h) depending on target |
| 09:45:22 | Unhelpful | amiconn: it seems that the arm1136 manual indicates otherwise, with a rather complicated formula applying for instructions that would normally take >2 cycles if executed :/ |
| 09:45:34 | amiconn | How could it? The parameters need to be passed in some way. The caller cannot know that the parameter is unused in the callee |
| 09:45:41 | kkurbjun | yeah, the macro is easy, but for someone new coming in looking at the function it might not occur to them that they need to use a macro for it to work right on all screens |
| 09:46:20 | amiconn | So the passed parameter list needs to follow a well defined convention |
| 09:47:15 | Unhelpful | kkurbjun: that's no worse than various IF_* macros we have elsewhere... and once you hit the range where paramaters start to be passed on the stack, the extra paramaters can get expensive |
| 09:47:57 | kkurbjun | yeah, I guess with the way that gcc compiles it wouldn't be able to.. I'm too used to RTL synthesizes diving through hierarchy :) |
| 09:48:43 | amiconn | kkurbjun: The caller and callee might reside in different .o files, in fact they might even be written in different languages |
| 09:49:05 | kkurbjun | yeah that makes sense |
| 09:49:35 | amiconn | Sure gcc will optimise away any unused parameters for static functions which are inlined, but that's about the only case where it's possible |
| 09:50:41 | kkurbjun | yeah, agreed, the macro definitely seems like it's the cleanest way to go |
| 09:55:31 | | Quit flydutch ("/* empty */") |
| 09:58:35 | | Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) |
| 10:00 |
| 10:07:29 | n1s | hmm, turns out more rtc chips than i realized use bcd natively, handeling the tm in the driver directly is still nicer though |
| 10:11:53 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 10:15:47 | | Join dg1 [0] (n=dg@adsl-71-215-103.jax.bellsouth.net) |
| 10:16:05 | *** | Saving seen data "./dancer.seen" |
| 10:17:10 | dg1 | rockbox sounds really good on my cowon d2, thanks |
| 10:17:20 | | Quit dg1 (Client Quit) |
| 10:19:36 | | Join dg1 [0] (n=dg@adsl-71-215-103.jax.bellsouth.net) |
| 10:20:08 | | Quit BHSPitMonkey (Remote closed the connection) |
| 10:29:16 | | Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) |
| 10:29:52 | | Quit dg1 (Read error: 60 (Operation timed out)) |
| 10:35:57 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 10:57:05 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 11:00 |
| 11:11:51 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 11:15:02 | NooB23 | where is 'rb->kbd_input' defined? searched for 30 minutes but not found anywhere -.- |
| 11:15:06 | | Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) |
| 11:17:07 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 11:19:19 | Unhelpful | NooB23: start by looking in plugin.c and plugin.h, which is where the plugin API structure is defined and filled in with functions. it's essentially a list of pointers to functions in the rockbox core. |
| 11:28:37 | NooB23 | thx so far |
| 11:30:18 | Unhelpful | kbd_input itself is almost certainly defined somewhere else... try using grep or similar tools to search the source. :) |
| 11:35:30 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 11:40:32 | NooB23 | found it in keyboard.c, nice tool :) |
| 11:41:50 | | Quit NooB23 ("Nettalk6 - www.ntalk.de") |
| 11:42:45 | | Nick YpsyZNC is now known as Ypsy (n=ypsy@geekpadawan.de) |
| 11:48:44 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 11:49:35 | | Join stripwax_ [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 11:53:54 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 11:54:56 | bertrik | funman, if I figure out the buttons on the c200v2, can you test it? |
| 11:56:16 | funman | sure |
| 11:56:27 | * | bertrik wonders if domonoky had any luck with the power management chip settings on his m200v4 |
| 11:56:42 | funman | missing buttons are rec/hold vol -/+ |
| 11:57:28 | funman | i have a suspicion that these buttons are read asynchronously to the function which reads the center+directional cross (through DBOP) |
| 11:57:45 | bertrik | aaaargh, the c200v2 also seems to share buttons with dbop pins |
| 11:57:46 | | Join TheSphinX^ [0] (n=cold@84.165.213.2) |
| 11:58:06 | funman | these are known: there are 5 bits on dbop din |
| 11:58:27 | funman | and btw reading them by DBOP is better than reading them on the GPIOC pins |
| 11:59:36 | bertrik | oh? I can't imagine how |
| 12:00 |
| 12:00:02 | funman | i had false reads with the GPIOC pins, perhaps the DBOP controller manages the delays |
| 12:00:04 | bertrik | I think it's always easier if pins have just one function |
| 12:00:26 | funman | yes perhaps the problem comes from the switch between DBOP/GPIO |
| 12:01:42 | bertrik | I think so |
| 12:02:04 | bertrik | you can't just switch the pins to GPIO when DBOP is busy with it |
| 12:03:42 | | Quit funman ("leaving") |
| 12:04:02 | bertrik | when trying to enable the DBOP FIFO on the fuze/e200v2 (to speed up the lcd update) the display shows blue bars, I think those are caused by GPIO button reads |
| 12:06:05 | | Quit stripwax (Read error: 110 (Connection timed out)) |
| 12:06:37 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 12:07:16 | | Join Ubuntuxer [0] (n=johannes@dslb-094-221-090-173.pools.arcor-ip.net) |
| 12:15:48 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 12:16:06 | *** | Saving seen data "./dancer.seen" |
| 12:16:10 | kugel | Unhelpful: as if those IF_* macros aren't already bad enough |
| 12:16:26 | kugel | :( |
| 12:17:17 | | Nick Ypsy is now known as YpsyZNC (n=ypsy@geekpadawan.de) |
| 12:17:29 | Unhelpful | kugel: they serve a useful purpose, and they're clear enough... and you should be able to use convttf now, i found a bug related to the change of depth from a numeric value to a flag... i must have somehow not managed to actually install the fonts i made with it, but i have it working now :) |
| 12:18:28 | Unhelpful | i'd like to rename depth to format and make it an enum... maybe at some point we'll have more formats :) |
| 12:19:04 | kugel | changed opinion? |
| 12:19:38 | | Quit scorche (Remote closed the connection) |
| 12:20:44 | | Join scorche [50] (n=scorche@rockbox/administrator/scorche) |
| 12:20:54 | Unhelpful | i don't know for sure. the 4-bit fonts are already no good on non-color targets, so in a way they're already target-specific... so why not have 2-bit ones for greyscale, and/or subpixel-rendered ones, etc. |
| 12:22:11 | | Nick YpsyZNC is now known as Ypsy (n=ypsy@geekpadawan.de) |
| 12:27:24 | | Join daurn [0] (i=daurnima@freenode/staff/daurnimator) |
| 12:27:27 | | Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) |
| 12:27:49 | | Quit Ubuntuxer ("Leaving.") |
| 12:29:45 | | Quit stoffel (Remote closed the connection) |
| 12:36:51 | | Join stoffel [0] (n=quassel@p57B4F124.dip.t-dialin.net) |
| 12:38:01 | | Quit TheSphinX^ (Remote closed the connection) |
| 12:38:35 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 12:39:37 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 12:40:11 | kugel | Unhelpful: that's what I was thinking too |
| 12:40:39 | kugel | greylib even could try to load the 4bit variant if it's available (by simple filename search) |
| 12:41:13 | Unhelpful | i think the biggest problem though is that right now we have one pack of fonts to download, and all of them work on all targets that can load fonts... |
| 12:41:16 | | Quit __lifeless (Remote closed the connection) |
| 12:41:33 | | Join __lifeless [0] (n=lifeless@90.151.222.130) |
| 12:42:10 | kugel | I guess we would want a separate package for aaf |
| 12:42:16 | kugel | if at all, that is |
| 12:43:04 | pixelma | fonts on greyscale aren't drawn with greylib |
| 12:43:15 | | Join _zic [0] (n=user@91-165-248-215.rev.libertysurf.net) |
| 12:43:29 | kugel | that could be changed :) |
| 12:43:34 | pixelma | that would be too slow I guess |
| 12:43:53 | pixelma | overkill |
| 12:44:10 | kugel | that never stopped us |
| 12:44:29 | kugel | I don't think it would be *too* slow |
| 12:44:42 | | Quit daurnimator (Read error: 110 (Connection timed out)) |
| 12:45:10 | pixelma | it's always nice how you say "I don't think so", adds much too the conversation |
| 12:45:17 | pixelma | to the |
| 12:47:06 | kugel | what do you want to hear? benchmark numbers? I can't tell it for sure, I have no greyscale target at all (plus, as if "that would be too slow I guess" added more) |
| 12:47:11 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 12:47:28 | pixelma | and fonts look blurry enough on most greyscale displays when lines need to scroll you wouldn't even notice anti-aliasing, ask some H100 owners |
| 12:48:03 | * | scorche nods in agreement |
| 12:48:27 | kugel | that's no reason to not try it at least |
| 12:50:21 | pixelma | well, I prefer a readable and snappy UI |
| 12:50:30 | kugel | also, the idea was to load the 4bit font only if a 2bit font was already chosen anyway, it would be anti-aliased in any event (unless you use a mono font, then greylib shouldn't try to load a AA font at all) |
| 12:51:55 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 12:52:52 | | Quit _zic (Remote closed the connection) |
| 12:53:36 | pixelma | I'm questioning the sense of font-aliasing on greyscale in gnerel (I even do for colour with current display sizes and the font size I typically use) |
| 12:53:46 | pixelma | general too |
| 12:54:13 | kugel | I noticed that |
| 13:00 |
| 13:02:03 | amiconn | Using the greylib in the core is out of question |
| 13:02:07 | AlexP | There would be no point whatsoever for the H100, the display is so crap :) For the others, who knows |
| 13:02:28 | | Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) |
| 13:02:31 | amiconn | It draws too much cpu power |
| 13:02:41 | pixelma | handling 4 times the data and changing the drawing to a much more complicated system must be slower |
| 13:03:15 | pixelma | a lot |
| 13:03:16 | | Nick Ypsy is now known as YpsyZNC (n=ypsy@geekpadawan.de) |
| 13:03:50 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 13:05:24 | kugel | amiconn: I didn't talk about core |
| 13:05:36 | kugel | or didn't mean to... |
| 13:06:12 | pixelma | AlexP: the M5 display is a bit better but still looks blurry when things scroll, the greylib looks grainy on the Mini (forgot the technical explanation for this) |
| 13:06:36 | pixelma | kugel: I thought you talked about font aliasing, wouldn't that be for the core? |
| 13:07:02 | kugel | 2bit fonts for the core, which can be done without anti-aliasing |
| 13:07:10 | pixelma | anti-aliasing I meant |
| 13:07:22 | kugel | when if you load a greylib enabled plugin, it could try to load the 4bit pendant |
| 13:07:37 | * | kugel adds a slash |
| 13:08:25 | amiconn | A slow lcd is actually good for the greylib |
| 13:11:11 | kugel | I meant withou without greylib to sentences ago, of course |
| 13:11:17 | kugel | s/withou// |
| 13:11:33 | kugel | s/to/two/ ............... |
| 13:13:35 | AlexP | :) |
| 13:16:08 | kugel | Unhelpful: still no success |
| 13:17:48 | | Join Buschel [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) |
| 13:23:23 | Unhelpful | kugel: i just did a clean build of simulator, and generated some fresh fonts. they work. and they've been working on my targets. you're using the three new patches? |
| 13:24:11 | Unhelpful | do the greyscale targets let the user select text and background grey levels? that alone would be enough to kill our ability to do any antialiasing. :) |
| 13:24:40 | pixelma | you can use a backdrop |
| 13:25:09 | kugel | Unhelpful: not the one for plugins but it shouldn't matter |
| 13:25:28 | kugel | I explicitely deleted convttf.c before (git actually wanted that :p) |
| 13:25:31 | amiconn | The text and background greylevels are selectable in the driver, it's just a matter of adding settings |
| 13:25:48 | pixelma | and in the WPS you can use all 4 shades of grey for fore- and background per viewport |
| 13:26:10 | pixelma | my M5 WPS uses that |
| 13:26:13 | * | amiconn still thinks that ordinary pixel-based font aa is worthless and a huge slowdown at the same time |
| 13:26:59 | | Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) |
| 13:27:33 | | Quit Rob2223 () |
| 13:27:38 | Unhelpful | kugel: maybe a pluginlib loader and renderer. rockpaint wouldn't be hurt (on color targets) by having the ability to do its own font loading and caching. |
| 13:27:52 | | Quit merbanan (Client Quit) |
| 13:28:05 | | Join Rob2222 [0] (n=Miranda@p4FDCFC24.dip.t-dialin.net) |
| 13:29:21 | pixelma | Rockpaint hasn't been ported to greyscale yet |
| 13:29:31 | Unhelpful | for core, keep in mind that we're talking about 2-bit fonts that you already decided look awful, and they'd be displayed with rather large pixels besides (on greyscale targets). |
| 13:29:57 | Unhelpful | pixelma: i'm aware, but i was testing its AA font support and had a lovely experience with the font selection menu. :/ |
| 13:30:42 | pixelma | just don't do it :P |
| 13:31:33 | | Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) |
| 13:32:44 | Unhelpful | well, actually it would be fairly usable if it cached the rendered names, and draw ahead, so that it wasn't redrawing each font when you got to the bottom and it started scrolling |
| 13:33:13 | kugel | Unhelpful: they look awful on color yes, no idea how they'd look on greyscale |
| 13:34:12 | kugel | what does rockpaint do with the fonts? I've never used it |
| 13:34:47 | Unhelpful | use the text tool, and pick select font from the menu. and have fun. :) |
| 13:36:22 | Unhelpful | kugel: i doubt they'll look much better with grey levels that are not evenly spaced in brightness, and huge fonts. |
| 13:37:31 | Unhelpful | also, subpixel AA would cost one more multiply, and a few more add, shift, and other one-cycle instructions. plus the cost of the extra font data. 2-bit might be passable for that, since we'd also be tripling the effective resolution. |
| 13:37:39 | Unhelpful | s/huge fonts/huge pixels/ |
| 13:38:07 | kugel | lol nice |
| 13:38:52 | amiconn | Subpixel aa is the only acceptable font aa for me. Unfortunately it isn't possible using precomputed fonts on some targets |
| 13:38:56 | | Join Buschel_ [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) |
| 13:40:30 | kugel | Unhelpful: why don't fonts work me :( |
| 13:41:00 | kugel | they have a reasonable size now (200k for monofur, 450-500k for dejavu) |
| 13:41:22 | Unhelpful | amiconn: because of vertical vs horizontal pixel layout? |
| 13:42:02 | amiconn | yes |
| 13:42:10 | | Quit Buschel (Read error: 104 (Connection reset by peer)) |
| 13:44:39 | Unhelpful | that part's actually easy, we'd store both versions of the glyph on disk, and load the desired one into cache. they should even be drawable with the same routine without extra conditions, so we wouldn't have to deal with additional slowdown or extra code. |
| 13:48:51 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 13:50:21 | CIA-43 | New commit by stripwax (r22525): Rerrange some registers in butterfly_generic to combine some 2-word stores into 4-word stores and remove some redundant mov instructions. Shave off ... |
| 13:51:48 | | Join Buschel [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) |
| 13:51:52 | Unhelpful | it could be either four copies if we want to support each combination of rgb vs bgr plus vertical vs horizontal... do we have targets where RGB vs BGR is an issue? i recall you mentioning that some had either vertical or horizontal pixel layouts for the same target. :/ |
| 13:51:58 | amiconn | Unhelpful: Now imagine the file size with an unifont-like font... and there's also the problem that you cannot detect automatically which version to use |
| 13:52:24 | Unhelpful | yeah, a single font at 20MB would be icky. |
| 13:53:00 | | Quit Buschel_ (Read error: 54 (Connection reset by peer)) |
| 13:53:35 | Unhelpful | kugel: i just converted monofur. perhaps you should check out an entirely fresh branch to apply the patch to? and you're not testing on a coldfire target, are you? i obviously can't have tested the coldfire version of the blend function. :/ |
| 13:54:00 | | Join darkham [0] (n=darkham@host5-155-dynamic.6-87-r.retail.telecomitalia.it) |
| 13:54:29 | kugel | I did git reset −−hard HEAD^^ so that it's at SVN, and deleted convttf.c |
| 13:55:17 | | Join _lifeless [0] (n=lifeless@90.151.222.130) |
| 13:55:17 | Unhelpful | if it's at svn, how do you have a convttf.c? :/ |
| 13:55:47 | kugel | it wasn't deleted, I apparently didn't add it previously |
| 13:56:08 | kugel | git ci -va doesn't work for added files :/ |
| 13:56:42 | kugel | (which is good) |
| 13:58:38 | Unhelpful | hrm, you're not using a 64-bit or big-endian system, are you? |
| 13:58:56 | kugel | amd64 |
| 13:59:11 | kugel | i.e, x86_64 |
| 13:59:29 | funman | kugel: you can use origin to revert your commits, or git checkout origin to have SVN state in a separate branch |
| 14:00 |
| 14:00:28 | kugel | origin doesn't work so well, because that's the git mirror which isn't always up-to-date |
| 14:00:47 | kugel | that's why I use git svn rebase, and don't fetch regularly |
| 14:00:50 | Unhelpful | kugel: do you have a 32-bit freetype? you could try building with -m32 |
| 14:00:55 | funman | when i use git svn rebase && git pull −−rebase it's always up to date |
| 14:01:16 | Unhelpful | ...and you should fetch to a branch you never work on, except when staging something for commit. :) |
| 14:01:32 | kugel | which would be master... |
| 14:02:12 | kugel | Unhelpful: I don't have 32bit support |
| 14:02:23 | kugel | I deactivated that in the kernel |
| 14:02:25 | Unhelpful | kugel: i'd bet that's where things are going wrong |
| 14:02:48 | kugel | well, the fonts work on the pc |
| 14:03:07 | kugel | I'll try on my lappy |
| 14:04:21 | Unhelpful | of course they work on your PC. it's the converted font that's bad |
| 14:05:19 | Unhelpful | i see some problems already, struct font_header_struct in convttf uses unsigned long for 32-bit values. start by replacing all of the types there with uint16_t for unsigned shorts and uint32_t for unsigned longs. |
| 14:06:09 | Unhelpful | do uint32_t for the two members that are FT_Long, too. there's no reason to use freetype types in that struct, anyway. |
| 14:10:03 | n1s | stripwax_: any benchmark numbers? |
| 14:10:30 | kugel | Unhelpful: indeed, it's a 64bit problem |
| 14:11:04 | | Quit bmbl (Read error: 104 (Connection reset by peer)) |
| 14:11:05 | stripwax_ | n1s sorry, nope. |
| 14:11:20 | | Quit __lifeless (Read error: 113 (No route to host)) |
| 14:12:11 | stripwax_ | hm, only one message from CIA-43? I'd have thought there would be two |
| 14:12:21 | bertrik | the gigabeat-F build just broke |
| 14:12:30 | CIA-43 | New commit by stripwax (r22526): Fix condition code clobbers (and one TAB) for inline arm code in lib and libtremor |
| 14:12:32 | stripwax_ | I broker it? |
| 14:12:34 | stripwax_ | ^broke |
| 14:12:44 | Unhelpful | kugel: i've just put up a patch to fix the font header struct. you may need to do more. i'm going to bed. :) |
| 14:12:59 | amiconn | Unhelpful: You will need to replace that with endian agnostic read/write functions anyway |
| 14:13:50 | kugel | Unhelpful: some 14px don't work |
| 14:13:52 | stripwax_ | agh, right, yes I did. I'll fix |
| 14:16:07 | *** | Saving seen data "./dancer.seen" |
| 14:16:40 | kugel | Unhelpful: hrm, there're a few more problems :/ |
| 14:17:11 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
| 14:19:37 | | Join PaulJam [0] (n=Paule@p54BEE873.dip.t-dialin.net) |
| 14:20:06 | CIA-43 | New commit by stripwax (r22527): Removed remaining MB usage |
| 14:20:12 | stripwax_ | What cpu is Gigabeat F? |
| 14:21:06 | | Nick stripwax_ is now known as stripwax (n=Miranda@87-194-34-169.bethere.co.uk) |
| 14:21:56 | stripwax | It's obviously the only platform that uses the non-assembly mdct butterfly code |
| 14:23:38 | | Quit darkham (Client Quit) |
| 14:23:42 | CIA-43 | New commit by learman (r22528): FS #10466: Introduce a real malloc for tremor. |
| 14:24:06 | AlexP | stripwax: http://www.rockbox.org/twiki/bin/view/Main/GigabeatInfo |
| 14:24:43 | stripwax | AlexP - right but why doesn't it use the ARM optimised code in rockbox? why is it use the regular C? |
| 14:24:55 | AlexP | heh, don't ask me :) |
| 14:25:44 | AlexP | There is something odd about it though - no iram? |
| 14:26:04 | stripwax | I don't know what arm version the ARM920T core is - but I'd have thought the asm would be (at-least) as fast as the gcc c |
| 14:26:09 | * | AlexP is guessing now |
| 14:26:34 | stripwax | Although if you're running at 300MHz, maybe it doesn't matter so much :-p |
| 14:27:26 | Lear | Argh, don't know why SVN decided to delete tlsf/src rather than add... |
| 14:28:02 | AlexP | stripwax: ARM9 I think |
| 14:28:04 | amiconn | ARM920T is v4t |
| 14:28:07 | AlexP | d'oh |
| 14:28:12 | * | AlexP shuts up :) |
| 14:28:20 | amiconn | It's also ARM9 |
| 14:28:39 | amiconn | ARM versions and generations are a real mess |
| 14:28:43 | stripwax | yeah |
| 14:28:50 | AlexP | OK, I feel slightly better now :) |
| 14:28:53 | stripwax | v4t is same as ARM7TDMI? |
| 14:28:58 | amiconn | ARM7 is always v4, ARM9 exists as v4 and v5 |
| 14:29:20 | amiconn | The 'T' means thumb support |
| 14:29:35 | Lear | Ok, what do you do if svn cleanup errors out? |
| 14:29:47 | | Quit petur (Read error: 113 (No route to host)) |
| 14:30:04 | stripwax | so the same code on pp502x should work on gigabeatF I would have thought. Odd that codeclib isn't using the arm code in that case. |
| 14:30:28 | stripwax | maybe it's just mdct2.c actually, not sure. |
| 14:31:15 | amiconn | Either it's an oversight, or the C code is faster on the F |
| 14:31:30 | stripwax | Oh! hah, the S3C2440 is explicitly compiled from C, from a #if right at the top of mdct2.c |
| 14:31:38 | amiconn | While ARM7TDMI and ARM920T are both ARMv4, instruction timing is different |
| 14:32:03 | amiconn | ARM9 has better pipelining |
| 14:32:58 | stripwax | Oh, I thought the pipeline was part of the 'v' version - v4 with 3 stage and v5 with 5 stage - but if that's ARM7 vs ARM9 rather than v4 vs v5 then that makes sense |
| 14:33:15 | stripwax | But is that the only ARM9 cpu in rockbox? |
| 14:33:32 | amiconn | no |
| 14:33:39 | stripwax | so it's still odd then .. |
| 14:33:47 | amiconn | The AMS targets are all ARM9 (v4) as well |
| 14:34:04 | amiconn | There are a few ARM9 (v5) targets, e.g. the Cowon D2 iirc |
| 14:34:29 | funman | Clipv2/Fuzev2 are armv5 |
| 14:35:05 | stripwax | Unhelpful - in fact, didn't you reorder some instructions in mdct_arm.S to try to reduce stalls on ARM9 targets? |
| 14:35:19 | stripwax | probably would be good if someone with a gigabeatF can confirm if C is still faster than asm |
| 14:35:23 | funman | btw i'll mail the AMS guy next week if i have no news from him about the Clipv2/Fuzev2 datasheet |
| 14:35:39 | AlexP | stripwax: If you do me a patch (or tell me what to do) I can test |
| 14:37:10 | amiconn | funman: Eh, are there actually two versions of the AS3525 with different arm core version? |
| 14:37:11 | stripwax | AlexP - one line change :) change the "#if defined(CPU_ARM) blah" line at the top of mdct2.c to be "#if 1" |
| 14:37:21 | AlexP | and then what am I testing for? |
| 14:38:07 | funman | amiconn: no the Clipv2 & Fuzev2 have an AS3531 (newer core for which we don't have the datasheet -yet-), or at least we are sure they use a ARM926-EJS |
| 14:38:17 | stripwax | oh, right :) test_codec runs on any of the mdct codecs (e.g. mp3, vorbis). see if the existing code gives faster decoding speed than the modified code |
| 14:38:25 | AlexP | righto :) |
| 14:38:36 | stripwax | many thanks! |
| 14:38:38 | amiconn | funman: Hmm, but then they should have a different manufacturer sub-dir in target tree... |
| 14:39:08 | funman | amiconn: they are not yet in the target tree ^^ |
| 14:39:21 | amiconn | They are in 'configure'.... |
| 14:39:36 | funman | there is some code for clipv2 on flyspray but i must check how much similarities there is with as3525 before adding them |
| 14:39:55 | funman | configure just errors out if you select them, I needed to reserve a target number for mkamsboot |
| 14:40:41 | stripwax | AlexP - actually, mp3 is a funny one .. so maybe vorbis and wma? or maybe just vorbis? :) |
| 14:41:05 | AlexP | vorbis is fine, I might have a wma somewhere :) |
| 14:42:49 | CIA-43 | New commit by learman (r22529): Don't know why svn decided to delete tlsf/src... Maybe due to some aborted tests I did to see where it would be best to place TLSF. |
| 14:44:20 | funman | ffmpeg -i file.ogg file.wma |
| 14:45:38 | | Quit fyre^OS (Read error: 113 (No route to host)) |
| 14:48:45 | | Join chandoo [0] (n=chandoo@67.83.185.120) |
| 14:53:16 | | Quit Llorean ("Leaving.") |
| 14:54:42 | n1s | stripwax: the mp3 codec doesn't use the mdct in the lib |
| 14:56:24 | n1s | hm, my rtc cleanup seems to be done, just need to testbuild a bit and read through the patch a final time (and then posting it on the tracker and nagging people as i have only one target to test on currently) |
| 14:57:15 | pixelma | which target did you test on? |
| 14:57:24 | n1s | gigabeast |
| 14:58:06 | n1s | so there are 11 other drivers to test |
| 14:58:26 | n1s | if we are going to do them all |
| 14:59:20 | stripwax | n1s - yep, I realised after I posted that |
| 14:59:23 | AlexP | stripwax: As is: Ogg 534.76% 55.41 MHz needed wma 624.70% 47.43 MHz with change: ogg 568.08% 52.16 MHz wma 648.85% 45.67 MHz |
| 14:59:59 | AlexP | stripwax: This was just "speed test" on a single file (for each) in test_codec |
| 15:00 |
| 15:00:01 | stripwax | Seems pretty clear to me. So that #if should be changed to just #if defined(CPU_ARM) without the S3C2440 bit |
| 15:00:17 | stripwax | AlexP - yep, perfect. |
| 15:01:44 | stripwax | AlexP - oh, that's off which build revision by the way? r22527 or something earlier? |
| 15:02:11 | AlexP | stripwax: 22529 |
| 15:02:22 | stripwax | for both runs? |
| 15:02:25 | AlexP | yep |
| 15:02:49 | stripwax | fab. many thanks! I'll commit the change |
| 15:02:57 | AlexP | cool, no worries |
| 15:03:43 | CIA-43 | New commit by stripwax (r22530): C code is NOT faster on S3C2440 - tested by AlexP on r22529 |
| 15:03:52 | stripwax | :) |
| 15:03:59 | AlexP | coolio :) |
| 15:06:37 | stripwax | Lear - does the tremor malloc affect decoding speed much/at all ? |
| 15:06:59 | * | n1s would probably hava edded a "anymore" to that committ message |
| 15:07:12 | n1s | s/a e/e a/ |
| 15:09:16 | n1s | Lear: floor 0 files requireing too much memory should no longer crash, right? |
| 15:09:27 | stripwax | n1s - I thought about it, but to be honest it may have been like that for quite some time |
| 15:09:59 | n1s | well, the opposite was true at one point |
| 15:12:24 | stripwax | true - but we don't know when. I thought if I put 'any more' then people might assume my change has improved GigabeatF, which is (very likely) not the case |
| 15:19:07 | Lear | stripwax: No. Only affects things when starting a new file. |
| 15:19:46 | Lear | n1s: I don't think I tested that... |
| 15:24:58 | stripwax | Anyone know why viewport->fg_pattern and viewport->bg_pattern etc are unsigned ints rather than of type fb_data ? |
| 15:25:41 | stripwax | gcc seems to need to emit instructions to cast from int to fb_data (e.g. lsl 16, lsr 16) in lcd functions such as mono_bitmap_part |
| 15:29:15 | | Join Buschel_ [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) |
| 15:29:49 | | Quit Buschel (Read error: 104 (Connection reset by peer)) |
| 15:30:13 | | Part decayedcell |
| 15:36:23 | | Quit bluebrother (Nick collision from services.) |
| 15:36:28 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 15:46:48 | | Join teru [0] (n=teru@59.133.112.132) |
| 15:49:02 | | Quit moos ("Rockbox rules the DAP world") |
| 15:49:17 | | Join moos [0] (i=mostafa@rockbox/staff/moos) |
| 15:51:58 | | Join kushalone [0] (n=kushal@12.169.180.178) |
| 15:52:17 | | Join Windeh [0] (n=Windlord@cm66.sigma104.maxonline.com.sg) |
| 15:55:49 | | Part Buschel_ |
| 16:00 |
| 16:04:04 | | Quit Windlord (Read error: 110 (Connection timed out)) |
| 16:05:02 | kugel | Lear: do we have tlsf malloc duplicated now? |
| 16:05:48 | * | n1s is confused by one thing in the h100rtc mod rtc driver, a comment says "chip wants century (always 20xx)" and it bitwise OR's the month value with 0x80... |
| 16:05:52 | | Quit Windeh ("http://windlord.co.cc/") |
| 16:06:28 | Lear | kugel: At the moment, yes. I plan to make pdbox use the codec copy. Didn't want to include it in this commit though. |
| 16:06:34 | kugel | stripwax: probably because we also accapt RGB888 as input on color (settings, viewport definitions in wps/ui viewport, color picker) |
| 16:06:55 | kugel | Lear: alright, duplication sucks a bit :) |
| 16:08:05 | stripwax | kugel - yep, that's probably it. plus it turns out the gcc code is actually quite clever even though I personally disagree with it :) |
| 16:11:50 | kugel | no, color picker is actually using RGB565 |
| 16:16:09 | *** | Saving seen data "./dancer.seen" |
| 16:18:19 | | Quit moos (Read error: 131 (Connection reset by peer)) |
| 16:18:28 | | Join moos [0] (i=mostafa@rockbox/staff/moos) |
| 16:21:11 | stripwax | kugel - hrm. must be some other reason then |
| 16:21:28 | kugel | well, settings and viewports still accept rgb888 |
| 16:22:20 | | Join Strife89 [0] (n=michael@adsl-220-104-59.mcn.bellsouth.net) |
| 16:22:40 | stripwax | gotcha |
| 16:24:07 | stripwax | although assumption is that current_vp->fg_pattern is always RGB565 anyway (=or at least, assumption in lcd-16bit.c is that it is in same format as framebuffer). so we must be converting before we store it in current_vp anyway. must be some other reason why it's an int in current_vp ... |
| 16:26:10 | kugel | amiconn or linuxstb (he committed the driver level viewports) probably now |
| 16:26:55 | pixelma | could the shades in greyscale viewports have anything to do with it? |
| 16:27:19 | kugel | native data type is generally faster, but that might outweight if exessive casting to fb_data is needed |
| 16:28:37 | kugel | stripwax: I was wondering the same about the coordinates, many other places are using shorts for those also |
| 16:31:25 | | Quit flydutch ("/* empty */") |
| 16:33:28 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 16:33:42 | CIA-43 | New commit by teru (r22531): Clear screen when leave usb screen so that usblogo doesn't remain on the screen. |
| 16:35:44 | kugel | teru: the GUI_EVENT_REFRESH should be used for those cases |
| 16:36:37 | kugel | because a) it's only active if ui vp is actually used and b) it redraws the statusbar |
| 16:39:52 | | Quit kushalone (Client Quit) |
| 16:42:04 | teru | kugel: clear_display and update are used when displaying usblog. i don't think it cause problem. |
| 16:42:07 | CIA-43 | New commit by kugel (r22532): Quickscreen: 4th item ... |
| 16:42:47 | kugel | teru: this event is specifically made for those cases in conjunction with the ui vp |
| 16:45:23 | kugel | especially due to the statusbar thing. just clearing and updating will make it disappear |
| 16:49:49 | PaulJam | kugel: nice work on the custom statusbar patch! i'm going to test this out later. i was wondering, is the patch you posted on the tracker the latest version? (i can't acess the link to the git repo you posted.) |
| 16:50:33 | kugel | repo.or.cz seems down |
| 16:51:04 | kugel | PaulJam: looking at git log, yes it is the latest version :) |
| 16:52:23 | PaulJam | thanks |
| 16:54:57 | | Join kushalone [0] (n=kushal@12.169.180.178) |
| 16:56:18 | | Quit panni_ (Read error: 113 (No route to host)) |
| 16:57:25 | CIA-43 | New commit by teru (r22533): keybox: fix issue when deleted all items. |
| 16:58:00 | | Quit dmb (Read error: 113 (No route to host)) |
| 17:00 |
| 17:04:27 | n1s | hmm, what's the policy on which targets we provide current builds for? mrobe500 has a link on the current build page but the gigabeast doesn't, both are unsupported and built by the buildsystem |
| 17:08:51 | | Join MG_Man [0] (n=MGMan@97.101.208.11) |
| 17:09:01 | | Join saratogahome [0] (n=463f90ed@gateway/web/cgi-irc/labb.contactor.se/x-cpjbjikmsdgdfohw) |
| 17:09:26 | saratogahome | great to see that the F can now use the ASM code for IMDCT |
| 17:11:04 | | Nick TheSeven is now known as Nanotron-TheSeve (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 17:11:23 | | Nick Nanotron-TheSeve is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 17:12:05 | | Nick TheSeven is now known as TheSevenTron (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 17:12:17 | | Nick TheSevenTron is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 17:17:18 | CIA-43 | New commit by kugel (r22534): More fixes for the usb screen: Use send_event(GUI_EVENT_REFRESH, NULL) to get rid of dead parts if the custom ui viewport is used as intended (it also ... |
| 17:18:25 | MG_Man | Oh damn, I knew I forgot something |
| 17:18:57 | MG_Man | 1. I was going to add a border to my backdrop for use with a custom ui viewport |
| 17:19:28 | MG_Man | And 2. I forgot to add conditionals for track/alubm/artists names to say something else if it was unknown |
| 17:21:03 | kugel | MG_Man: fix it and tell us when you're done so we can delete your theme to enable you to re-upload |
| 17:21:08 | MG_Man | Ok |
| 17:21:12 | MG_Man | It shouldnt take long |
| 17:21:48 | | Join biengo [0] (n=quassel@xdsl-213-196-250-156.netcologne.de) |
| 17:22:17 | CIA-43 | New commit by kugel (r22535): Move a line up into the existing FOR_NB_SCREENS loop and add a comment. |
| 17:22:17 | saratogahome | stripwax: how much of an improvement did your changes make? |
| 17:23:05 | | Join _zic [0] (n=user@91.165.248.215) |
| 17:24:45 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 17:31:44 | AlexP | saratogahome: The mdct asm/c change? |
| 17:31:51 | AlexP | saratogahome: If so, [14:59:23] <AlexP> stripwax: As is: Ogg 534.76% 55.41 MHz needed wma 624.70% 47.43 MHz with change: ogg 568.08% 52.16 MHz wma 648.85% 45.67 MHz |
| 17:32:33 | teru | weird. it seems gui_wps_show in apps/gui/wps.c is expected to return GO_TO_* but it returns SYS_USB_CONNECTED under particular circumstances. |
| 17:34:55 | | Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) |
| 17:38:10 | CIA-43 | New commit by teru (r22536): Calendar: change directory to store .memo file from /.rockbox/ to /.rockbox/rocks/apps/ for the consistency with other plugins. move the file manually ... |
| 17:40:17 | MG_Man | Okay, conditionals fixed, now just gotta get the new backdrop and ui viewport |
| 17:42:10 | | Quit kushalone (Client Quit) |
| 17:43:59 | stripwax | saratoga - AlexP's numbers are for enabling the asm mdct on gigabeat F. I didn't (don't) have numbers for the asm changes I made. Probably small, but I figure removing instructions from mdct is always good |
| 17:44:16 | stripwax | i.e. can't slow anything down |
| 17:46:34 | CIA-43 | New commit by kugel (r22537): Make UI viewport handling more multiscreen aware and bring a break; accidentally back lost in a previous commit (r22485). |
| 17:46:54 | * | kugel swaps accidentally and back :S |
| 17:48:35 | | Join fml [0] (n=4fd3dc7a@gateway/web/cgi-irc/labb.contactor.se/x-myigfprcvlmlplbj) |
| 17:48:39 | saratogahome | stripwax: have you ever profiled AAC-HE? |
| 17:49:18 | saratogahome | I think it can be made a lot faster |
| 17:50:18 | fml | AlexP: hello! I can't build the RB manual. Can you? I have r22537. |
| 17:52:03 | stripwax | saratoga - no, but I can add it to the queue :) mt asked for atrac profiling first :) |
| 17:52:34 | AlexP | fml: Which target? I just tried the beast and it seems fine |
| 17:52:39 | saratogahome | stripwax: i have a very good idea how much most of the ATRAC functions used |
| 17:52:53 | stripwax | saratoga - would you say you have a feel for why wma is somewhat significantly faster than vorbis, by the way? |
| 17:52:55 | saratogahome | i commented most of them out while testing and recorded the run time |
| 17:53:05 | saratogahome | stripwax: its a much simplier codec |
| 17:53:06 | stripwax | oh ok |
| 17:53:06 | fml | AlexP: H120 |
| 17:53:41 | stripwax | although commenting them out isn't a very good way of profiling, since you have a processing pipeline that will change when you comment stuff out :) |
| 17:54:05 | AlexP | fml: The pdf builds fine here, just trying html |
| 17:54:32 | saratogahome | WMA is the fast ffmpeg huffman decoder, maybe 4 multiplies per sample for requantization and stereo decoding, then the MCDCT library, then the ASM dewindowing code |
| 17:55:04 | saratogahome | its a transform codec stripped to its core |
| 17:55:23 | AlexP | fml: html fine too |
| 17:55:23 | | Join TopyMobile [0] (n=topy@g228140131.adsl.alicedsl.de) |
| 17:55:26 | AlexP | fml: What is the error? |
| 17:56:17 | fml | AlexP: I'll make clean first, then try and then tell you |
| 17:56:36 | AlexP | OK |
| 17:57:02 | saratogahome | ATRAC non-QMF is something like 30 MHZ total BTW |
| 17:57:10 | saratogahome | and it could be made much faster |
| 17:57:16 | saratogahome | but the QMF is always going to be slow |
| 17:57:24 | saratogahome | its a good canidate for the COP on PP though |
| 17:57:33 | saratogahome | anyway have to run |
| 17:57:45 | stripwax | ok |
| 17:57:45 | | Quit saratogahome ("CGI:IRC (EOF)") |
| 17:58:51 | fml | AlexP: no luck after clean. ! Misplaced \noalign. l.453 \end{btnmap}. I think it's in iriver_istall.tex |
| 17:59:09 | AlexP | weird, I wonder why I don't get it |
| 18:00 |
| 18:00:33 | MG_Man | I think I'll just go without a viewport ui |
| 18:00:39 | fml | AlexP: same for e200 |
| 18:00:51 | AlexP | fml: In a new build directory too? |
| 18:00:54 | MG_Man | It looks wrong when used in say 3.2 and such where it isn't supported, and some people may not have the latest build |
| 18:01:02 | MG_Man | Plud it doesnt really look any different/better |
| 18:01:15 | MG_Man | Not for my theme, at least |
| 18:02:01 | AlexP | fml: e200 manual builds fine here.... Very odd |
| 18:02:58 | fml | AlexP: same (can't build) for the recorder in a fresh new build dir. Really weird! |
| 18:04:18 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 18:04:39 | AlexP | fml: The pdf seems not to have built on the server last night |
| 18:05:05 | AlexP | fml: I suspect my \ifpdfoutput changes in r22522 |
| 18:05:19 | AlexP | fml: But I'm a bit stuck trying to fix it as it works here |
| 18:06:09 | | Quit AndyIL (Read error: 60 (Operation timed out)) |
| 18:06:28 | AlexP | fml: Could you revert that and try again? The trouble is that without those changes, the html doesn't build :/ |
| 18:07:17 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 18:07:38 | fml | AlexP: how do I revert? svn up -rnnnnnn? |
| 18:08:12 | AlexP | yes, I think so |
| 18:08:36 | fml | AlexP: why did you put the ifpdf's where they are used and not in the definitions of rbxxxrule? Didn't it work that way? |
| 18:08:56 | AlexP | fml: er, a good point :) |
| 18:09:16 | AlexP | fml: That sounds like the better way of doing it |
| 18:09:55 | AlexP | fml: Perhaps see if that works properly? |
| 18:10:28 | fml | AlexP: r22521 (PDF manual) builds fine here |
| 18:10:33 | MG_Man | Alright, all fixed |
| 18:10:37 | AlexP | fml: OK, so it must be that |
| 18:10:48 | MG_Man | I'll need the old one (BoxAmp in H300/iPod Color) |
| 18:10:54 | MG_Man | need the old one deleted first* |
| 18:11:28 | AlexP | fml: Could you try changing the \ifpdfoutput to the definitions and see if it works? I could do, but it builds for me at present :/ |
| 18:11:42 | AlexP | MG_Man: One moment |
| 18:11:50 | MG_Man | Thank you |
| 18:12:26 | AlexP | MG_Man: OK, deleted it |
| 18:12:31 | MG_Man | Thank you |
| 18:12:35 | MG_Man | Re uploading it now |
| 18:13:15 | fml | AlexP: I tried and doesn't work for me. Tex is tricky! I think \opt and\nopt get in the way. |
| 18:14:48 | fml | I tried just to change \rbtoprule (added ifpdfoutput with just \hline in the else case) and it doesn't biuld |
| 18:15:56 | AlexP | huh |
| 18:16:03 | | Quit faemir ("Leaving") |
| 18:16:11 | *** | Saving seen data "./dancer.seen" |
| 18:16:21 | AlexP | It is very odd that it builds fine here though - I wonder what the difference is |
| 18:16:22 | fml | AlexP: agreed! :-) |
| 18:17:24 | AlexP | fml: The curious thing is that the html output seems to be building fine on the server with current svn - does it work for you? |
| 18:17:25 | fml | tex and latex are so highly standardized that it can't be the reason (the program itself) |
| 18:17:42 | fml | AlexP: how do I build html? |
| 18:19:56 | AlexP | make manual-html |
| 18:21:29 | fml | AlexP: I use ubuntu. What package do I need to get htlatex? |
| 18:22:05 | AlexP | tex4ht |
| 18:22:09 | AlexP | I think :) |
| 18:25:06 | CIA-43 | New commit by teru (r22538): fix FS #10465 and return GO_TO_ROOT instead of SYS_USB_CONNECTED in gui_wps_show. |
| 18:25:11 | fml | AlexP: HTML works. But PDF still does not. |
| 18:26:13 | pixelma | I can confirm this (except the html part) |
| 18:26:53 | pixelma | the PDF doesn't build for me either |
| 18:26:59 | AlexP | fml: OK, so we need to think of a better way to do r22522 - as without those changes, html doesn't build |
| 18:27:15 | AlexP | pixelma: Really oddly, it does here |
| 18:29:20 | AlexP | well, I'll have a play but it is a bit difficult for me as it already works, so if I change stuff I don't know whether it'll have fixed it or not |
| 18:31:24 | | Join daurn| [0] (n=daurnima@ppp118-208-191-102.lns10.mel4.internode.on.net) |
| 18:31:38 | fml | Sorry, I have to leave |
| 18:31:40 | | Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") |
| 18:34:53 | | Quit daurn (Read error: 60 (Operation timed out)) |
| 18:36:43 | CIA-43 | New commit by kugel (r22539): Respect UI viewport per screen in viewport_set_defaults() also. |
| 18:39:29 | | Join domonoky1 [0] (n=Domonoky@g229116098.adsl.alicedsl.de) |
| 18:40:56 | pixelma | AlexP: I can't even build a PDF from r22521 (cygwin) |
| 18:42:20 | AlexP | pixelma: I wonder if that is due to fml's changes to the mid,top,bottom rules in r22516 |
| 18:42:28 | AlexP | Could you try 22515? |
| 18:43:55 | pixelma | sure |
| 18:47:54 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 18:49:30 | | Quit teru ("Quit") |
| 18:50:19 | | Quit funman ("free(random());") |
| 18:53:12 | | Quit Strife89 ("Leaving") |
| 18:54:56 | | Quit domonoky (Read error: 110 (Connection timed out)) |
| 18:58:43 | pixelma | AlexP: yes 22516 breaks it for me (tested both revisions) |
| 18:58:51 | AlexP | pixelma: OK |
| 19:00 |
| 19:00:04 | AlexP | pixelma: 22516 makes the header "box" a bit bigger - seeing as it seems to break pdf (and probably html) on cygwin and html on linux, maybe it is worth reverting that and trying to find a different way |
| 19:01:12 | pixelma | I agree |
| 19:02:24 | AlexP | OK, I'll revert it for now and fml can try and weave some slightly different magic :) |
| 19:02:45 | MG_Man | There, theme reuploaded |
| 19:04:12 | | Quit biengo (Remote closed the connection) |
| 19:04:14 | n1s | ok, rtc cleanup now posted in FS #10569, test! |
| 19:05:38 | saratoga | apparently WMA Lossless reverse engineering has begun over at ffmpeg |
| 19:05:49 | saratoga | we just need that and WMA pro and we can can complete our codecs I think |
| 19:08:45 | | Join Tsumugi [0] (n=Mugi@216.218.195.106) |
| 19:10:10 | * | stripwax mumbles something sarcastic about DRM .. ;) |
| 19:11:19 | stripwax | Would it make sense to make some of that asm volatile in the codeclib to be just 'asm' and encourage gcc to do the optimal reordering for the platform? |
| 19:11:27 | bertrik | n1s, I'll test on ams sansa and sansa v1 |
| 19:13:18 | AlexP | pixelma: Could you test http://pastebin.com/m574eff4 please? |
| 19:14:06 | n1s | bertrik: great! |
| 19:15:07 | Tsumugi | is it appropriate to ask a user interface question here, or should i poke the community channel? |
| 19:16:17 | AlexP | Tsumugi: If it about the Rockbox UI, then here :) |
| 19:16:22 | AlexP | *is about |
| 19:17:09 | Tsumugi | i'm wondering if there is a way to go from the "now playing" view to the "playlist" view directly? (on an ipod running rockbox, of course) |
| 19:17:34 | kugel | fucking "nothing to resume" splash :S |
| 19:17:47 | AlexP | Hold select to get the context menu, then select playlist, then view playlist |
| 19:18:13 | AlexP | There isn't a one click way of getting there that I know of |
| 19:18:30 | AlexP | (although I think there is a patch for this) |
| 19:18:40 | Tsumugi | yeah, i knew that way −− oh? |
| 19:18:55 | AlexP | Have a look on flyspray (I might be misremembering) |
| 19:19:13 | AlexP | Although even if there is that means you will need to patch the source code then compile your own build |
| 19:19:30 | Tsumugi | i probably should rtfc, but are those connections "hard coded" or are they in the UI config files? |
| 19:19:45 | AlexP | You would need to change the source code |
| 19:19:49 | Tsumugi | okay |
| 19:20:19 | Tsumugi | i'm guessing there's a nice section on setting up a cross compiler on the web, so i'll head there =) thanks! |
| 19:20:28 | AlexP | Tsumugi: Are you on linux? |
| 19:20:40 | Tsumugi | i can be! |
| 19:20:50 | AlexP | It is easier of you are :) |
| 19:21:28 | AlexP | Check the source out of svn, then run tools/rockboxdev.sh |
| 19:21:41 | AlexP | It'll patch and build the cross compilers for you |
| 19:21:48 | Tsumugi | wow, awesome |
| 19:22:32 | AlexP | svn co svn://svn.rockbox.org/rockbox/trunk rockbox |
| 19:23:05 | AlexP | That command is an exercise into how to fit the most mentions of "rockbox" into one line :) |
| 19:23:27 | Tsumugi | haha |
| 19:23:37 | * | Tsumugi adds && cd rockbox for one more ;) |
| 19:23:42 | AlexP | good work :) |
| 19:24:23 | | Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
| 19:25:41 | | Quit TopyMobile (Remote closed the connection) |
| 19:27:14 | bertrik | n1s, on my e200(v1) the time is still correct with the patch, also the day-of-week in calender is correct |
| 19:41:03 | CIA-43 | New commit by kugel (r22540): Fix up statusbar handling in the usb screen a bit more, using the GUI_EVENT_ACTIONUPDATE event instead of direct draw (with the custom statusbar patch ... |
| 19:42:48 | | Join Ubuntuxer [0] (n=johannes@dslb-094-220-225-034.pools.arcor-ip.net) |
| 19:44:50 | | Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) |
| 19:54:49 | | Join Buschel [0] (n=AndreeBu@p54A3D493.dip.t-dialin.net) |
| 20:00 |
| 20:02:58 | kugel | AlexP, pixelma (and other manual guys): does that look fine to you http://pastie.org/598925 ? |
| 20:04:19 | AlexP | kugel: is party mode in playback settings so it can be referenced like the other settings? |
| 20:04:19 | Unhelpful | amiconn: i know. the offsets table needs fixing, too. i could just go through the whole lot with htole* before writing it out, that seems easiest... |
| 20:04:31 | kugel | I didn't find a reference |
| 20:04:45 | AlexP | OK |
| 20:05:11 | AlexP | I find the second paragraph rather confusing - I'll try and propose an alteration :) |
| 20:05:32 | kugel | maybe s/"Please note that each opposite direction inverts the direction the setting is toggled through."/"Please note that each item inverts the direction the setting is toggled through compared to its opposite item"/? |
| 20:06:05 | kugel | modify as you like and re-paste :) |
| 20:06:11 | saratoga | Buchel: you're concerned that accumulating into a 32 bit buffer in the IQMF isn't accuarate enough? |
| 20:07:03 | Unhelpful | kugel: "Unhelpful: some 14px don't work" <- does this mean that at least *some* fonts work now? :D |
| 20:07:22 | bluebrother | party mode as default in the quickscreen? Bad idea. |
| 20:07:24 | kugel | type, apparently |
| 20:07:27 | kugel | typo |
| 20:07:41 | bluebrother | why not make the quickscreen behave as now and make the "up" item the opposite of "down"? |
| 20:07:53 | kugel | Unhelpful: what are you referring to? |
| 20:08:21 | | Quit Ubuntuxer (Read error: 110 (Connection timed out)) |
| 20:08:25 | Unhelpful | ...to what you said about 6hr or so ago? |
| 20:08:34 | Buschel | saratoga: no, the accumulation is fine but only for the asm'ed part. The C-code does accumulate into 16 bit. |
| 20:08:51 | kugel | Unhelpful: ah I thought it was about my qs commit |
| 20:08:57 | kugel | yea, some fonts work |
| 20:09:05 | kugel | although scrolling is buggy |
| 20:09:06 | Buschel | saratoga: And the iqmf is 2-staged. So, the (16 bit precision) results of the first stage are the input for the second stage. |
| 20:09:13 | soap | kugel, not to take you too far off topic - but what ever happened to FS #10156? |
| 20:09:28 | kugel | the glyph that enters the scrolling margin is a bit corrupted |
| 20:09:39 | saratoga | how do you figure its 16 bit? |
| 20:09:45 | AlexP | kugel: Something like "Please note that the settings at opposite sides of the screen cycle through the available options in opposite directions. Therefore if you have the same setting at the top and bottom of the quickscreen, then pressing up and down will cycle through this setting in opposite directions." maybe? |
| 20:10:09 | kugel | soap: no idea, I never understood entirely what the problem was about |
| 20:10:40 | kugel | most of what the task is about is in SVN, but the initial problem (which is apparently ultra unlikely to ever happen) appears to be still there |
| 20:10:47 | saratoga | it looks to me like fixmul31 returns the top 32 bits and those are accumulated into a 32 bit buffer |
| 20:11:30 | Buschel | saratoga: 1st -> there is no scaling when truncating to int16_t. |
| 20:11:50 | AlexP | bluebrother: Weirdly my fix for the html last night breaks the pdf for everyone except me |
| 20:12:03 | soap | I was just going through my old FS watch list and that one seemed to die off unexpectedly. |
| 20:12:04 | Buschel | saratoga: 2nd -> change in decoing speed when making the samples the second operand in smull/smlal |
| 20:12:21 | AlexP | bluebrother: Given that the original commit that this is trying to fix also breaks cygwin I think I'll just revert that for now |
| 20:12:24 | Buschel | saratoga: the samples are int32_t but the upper 16 bits are not significant |
| 20:12:46 | Buschel | saratoga: btw, just reached 69 MHz :o) |
| 20:12:51 | | Quit PaulJam (Read error: 113 (No route to host)) |
| 20:12:57 | Unhelpful | kugel: on what target are you testing? |
| 20:13:00 | saratoga | Buschel: which code are you refering to? i can't find any int16_t |
| 20:13:02 | kugel | e200 and fuze |
| 20:13:08 | stripwax | which codec? |
| 20:13:17 | saratoga | atrac3 |
| 20:13:54 | AlexP | bluebrother: The original commit was to make the top and mid rules leave a bit more room for the header so it wasn't so cramped, but that broke cygwin, and html on linux. I fixed the html on linux with the \ifpdfoutput we talked about last night, but in doing so broke pdf on linux (except for me, which is weird). |
| 20:14:10 | Buschel | saratoga: search for calls of av_clip_in16 in atrac.c |
| 20:14:24 | Unhelpful | hrm. e200 works fine for me :/ |
| 20:14:59 | saratoga | Buschel: its only called after the IQMF unless I am missing something? |
| 20:15:03 | stripwax | av_clip_int16 should use CLIP_TO_15 from lib |
| 20:16:12 | *** | Saving seen data "./dancer.seen" |
| 20:17:04 | Buschel | saratoga: yes, but the 2nd reason is still valid. and also there is no shifting within the iqmf which would eliminate any exisiting fract part |
| 20:17:38 | stripwax | also atrac3 fixp_math doesn't use the lib for fixmul31? |
| 20:17:59 | saratoga | stripwax: see FS #10565 |
| 20:17:59 | | Quit Buschel (Read error: 104 (Connection reset by peer)) |
| 20:18:03 | | Join Buschel [0] (n=AndreeBu@p54A3D493.dip.t-dialin.net) |
| 20:18:05 | kugel | AlexP: that works also |
| 20:18:21 | * | Buschel slaps his wlan stick.... |
| 20:18:36 | stripwax | ah! :) |
| 20:18:50 | Buschel | stripwax: the clip16 stuff should not be used in libatrac at all. this should only be handled by the dsp-rotuines |
| 20:18:55 | Buschel | *routines |
| 20:19:03 | AlexP | kugel: I'll just commit something here to make the manuals actually build again |
| 20:19:15 | saratoga | Buschel: you're talking about the "s1 += fixmul31(p1[i], qmf_window[i]);" lines in iqmf() right? |
| 20:19:27 | stripwax | oh, because we output signed 32bit rather than signed 16bit from codec? |
| 20:19:37 | kugel | AlexP: I was refering to your suggestion about the text |
| 20:19:48 | saratoga | yes ideally each codec should output 32 bit samples but some don't and that should be fixed |
| 20:19:57 | AlexP | kugel: I know, but until I commit this you can't build the manual to test it :) |
| 20:20:00 | Buschel | stripwax: yes. and the codec tells the dsp-routines what exact format is used |
| 20:20:00 | stripwax | I'm pretty sure cook does clip16 also |
| 20:20:01 | saratoga | cook does the same thing but when i changed it the codec would crash for reasons I don't understand |
| 20:20:13 | stripwax | jinx |
| 20:20:34 | kugel | indeed |
| 20:20:36 | Buschel | saratoga: the same happened to me. something to fix in future... |
| 20:21:00 | saratoga | in cook? theres probably some underlying problem we're missing then |
| 20:22:34 | Buschel | saratoga: example for the missing fract part: samples use int32_t with al value range of +/-32767. win-coefs use +/-2^31. now they are multiplied and the result is shifted by >>31. the reuslt is a int32_t with a value range of +/-32767. -> 16bit precision. |
| 20:22:58 | saratoga | why are the input values restricted to 16 bits? |
| 20:23:00 | Buschel | saratoga: so, each results of a multiplication is truncated. |
| 20:23:28 | kugel | AlexP: "Please note that opposite items invert the direction a |
| 20:23:28 | kugel | setting is toggled through. Therefore if you have the same setting at the top |
| 20:23:28 | kugel | and bottom for example, then pressing up and down will cycle through |
| 20:23:28 | DBUG | Enqueued KICK kugel |
| 20:23:28 | kugel | this setting in opposite directions."? |
| 20:23:33 | kugel | gah |
| 20:23:52 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 20:23:57 | AlexP | kugel: Sounds a little stilted, one mo |
| 20:24:29 | kugel | most if it are your words! |
| 20:25:04 | bluebrother | AlexP: that's strange. |
| 20:25:22 | Buschel | saratoga: is there any reason that the sign of the window_lookup table is inverted? |
| 20:25:26 | AlexP | bluebrother: indeed it is |
| 20:25:55 | saratoga | Buschel: you'd have to ask MT about that, he computed the table |
| 20:26:00 | saratoga | but my guess is thats just how ffmpeg did it |
| 20:26:15 | Buschel | saratoga: ok, I'll invert them again |
| 20:28:43 | AlexP | kugel: toggle suggests only two options, which isn't true for most settings |
| 20:28:53 | CIA-43 | New commit by alex (r22541): Revert r22516 and r22522 - the former breaks html on linux and evrything on cygwin, the latter fixes html but breaks pdf on linux. Revert and find a ... |
| 20:28:56 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 20:29:36 | | Quit togetic ("WeeChat 0.3.0-rc2") |
| 20:29:54 | AlexP | kugel: "Please note that the settings at opposite sides of the screen cycle through the available options in opposite directions. Therefore if you select the same setting at e.g. the top and bottom of the quickscreen, then pressing up and down will cycle through this setting in opposite directions." ? |
| 20:30:20 | kugel | that seems nice |
| 20:30:54 | kugel | although I'm not sure as to the usage of abbreviations like e.g. in the manual |
| 20:32:44 | AlexP | Why? |
| 20:32:48 | AlexP | It is standard english |
| 20:34:26 | kugel | alright |
| 20:34:41 | | Quit Thundercloud (Read error: 60 (Operation timed out)) |
| 20:36:14 | bluebrother | e.g. is a latin abbreviation btw. |
| 20:36:30 | AlexP | yes, but still standard english :) |
| 20:36:40 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 20:36:45 | AlexP | f.e. which people sometimes use to mean e.g. isn't English |
| 20:36:53 | bluebrother | yes, but you wouldn't want to write the latin words. That was my point :) |
| 20:36:58 | AlexP | indeed so :) |
| 20:37:10 | bluebrother | same as i.e. :) |
| 20:37:14 | AlexP | yep :) |
| 20:37:19 | kugel | AlexP: alert me once the manual builds again |
| 20:37:31 | AlexP | kugel: It should do now |
| 20:37:41 | kugel | oh there was a commit! |
| 20:38:03 | AlexP | I hope it works :) |
| 20:38:55 | | Quit petur (Remote closed the connection) |
| 20:39:14 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 20:39:30 | kugel | works |
| 20:39:33 | AlexP | cool |
| 20:39:36 | CIA-43 | New commit by kugel (r22542): Update the manual to reflect the recent addition of the 4th item to the quickscreen.. |
| 20:40:27 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 20:40:27 | * | bluebrother still thinks that having party mode in the quick screen is a bad idea |
| 20:40:54 | bluebrother | party mode caused quite some confusion in the past, having it more present is calling for problems. |
| 20:40:57 | * | goffa__ agrees |
| 20:41:10 | AlexP | I never quite got the point of party mode at all :) |
| 20:41:26 | AlexP | kugel: What about the default mirroring the bottom setting? |
| 20:41:42 | bluebrother | furthermore, I'd *really* appreciate not changing the old behaviour, i.e. making the "up" button the same as it did before: the same as "down" but inversed |
| 20:41:58 | AlexP | Then it acts like it does now for those that want that, and provides a nice example of how to do the mirroring |
| 20:42:09 | kugel | I don't object anything in that regard |
| 20:42:13 | * | bluebrother points out that he said that earlier |
| 20:42:15 | pixelma | more ways to set your file view to playlists? |
| 20:42:17 | kugel | I don't use the defaults whatsoever anyway |
| 20:42:27 | AlexP | bluebrother: Ah, well in that case - great minds etc. :) |
| 20:42:57 | bluebrother | AlexP: or simply people who did manual work −− and noticed at least some of the usual user gotchas :) |
| 20:43:11 | AlexP | hehe :) |
| 20:43:32 | kugel | the old behavior often led to accidentally changing the file filter, that's why I changed it. But now that the top item (and the manual) actually indicates what it does, the problem is probably disappeared anyway |
| 20:44:07 | bluebrother | I only used the quickscreen for changing the file view setting ... |
| 20:44:23 | kugel | you can still do that |
| 20:45:09 | bluebrother | well, the point was simply that it was the only use the quickscreen had for me, so I never accidentially changed that setting using the quickscreen ... |
| 20:45:30 | CIA-43 | New commit by kugel (r22543): Add the select button as exit button for the e200's quickscreen, and update the manual (fuze entry was not wrong also). |
| 20:45:51 | * | bluebrother looks at the average build speeds and is impressed −− looks pretty much unpredictable :o |
| 20:46:26 | kugel | so if everyone wants file view as default top item, go for it, I really don't object |
| 20:47:49 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 20:52:44 | kugel | nobody wants to do it, apparently? |
| 20:52:56 | bluebrother | I'm about to change it. |
| 20:52:59 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 20:53:02 | kugel | ah fine |
| 20:53:20 | kugel | else I would've changed in a few mins |
| 20:53:30 | pixelma | bluebrother, AlexP: btw. r22516 broke PDF building on cygwin in a very weird way. Usually compiling stops at a line with an error and I'm asked what to do, with this the process just hung in /rockbox_interface/main.tex (I guess at the first table) running the CPU at full power, pressing Ctrl-C gave me the question what to do, pressing q - "ok, entering batch mode" and another hang there |
| 20:53:48 | pixelma | AlexP: it's really fixed now :) |
| 20:53:54 | bluebrother | I'm just waiting for my box to finish that build to ensure there's no typo or similar. Takes a bit on this machine. |
| 20:54:08 | AlexP | pixelma: It was very odd all round |
| 20:54:34 | AlexP | bluebrother: What is really weird is that 22522 built absolutely fine for me, but broke for everyone else |
| 20:54:41 | * | bluebrother wonders if the manual build hangs he experienced yesterday are related to that issue −− or to his gpp experiments |
| 20:55:04 | pixelma | AlexP: did the gigabeat manual build for you too while it was broken? |
| 20:55:05 | AlexP | I'll just wait until bluebrother finishes rewriting the manual in ASM :) |
| 20:55:20 | AlexP | pixelma: not the F, but that was a different issue |
| 20:55:39 | AlexP | pixelma: I only tested the S, assuming it would be the same |
| 20:55:43 | * | bluebrother remembers to change the manual too |
| 20:55:44 | pixelma | I know, just thought there might be something weird about your setup |
| 20:55:55 | CIA-43 | New commit by Domonoky (r22544): rbutil: dont write logfile if user aborts filename selection. |
| 20:56:08 | AlexP | pixelma: The difference is texlive vs tetex I guess, but why, I don't know |
| 20:56:18 | pixelma | AlexP: does the S already support the remote/and or is this enabled in the manual? |
| 20:56:25 | AlexP | pixelma: yes and yes |
| 20:57:42 | pixelma | which of the two packages do you use? |
| 20:57:56 | AlexP | texlive, tetex isn't available anymore for Arch |
| 20:58:28 | pixelma | hmm |
| 21:00 |
| 21:03:19 | | Nick dys` is now known as dys (n=andreas@95.115.76.241) |
| 21:03:30 | CIA-43 | New commit by bluebrother (r22545): Replace "Party Mode" as Quickscreen top item with "Show Files" to get the old behaviour as default and prevent accidential enabling of party mode. |
| 21:10:29 | | Quit T44 (Read error: 104 (Connection reset by peer)) |
| 21:10:43 | | Join Topy [0] (i=Topy44@f049085172.adsl.alicedsl.de) |
| 21:11:04 | | Join mrkiko [0] (n=mrkiko@host113-30-dynamic.0-87-r.retail.telecomitalia.it) |
| 21:17:33 | bluebrother | AlexP: why do you want the manual in asm? |
| 21:17:48 | AlexP | bluebrother: I don't, it was just a joke :) |
| 21:18:19 | bluebrother | hehe ... but seriously, I might get this gpp thing running. |
| 21:18:49 | AlexP | That'd be cool (and would hopefully lead to me learning something new) |
| 21:22:05 | kugel | bluebrother: do you have a link to their site? I googled and all I got was the wikipedia article, which is about preprocessing in general (the rest was useless stuff like Government Purchasing Project) |
| 21:22:22 | kugel | oh I think I found it |
| 21:31:31 | CIA-43 | New commit by kkurbjun (r22546): Add stride defines to support vertical strides |
| 21:31:36 | | Quit BHSPitMonkey (Remote closed the connection) |
| 21:33:29 | MG_Man | One thing I wondered about the H300 |
| 21:33:35 | MG_Man | Video playback is 10FPS on the original firmware |
| 21:33:39 | MG_Man | Is it the same for Rockbox? |
| 21:33:55 | Buschel | saratoga: anything speaking against submitting the current state of atrac optimization? |
| 21:34:18 | AlexP | MG_Man: http://www.rockbox.org/twiki/bin/view/Main/PluginMpegplayer#Performance |
| 21:34:40 | AlexP | although that is quite out of date |
| 21:36:31 | MG_Man | Gee |
| 21:36:42 | MG_Man | How ironic that the iPod COlor does videos better than the Video :P |
| 21:36:47 | MG_Man | I assume it's the resolution |
| 21:37:10 | AlexP | yes, but it only does as we don't use the dedicated video processor in the video |
| 21:38:05 | MG_Man | I guessthe only way to tell for sure is to try it |
| 21:38:19 | MG_Man | I don't know if the simulator emulates the DAP's CPU though |
| 21:38:44 | AlexP | no, it is a simulator not emulator |
| 21:38:50 | AlexP | and try what? |
| 21:39:49 | CIA-43 | New commit by kkurbjun (r22547): Correct superdom conflict |
| 21:44:30 | CIA-43 | New commit by Buschel (r22548): Submit interim version of FS #10565. Performance optimization of atrac3 decoder for ARM. Introduce ASM routines for multiplications and two synthesis ... |
| 21:45:53 | | Quit Res1 (Read error: 54 (Connection reset by peer)) |
| 21:50:22 | | Join Res1 [0] (n=Res@user-0c6s6hp.cable.mindspring.com) |
| 21:51:00 | * | bluebrother hands Buschel 1560 points :) |
| 21:51:45 | Buschel | always the sim... |
| 21:52:11 | kugel | what, you only test on target????? :D |
| 21:53:50 | * | Buschel is bad bad guy :) |
| 21:57:23 | CIA-43 | New commit by Buschel (r22549): fix red |
| 21:58:20 | | Join GeekShado_ [0] (n=Antoine@138.228.192-77.rev.gaoland.net) |
| 21:58:20 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 21:59:58 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 22:00 |
| 22:05:25 | bluebrother | looks like the gpp stuff is actually working. At least it doesn't seem to scramble the manual anymore :) |
| 22:06:05 | | Quit amiconn (Nick collision from services.) |
| 22:06:07 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 22:06:15 | | Quit pixelma (Nick collision from services.) |
| 22:06:17 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 22:06:29 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 22:06:35 | kugel | awesome |
| 22:06:36 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 22:06:47 | kugel | it is compatible to config*.h also? |
| 22:08:15 | bluebrother | not yet. The first goal was to get the files preprocessed at all. Now to do something useful during preprocessor run ... |
| 22:08:56 | | Quit kugel (Remote closed the connection) |
| 22:10:07 | n1s | bertrik: thanks for testing :) |
| 22:10:48 | bertrik | n1s, just 11 more drivers to test ... :P |
| 22:11:53 | n1s | yes :) |
| 22:12:12 | bluebrother | n1s: that RTC thing? Is it on FS? |
| 22:12:30 | n1s | well, i tested the mc13783 driver |
| 22:12:33 | n1s | bluebrother: yes |
| 22:15:32 | | Quit GeekShadow (Read error: 110 (Connection timed out)) |
| 22:16:16 | *** | Saving seen data "./dancer.seen" |
| 22:19:28 | AlexP | bluebrother: excellent :) |
| 22:21:24 | n1s | bluebrother: fs#10569 if you haven't found it yet :) |
| 22:21:53 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 22:33:50 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 22:35:27 | | Nick TheSeven is now known as SevenTron (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 22:35:33 | | Nick SevenTron is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) |
| 22:38:55 | bluebrother | n1s: 3 additional targets tested, h100 is broken. I've commented on FS. |
| 22:39:06 | n1s | bluebrother: thanks |
| 22:40:19 | n1s | bluebrother: does the rtc modded h100 work with a recent clean revision? |
| 22:40:23 | kugel | n1s: I'll test the samsung one |
| 22:40:52 | n1s | bluebrother: alarms should be unaffected, i thik |
| 22:42:16 | pixelma | I'll test on M5 |
| 22:43:04 | n1s | great |
| 22:44:00 | n1s | bluebrother: i have no idea why it should hang, the only weird thing in that driver is that |0x80, maybe you could try removing it? |
| 22:45:19 | bluebrother | n1s: maybe it's an effect of the calendar plugin not getting a useable value? Though I haven't looked into the code at all. |
| 22:47:27 | kugel | samsung's have RTC_E8564, same as h10 and hdd1630 |
| 22:49:23 | n1s | bluebrother: thing is that that driver didn't change much at all and should essentially behave the same as it did... |
| 22:49:45 | n1s | did you test with a recent svn version? |
| 22:51:38 | bluebrother | n1s: yes, with current svn |
| 22:51:58 | n1s | ok, thanks |
| 22:53:46 | n1s | i wonder if it could have something to do with the special bcd decoding done in get_time previously |
| 22:54:02 | kugel | n1s: broken here |
| 22:54:14 | kugel | I got 2 warnings though, let's see if fixing these helps |
| 22:55:36 | n1s | kugel: were there a "statement witholut effect warning" ? |
| 22:56:09 | kugel | no, apparently just signedness warning in the for-loops (int i is compared with sizeof() ) |
| 22:58:29 | kugel | it appears to use BCD? |
| 22:58:39 | kugel | maybe only BCD ones are broken |
| 23:00 |
| 23:00:25 | | Quit _zic (Remote closed the connection) |
| 23:00:49 | n1s | kugel: very possible |
| 23:00:53 | | Quit mrkiko ("Lost terminal") |
| 23:07:09 | n1s | bluebrother: could you please test the new patch i tested, i used the "special" bcd decoding from svn get_time |
| 23:07:12 | n1s | ? |
| 23:07:27 | n1s | s/tested/posted/ |
| 23:09:12 | pixelma | would the Iaudio driver need this version too= |
| 23:09:18 | pixelma | ? |
| 23:11:10 | kugel | n1s: doesn't fix it here. I have the same symptoms |
| 23:11:30 | n1s | pixelma: it doesn't change anything for the iaudio driver, does it not work with the original patch? |
| 23:12:01 | n1s | kugel: doesn't change anything for the ams driver either |
| 23:12:13 | pixelma | can't tell as I'm just compiling (and then my only USB cable for it is taken for a while still |
| 23:12:16 | pixelma | ) |
| 23:12:17 | kugel | I'm testing on samsung yh925 |
| 23:13:38 | kugel | ah you just hacked the h100 one, gonna adapt and test again |
| 23:14:32 | bluebrother | n1s: reading looks good now, but setting the time doesn't work −− it always falls back to −−:−−:−− |
| 23:14:52 | kugel | yep, that did it for reading here too |
| 23:15:10 | n1s | bluebrother: ok, thanks, that confirms the problem (only changed the rtc_read_datetime so that's expected) |
| 23:15:49 | n1s | so the generic bcd conversion doesn't work, more work for tomorrow then |
| 23:15:55 | kugel | our rtcs apparently have an additional bit in the buf which messes it up |
| 23:16:15 | n1s | yeah, would seem so |
| 23:16:47 | n1s | I have no desire to read a whole bunch of datasheets though :) |
| 23:17:15 | kugel | I think such target specific code doesn't necessarily need generic macros |
| 23:17:19 | n1s | i guess the hard part is doing this in a nice way |
| 23:17:30 | kugel | if they don't work that is, I'd just keep the old conversion |
| 23:17:33 | bluebrother | interestingly the date read out in the set screen is correct while the date in the time / date screen shows only "unknown" |
| 23:17:46 | n1s | kugel: no, but this way was so nice! :) |
| 23:17:52 | kugel | :) |
| 23:18:30 | kugel | bluebrother: the patch doesn't swap wday and mday as SVN does, that's probably the reason (at least here) |
| 23:18:49 | n1s | it is interestig that several chips have thae same quirk |
| 23:19:24 | bluebrother | at least they do have things in common :) |
| 23:20:09 | kugel | rtc_read_datetime and rtc_write_datetime are entirely the same on our both rtcs, except for RTC_ADDR symbol |
| 23:20:44 | n1s | yeah, might be the same chip design :) |
| 23:21:41 | n1s | so at least the ds1339 and e8564 driver broken... |
| 23:23:21 | | Join fml [0] (n=4fd3dc7a@gateway/web/cgi-irc/labb.contactor.se/x-jvismssnbdzrgqfi) |
| 23:24:32 | fml | AlexP, pixelma: hey, wanna try a patch that fixes vspace in table headers? http://pastebin.ca/1547630 |
| 23:24:35 | | Quit petur ("Zzzzz") |
| 23:25:22 | fml | vspace in the first row still needs fixing |
| 23:28:47 | AlexP | fml: Did you see my revert earlier? |
| 23:29:19 | fml | AlexP: yes, and applied |
| 23:29:35 | AlexP | ok, cool :) |
| 23:29:44 | AlexP | I'll try now with this one :) |
| 23:30:37 | fml | With this patch, heads should look like the original booktabs (but without the thin white lines!) |
| 23:30:51 | fml | It builds as PDF and as HTML for me |
| 23:36:39 | AlexP | Yes, bith build here :) |
| 23:36:42 | AlexP | *both |
| 23:37:15 | AlexP | Looks good |
| 23:37:36 | fml | AlexP: commit? |
| 23:37:49 | AlexP | Is it possible to adjust the position of the lower line at all? It looks a little too close to the text in the first row to me (being very nit-picky here) |
| 23:38:08 | fml | AlexP: this will be another patch |
| 23:38:15 | AlexP | OK, sounds good |
| 23:38:49 | pixelma | can I please test on cygwin first? |
| 23:38:52 | CIA-43 | New commit by alle (r22550): Make table headers look like the original booktabs |
| 23:39:03 | pixelma | seems I can't |
| 23:39:04 | AlexP | pixelma: er, no :) |
| 23:39:05 | fml | pixelma: too late :-) |
| 23:39:08 | bluebrother | pixelma: too slow :) |
| 23:39:24 | gevaerts | bluebrother: what else did you expect from cygwin? :) |
| 23:39:27 | pixelma | sorry, can't divide myself or this laptop |
| 23:39:32 | fml | I wonder why there are differences in tex at all |
| 23:39:50 | AlexP | pixelma: Just shout if and when :) |
| 23:40:01 | bluebrother | though my build batch (pdf only) is still running. Need to have a closer look at the h100 manual |
| 23:40:13 | AlexP | What is up with it? |
| 23:40:30 | bluebrother | I wouldn't expect the speed difference that extreme for the manual |
| 23:40:49 | AlexP | Oh, it takes ages to build? |
| 23:40:55 | pixelma | speed difference? |
| 23:41:14 | * | bluebrother grumbles |
| 23:41:52 | bluebrother | why on earth was svnversion.sh renamed? It still only grabs the svn version information. |
| 23:42:11 | AlexP | 0m24.218s |
| 23:42:14 | AlexP | er, oops |
| 23:42:26 | bluebrother | but now all my set up manual builds which I haven't used for a while can't find it anymore. |
| 23:43:12 | kugel | version.sh handles git-svn repos also |
| 23:43:28 | kugel | that's probably why it was renamed |
| 23:43:33 | bluebrother | so? It still retrieves the *svn* version number. So calling it svnversion is *still* correct. |
| 23:44:27 | bluebrother | handling of git-svn was added before it got renamed. |
| 23:46:06 | pixelma | n1s: everything seems to work correctly with your patch (time display in statusbar and WPS, clock plugin, calendar plugin) |
| 23:46:12 | pixelma | on M5 that is |
| 23:46:29 | pixelma | I tested the first version in the tracker |
| 23:46:58 | pixelma | fml, AlexP: cygwin manual PDFs still build too |
| 23:47:10 | AlexP | pixelma: good news |
| 23:54:24 | fml | AlexP, pixelma: please try another patch that fixes the space in the last rows: http://pastebin.ca/1547654 |
| 23:54:57 | fml | I produced PDF and HTML with it |
| 23:55:15 | AlexP | ok, will do |
| 23:58:15 | | Quit ender` (" Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a") |
icon identifies that the person is a core developer (has commit access).