--- Log for 20.11.108 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 18 days and 8 hours ago 00.00.19 Quit sarixe ("Ex-Chat") 00.01.48 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 00.02.56 # kugel: re ping 00.05.35 Quit funman ("leaving") 00.06.35 # preglow: I think FS#9545 is ready for more eyes now, so if you want to try your sd driver for real with it, go ahead! 00.08.10 Quit balou (Remote closed the connection) 00.08.13 Join balou [0] (i=balou@cl-1844.ham-01.de.sixxs.net) 00.08.35 Quit Thundercloud (Remote closed the connection) 00.09.17 Join ajonat [0] (n=ajonat@190.48.123.99) 00.09.25 Quit saratoga ("CGI:IRC") 00.09.33 Quit bertrik ("Leaving") 00.09.33 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-66ddb2212c9522bf) 00.14.07 # * gevaerts now has both a ramdisk and a CF card in his mini. Unfortunately rockbox doesn't want to mount the ramdisk yet 00.15.15 # USB sees both 00.16.51 Quit ender` (" How long a minute is depends on which side of the bathroom door you are on. -- Theory of relativity") 00.23.04 # http://www.rockbox.org/twiki/bin/view/Main/CFModGuide how to get these hex values in the last table? (Kingston Elite Pro 133X 16GB) 00.24.32 Join Am0nXz [0] (n=normanz@190.166.40.105) 00.25.40 Join culture_ [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 00.29.34 # jhMikeS: hm, my fading ain't longer too 00.31.11 # jhMikeS: btw: I implemented your propose (it works), but I'm not entirely beware of the advantages. I think the code is mainly less readable, as I wouldn't connect SYS_TIMEOUT to fading, maybe you can clear it up for me? 00.32.41 Quit lasser (Read error: 145 (Connection timed out)) 00.33.20 Part Am0nXz 00.38.56 Quit culture_ (Read error: 104 (Connection reset by peer)) 00.39.07 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 00.39.38 # kugel: that queue gets pretty busy with messages as it is and so lowering the traffic there seemed a good idea 00.40.56 Quit LarsMoeller ("ChatZilla 0.9.84 [Firefox 2.0.0.18/2008102918]") 00.41.40 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 00.42.28 Quit bmbl (Client Quit) 00.44.06 Quit Nico_P (Read error: 104 (Connection reset by peer)) 00.44.53 Quit haikubear ("CGI:IRC (EOF)") 00.45.00 Quit LambdaCalculus37 ("Ka-chunka") 00.45.59 Quit faemir (Remote closed the connection) 00.56.11 # linuxstb_: ping 00.56.13 # jhMikeS: do you have a preference which fading to use? I suppose your patch? 00.56.21 # on the beast that is 00.56.34 # amiconn: Hello. 00.56.56 Quit shotofadds ("Leaving") 00.56.58 # linuxstb_: Do you know how large 'absres' in the 3.98 filter can be? 00.57.04 # kugel: for beast, the hardware looks much better since it's always smooth as glass no matter the brightness 00.57.40 # There's a possible optimisation (saving the division by three in that line), but only if absres is guaranteed not to become > INT_MAX / 3 00.57.58 # jhMikeS: yep, that's what I think too, although my patch is (for me) already smooth at brightness of 3. At least it's very noticeable 00.58.31 # kugel: the way the increased brightness range works, changing current ranges causes brightness glitches so those also show in fading 00.58.31 Join groundup [0] (n=chatzill@80.78.22.37) 00.58.53 # amiconn: Sorry, I've no idea. I never looked deeply into the codec. 00.59.12 # On ARM, gcc uses 'smull' for this / 3, but (absres * 3) would still be faster 01.00.52 Part toffe82_ 01.01.16 # I am very new to using Rockbox. In fact, I just installed it about 3 minutes ago. What is the best resource for finding out everything I can on customizing it? In particular, I want to know if I can use a picture as a background 01.02.04 # jhMikeS: ah ok. I can just consider from what Lambda told me and he said it's quite smooth (but also that yours is a little smoother). Anyway, I'd be in favor of the hardware fading too. 01.02.08 # groundup: we like to recommend the manual 01.02.36 # jhMikeS: have you looked at the settings I made? They should work for the gigabeat too with a proper #define 01.02.49 # amiconn: Yes, I see what you mean. It's hard to know if that's going to be safe though. 01.03.58 # kugel: I was looking and it seems compatible. 01.04.47 Part captainkwel 01.05.12 Quit herrwaldo ("Konversation terminated!") 01.05.41 # jhMikeS: I had to reimplement some of the settings, since OFFON setting uses bool and the pwm TABLESETTING int. Is there a way to use int's with OFFON setting? A flag maybe? 01.05.58 # amiconn: voice on the beast should be working fine now 01.06.09 # jhMikeS: Yes, almost 01.06.11 # kugel: you can use true/false with an int 01.06.24 # amiconn: what else is an issue? I fixed the PCM driver. 01.06.40 # The silence after boot is gone, and the delay at the beginning seems to be fixed too 01.07.27 # jhMikeS: yes, but it gave warnings with incompatible pointers, isn't bool 1byte wide only? 01.07.51 # But sometimes the end of a voice clip gets swallowed. This end doesn't vanish then though, it's played before the next clip, or next music 01.07.52 # kugel: bool is 32 bits 01.08.15 # ok, then the issue was at another point, I'll look into again 01.08.27 # bool can be different width depending on platform and even optimisation level 01.09.09 # amiconn: That sounds strange. I'm not experiencing that issue. 01.09.42 # Never assume that a bool* is compatible to an int* or similar without special precautions 01.11.23 # amiconn: Is there a recipe to get that to happen? Is it only .talk clips or all menus? 01.12.06 # I get it when playing a file and 'talk files' is set to 'numbered' 01.12.46 # Also, the swallowed beginning seems to be not completely fixed. 01.13.18 # Hmm, wait 01.14.01 # "talk files" set to "numbered" seems to be ok here. 01.16.26 Quit DerDome (Read error: 110 (Connection timed out)) 01.22.14 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 01.24.07 Join Slack [0] (n=brett@12-218-63-169.client.mchsi.com) 01.25.20 Quit tyfoo (Client Quit) 01.25.47 Join hillshum [0] (n=hillshum@75-165-238-79.slkc.qwest.net) 01.29.54 # jhMikeS: I didn't have the fix in my build, even though I thought I did. It's working nicely now 01.30.31 # amiconn: hehe. I thought it should. 01.31.26 # It was trying to write the FIFO with the whole module disabled which doesn't really work well. 01.31.51 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 01.40.37 Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net) 01.45.17 Join LambdaCalculus37 [0] (n=rmenes@c-68-83-177-181.hsd1.nj.comcast.net) 01.45.19 Quit MethoS- (Remote closed the connection) 01.45.27 Join sin613 [0] (n=pbarton@host-8-122-107-208.midco.net) 01.46.27 # jhMikeS: What has to be done to get fading committed? 01.46.33 Quit mofux (Read error: 104 (Connection reset by peer)) 01.46.47 Quit Thundercloud (Remote closed the connection) 01.48.14 *** Saving seen data "./dancer.seen" 01.53.12 # kugel: For the thread stuff? I don't know. I'll do 'beast HW stuff separately. 01.53.16 Join CaptainKewl [0] (n=jason@207-237-173-165.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.56.37 # jhMikeS: ams sansas (at least e200v2,fuze and likely c200v2) will be able to use the thread fading too 01.58.49 Quit neddy (Read error: 104 (Connection reset by peer)) 01.59.19 # Make sure the addition to each driver at the low level is minimal for each target? 01.59.57 # jhMikeS: yea, the needed modifications are minimal. I factored most of the code out to backlight_thread_fading.c/h 02.00.58 Join neddy [0] (n=john@nat/sun/x-dd5fc4d49564cbd0) 02.01.30 # but that could probably go into backlight.c as well 02.01.39 Quit culture (Read error: 110 (Connection timed out)) 02.02.47 # eek, isn't backlight.c enough of a maze already? 02.03.19 # yea, that's what I initially thought too (thus I used the extra file). 02.03.39 # I meant, if it's wanted, it could go into that 02.06.03 # stuff for the sim should be factored away into "sim drivers" or something. 02.07.12 # or uisimulator/backlight.c 02.07.49 # uisimulator/sdl rather 02.08.12 # jhMikeS: Seems that I can use F_T_INT flag for OFFON to use int vars? 02.09.19 # I don't think true/false is incompatible with ints, you just get 0 or 1 for the value. 02.10.17 # Though for HW fading, since it's fixed, off/1000ms seems like a good idea since you know what you get. 02.10.57 # jhMikeS: that might apply to beast, but not to thread fade targets 02.11.28 # jhMikeS: you can't assume that all "true" values are 1 - any non-zero integer evaluates as true 02.11.41 Quit balou (Remote closed the connection) 02.11.44 Join balou [0] (i=balou@cl-1844.ham-01.de.sixxs.net) 02.13.43 # jhMikeS: you cannot know the fading time without calclulating it from the current brightness 02.14.17 # Unhelpful: I know that is true. I usually take context into account. 02.14.37 # jhMikeS: sorry, then... the context thing occurred to me afterward :/ 02.15.26 # kugel: For thread yes, I know. Llorean suggested that but I wonder if it's a good idea unless you really can set the time. 02.18.04 # you could have a thread fading that fades over a set time, it just wouldn't actually set the brightness each time it's called. probably more complicated than we'd want? 02.21.31 # jhMikeS: it won't be much more than a "nice-to-know" information 02.21.31 # If you do sleep delay = time/brightness then it would be constant (or close enough) 02.22.38 # true 02.22.40 # [12:08:13] jhMikeS: Seems that I can use F_T_INT flag for OFFON to use int vars? <- that might not work 02.22.58 # kugel: I think I can get along with simple on/off just fine 02.23.00 # JdGordon: yea, I already tried and it didnt 02.24.09 # JdGordon: I guess the comment "variable type for the setting" confused me 02.37.10 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.38.37 # * kugel might just not use a macro for that 02.47.20 Quit sin613 ("Leaving.") 02.49.28 Join Darksair [0] (n=user@125.33.196.169) 03.01.11 Join z35 [0] (n=z35@h212.24.89.75.dynamic.ip.windstream.net) 03.09.37 # * jhMikeS goes to work on other matters while kugel works out settings stuff :) 03.11.24 # jhMikeS: doesn't look like I'll get it that easy. I think I'm just gonna keep it like it is 03.11.50 # I would need to create a new struct bool_int_setting or something like that 03.13.25 # isn't there one for arrays of values that have other text and labels? 03.18.20 # I didn't spot such one 03.18.50 # bool_setting would just be perfect, except for the callback which obviously requires the var to be a bool 03.21.11 # jhMikeS: well, the settings are working, it's just that I have to do this http://pastebin.ca/1261954 at 2 places 03.22.10 # * kugel leaves an updated patch on the tracker and goes to bad 03.22.13 # bed even 03.22.31 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") 03.22.46 Quit aarcane ("Leaving") 03.25.17 Part pixelma 03.25.40 Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) 03.37.43 Quit neddy (Read error: 110 (Connection timed out)) 03.38.46 Join reacocard [0] (n=reacocar@WL-112.CINE.HMC.Edu) 03.46.39 Quit JdGordon (Remote closed the connection) 03.46.55 Join neddy [0] (n=john@nat/sun/x-214d213f74b4d691) 03.48.17 *** Saving seen data "./dancer.seen" 03.48.53 Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) 03.51.11 Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) 03.51.17 Quit jhMikeS (Nick collision from services.) 03.51.23 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 03.52.05 Quit JdGordon (Read error: 54 (Connection reset by peer)) 03.55.09 Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) 03.58.14 Quit LambdaCalculus37 ("Ka-chunka") 04.06.45 Join miepchen^schlaf_ [0] (n=miepchen@p579ECBCC.dip.t-dialin.net) 04.06.51 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 04.11.38 Quit saratoga ("CGI:IRC (EOF)") 04.19.07 Quit reacocard (".") 04.19.34 Join reacocard [0] (n=reacocar@134.173.63.19) 04.19.45 Quit jhulst (Remote closed the connection) 04.20.13 Join blkhawk- [0] (n=blkhawk@e179049171.adsl.alicedsl.de) 04.21.40 Quit JdGordon (Read error: 54 (Connection reset by peer)) 04.21.40 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 04.22.58 Join _Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 04.23.48 Quit Kopfgeldjaeger (Read error: 104 (Connection reset by peer)) 04.23.51 Nick _Kopfgeldjaeger is now known as Kopfgeldjaeger (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 04.23.55 Quit tvelocity ("Αποχώρησε") 04.26.44 Nick Darksair is now known as Awaysair (n=user@125.33.196.169) 04.30.52 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 04.35.47 Quit blkhawk (Read error: 113 (No route to host)) 04.36.11 Nick blkhawk- is now known as blkhawk (n=blkhawk@e179049171.adsl.alicedsl.de) 04.39.15 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 04.42.32 Quit aarcane (Client Quit) 04.46.22 Quit jhMikeS (Nick collision from services.) 04.46.28 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 04.46.52 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.47.58 Quit Bensawsome ("The awsome is gone :(") 04.49.33 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 04.54.57 Join HBK- [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 04.54.57 Quit HBK1 (Read error: 54 (Connection reset by peer)) 04.58.46 Nick Awaysair is now known as Darksair (n=user@125.33.196.169) 04.59.13 Join Horschti [0] (n=Horscht@p4FD4F871.dip.t-dialin.net) 04.59.44 Nick HBK- is now known as HBK (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 04.59.59 Quit Horscht (Nick collision from services.) 05.01.58 Quit aarcane (Remote closed the connection) 05.02.12 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 05.04.37 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) 05.42.42 Quit aarcane (Client Quit) 05.45.51 Quit Horschti ("electromagnetic radiation from satellite debris") 05.48.20 *** Saving seen data "./dancer.seen" 05.49.40 Quit Bensawsome ("The awsome is gone :(") 05.50.14 Quit Seed ("cu, Andre") 05.59.19 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 06.09.19 Quit aarcane (Client Quit) 06.12.40 Quit jhulst (Remote closed the connection) 06.15.34 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 06.19.49 Quit aarcane (Client Quit) 06.20.37 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 06.27.51 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 06.27.59 Quit groundup ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111317]") 06.37.51 # does anyone know if you can redefine the format declerations in tagnavi_custom.config or if you can only add new ones? 06.39.07 Quit aarcane (Read error: 60 (Operation timed out)) 06.40.27 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 06.40.31 # JdGordon: No clue, but it'd take you like 10 seconds to test. 06.40.52 # ... 06.40.56 # asking is easier 06.41.45 # Yeah, but now there's nobody to answer 06.47.36 Quit Zarggg () 06.48.10 # principle of least surprise says that if it's in there, you can modify or remove it. not that that proves anything. 06.50.21 # between 1/2 and 1/3 of the way to having a testable scaler... mostly depending on how much harder the vertical scalers turn out to be than the horizontal ones. 06.51.18 # are there a macros somewhere for the screen pixel dimensions? right now, i'm just using w=240, which is fine for anything i have around to test on... 06.53.33 # LCD_WIDTH and LCD_HEIGHT 06.53.55 # cryptic names aye? :D 06.55.33 Quit hillshum ("Leaving") 06.57.11 # only cryptic if i have to start by guessing where they might be defined. i'm setting LCD_WIDTH as the limit for scaler output width. i don't see any reason to ever scale a bitmap to a size larger than the display :P 06.58.26 # should be defined in config.h I tihnk 06.59.08 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 07.08.25 # i'm really not sure at all what some of the stuff in the existing scaler is doing. :/ 07.14.18 Quit aarcane (Remote closed the connection) 07.14.57 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 07.34.34 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 07.35.01 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 07.37.47 Quit aarcane (Remote closed the connection) 07.39.00 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 07.40.30 Quit ajonat () 07.45.45 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.46.34 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.48.24 *** Saving seen data "./dancer.seen" 07.49.08 Quit aarcane (Read error: 104 (Connection reset by peer)) 07.50.06 # is there any reason not to close 6069? apart from being really outdated, the latest version adds alot of stuff which probalky isnt needed 07.53.29 # JdGordon: Isn't that just going to be completely useless with Zagor's changes anyway? 07.53.44 # all the makefile changes yes 07.53.57 # do we bother much about making sure DEBUG builds work? 07.54.11 # * JdGordon is trying to keep <200 open bugs :p 07.55.50 # I dunno 07.56.02 # meh, it can always be reopened later 07.57.57 # Yeah 07.58.36 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.05.05 Quit miepchen^schlaf_ () 08.07.01 # I assume 5230 is still a bug, but can someone with an ipod and/or e200 check? seems to work on my e200 08.14.31 Quit planetbeing ("leaving") 08.14.43 Quit courtc (Read error: 60 (Operation timed out)) 08.21.12 Join courtc [0] (n=court@unaffiliated/courtc) 08.27.52 Quit reacocard (".") 08.36.47 Quit BigBambi (Read error: 113 (No route to host)) 08.43.07 # JdGordon: It used to be pretty irregular, so it'd be hard to confirm whether it's gone or not, sadly 08.46.51 Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) 08.48.47 Join Rob2223 [0] (n=Miranda@p4FDCCA77.dip.t-dialin.net) 08.56.14 Quit bluebrother (Read error: 60 (Operation timed out)) 08.57.26 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 09.03.06 Quit Llorean (Read error: 104 (Connection reset by peer)) 09.03.26 Join Llorean [0] (n=DarkkOne@ppp-70-242-15-169.dsl.hstntx.swbell.net) 09.04.13 # i *do* still think that the resize_nearest ought to be nuked, except perhaps as an option for B&W-only targets? i don't think we want to be scaling icons, or theme images. 09.05.01 Join fyre^OS [0] (n=nnscript@cpe-24-90-84-200.nyc.res.rr.com) 09.05.01 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 09.05.07 # I too think we should avoid resizing such images 09.05.08 # Theme images won't really work anyway, unless we get the ability to position things as a percentage of the screen rather than absolutely 09.05.14 # So, in general, I'm for avoiding resizing them. 09.05.55 # also, resize means more CPU usage and in these cases rather pointless and we should avoid wasting resources 09.06.10 # also, about the dynamic buffer usage part... some people want to use the scaler outside of album art, possibly in plugins. perhaps the scaler should provide a function that returns the needed buffer, and then plugins could allocate that from their remaining plugin buffer, if they can, or by stealing audio buffer, whatever. it still gets a static buffer done away with. 09.06.33 # Unhelpful: yes, sounds like a plan 09.06.54 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.07.55 # i'm really pretty much inclined to say that smooth upscaling and downscaling of 24-bit rgb and 8-bit grey images covers every reasonable use, cut anything else out, and call it done 09.08.13 # Unhelpful: B&W targets don't have album art, hence won't have scaling in the core. Also those are usually the most binsize & memory restricted targets 09.08.38 # amiconn: don't build scaler at all on B&W targets? 09.09.02 # No, just plain bmp loading (for icons, wps bitmaps etc) 09.09.22 # The scaler might still be useful in the pluginlib though 09.09.38 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 09.09.58 Quit BHSPitMonkey ("Ex-Chat") 09.12.45 Quit CaptainKewl (Read error: 110 (Connection timed out)) 09.13.18 # now, if only i could get the darn thing to work. for some reason, the bmp reader is failing before it's passed as many rows as it claims are in the file... 09.13.28 Join petur [0] (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) 09.16.01 Join Nibbler [0] (n=Nibbler@e181111006.adsl.alicedsl.de) 09.31.35 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.33.23 Join lasser [0] (n=chatzill@Wae3e.w.pppool.de) 09.34.05 # hmm, with a bit of post processing we might get dependency generation down from 1500 forks to... 5? 09.34.23 # wow 09.34.56 # gcc can take any number of input files, but it always strips the path from the target it outputs. so we need to put that back. 09.35.20 # but that could be done with a single sed/awk/perl call 09.35.37 # there's also -MT -MQ 09.36.00 # but I've found them inadequate in the past 09.36.11 # yes but multiple MT puts multiple targets before a single :, which is not what we want 09.38.07 Quit bmbl (Read error: 60 (Operation timed out)) 09.38.47 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 09.48.27 *** Saving seen data "./dancer.seen" 09.54.23 Join DerDome [0] (n=DerDome@dslb-082-083-218-062.pools.arcor-ip.net) 09.56.27 Quit Nibbler (Read error: 113 (No route to host)) 09.57.41 Quit pixelma2 ("-") 09.57.51 Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) 10.02.17 Quit DerDome ("Leaving.") 10.03.10 Join tvelocity [0] (n=tony@adsl6-251.her.forthnet.gr) 10.08.48 Join spiorf [0] (n=spiorf@host45-171-dynamic.40-79-r.retail.telecomitalia.it) 10.12.27 Join jeffdameth1 [0] (n=jeff@dyndsl-095-033-064-030.ewe-ip-backbone.de) 10.13.44 Quit jhulst (Read error: 113 (No route to host)) 10.15.56 Quit jeffdameth (Read error: 60 (Operation timed out)) 10.20.47 Quit jhMikeS () 10.28.33 Join JdGordon_ [0] (n=jonno@c211-28-145-137.smelb2.vic.optusnet.com.au) 10.28.36 Quit Thundercloud (Remote closed the connection) 10.28.40 Quit JdGordon_ (Read error: 104 (Connection reset by peer)) 10.37.59 Join Juxta [0] (n=amidago@wnn73227.wireless.dtu.dk) 10.38.19 # Hello, any admin i can ask a question? 10.38.28 # admin ? 10.38.34 # any? 10.38.34 # yea 10.38.35 # admin of what ? 10.38.57 # I want to use a figure from rockbox.com and i want to ask for permission 10.39.14 # rockbox.com ? I don't think we own that. 10.39.19 # we have rockbox.org 10.39.19 # i know 10.39.26 # thats what i ment :p 10.39.36 # Copyright 1999-2008 by the contributing authors. 10.39.43 # Juxta: what figure? 10.39.59 # rockbox kernel and a few screens 10.40.09 Join mofux [0] (n=quassel@dslb-092-078-076-096.pools.arcor-ip.net) 10.40.20 # * GodEater guesses at more homework. 10.40.21 # Juxta: and where do you want to use it? 10.40.46 # ah right you are the one who asked here about the kernel here a couple of days ago? 10.40.57 # yea lol you remember hehe 10.41.06 # yea.. and i just wanted "proper" permission 10.41.32 # my teacher will demand it anyways, so "a written" agreement from an author would be good enough 10.41.46 # dont give it to him so he fails the assingment :D 10.42.05 # hehe then i will have to manipulate a conversation ^^ 10.42.34 # as I said then you need to contact the author of that image, Miika Pekkarinen 10.42.49 # http://www.rockbox.org/twiki/bin/view/Main/MiikaPekkarinen 10.42.51 # k 10.44.29 # with "screens" do you mean screenshots? 10.50.07 # fyi: I plan to commit #9534 today 10.51.47 # * B4gder buckles up 10.53.13 # we have have an extra beer tonight and celebrate this! 10.53.22 # uhm, replace one have with 'can' 10.53.29 # can can? ;) 10.53.40 # no cans, just pints! 11.04.39 Join DerDome [0] (n=DerDome@141.71.76.40) 11.04.55 # Zagor: while you're at it, remove the depencendy for make zip 11.05.11 Nick Darksair is now known as Awaysair (n=user@125.33.196.169) 11.25.04 # Zagor: have you considered crosscompiling sims? (using mingw32 on Linux, I think is the only current, and possible, use) 11.25.16 Join PaulJam [0] (i=PaulJam_@134.76.3.86) 11.28.01 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 11.37.04 # rasher: that could be interesting 11.42.41 # Zagor: it appears to be working at least a good deal through the compile 11.43.28 Quit tvelocity ("Αποχώρησε") 11.46.25 Nick Awaysair is now known as Darksair (n=user@125.33.196.169) 11.48.30 *** Saving seen data "./dancer.seen" 11.52.34 # Zagor: it "pretty much" works. UI256.bmp doesn't end up in the correct dir, and the executable doesn't get a pretty icon, but the output does in fact appear to work 11.53.45 # * Zagor spots some sneakily-named bitmaps 11.53.54 # rasher: nice 11.54.23 # I never understood the UI256 thing. does it have to be in the root? how is it used? 11.54.48 # Zagor: Actually, the .rocks might be wrong, I didn't manage to run a plugin, but I've no time to test further (and codecs might be broken as well, I assume) 11.55.00 # Zagor: It has to be in the root, and it's used if you start rockboxui with --background 11.55.11 # that is, the same folder as rockboxui(.exe) 11.55.23 # ok. I'll put it there then. 11.55.47 # I've moved a number of files out of there because I like it relatively clean. 11.56.14 # Zagor: if you want to test yourself, simple build instructions are here: http://www.rockbox.org/twiki/bin/view/Main/UiSimulator#Building_Windows_sim_in_Linux 11.56.36 # And the sim runs in wine, so you don't even need to touch Windows at all 11.56.49 # excellent 11.59.35 Join LarsMoeller [0] (n=chatzill@e181239169.adsl.alicedsl.de) 12.01.01 Quit linuxstb_ (Read error: 110 (Connection timed out)) 12.01.05 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 12.02.15 Join pvbcharon [0] (n=charon@62.225.173.228) 12.04.18 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-090-022.ewe-ip-backbone.de) 12.07.30 Join MegafEee [0] (n=Linux@unaffiliated/megaf) 12.16.46 Nick Darksair is now known as Awaysair (n=user@125.33.196.169) 12.17.26 Join n1s [0] (n=nils@rockbox/developer/n1s) 12.21.07 # brace for commit 12.21.37 # * JdGordon is taking bets on the score 12.24.38 # * n1s hides under his desk 12.25.17 # * GodEater grabs his desk with both hands 12.25.34 Quit MegafEee (Read error: 145 (Connection timed out)) 12.25.45 # * gevaerts expects a new record 12.26.32 # doubters :) 12.26.42 # * GodEater wonders if anyone's told dev.cgi to expect the sudden hammering it's about to receive 12.26.50 Join Lynx_ [0] (n=lynx@xdsl-84-44-171-184.netcologne.de) 12.27.29 # * gevaerts tweaks his build server to help the record along ;) 12.27.49 # removing the compiler doesnt give it a big enough scrore 12.28.03 Quit havien (Read error: 60 (Operation timed out)) 12.28.42 # that's what i call a commit 12.29.33 # why, this looks golden 12.29.35 Join pvbcharon_ [0] (n=charon@p056-interdsl5.rga.net) 12.30.23 # the commit message has one of the longest subject lines I've seen 12.30.38 Join kugel [0] (n=chatzill@unaffiliated/kugel) 12.30.50 # * GodEater watches the countdown on dev.cgi 12.31.08 Nick Awaysair is now known as Darksair (n=user@125.33.196.169) 12.32.21 # "Build should have been done (n) seconds ago" :) 12.34.03 Join havien [0] (n=none@68-189-143-101.dhcp.wlwl.wa.charter.com) 12.34.35 Quit pvbcharon_ () 12.35.36 # * GodEater suspects around 26 suddenly hung build jobs around the globe. 12.36.11 # Oh Ye of Little Faith 12.36.29 # * pixelma guesse that the first compile in a new way just takes longer 12.36.51 # checkout probably takes a while too, maybe 12.37.06 # what with umpteen files changed 12.37.26 Quit lasser (Remote closed the connection) 12.37.50 # wow 12.37.52 # green 12.38.11 # * GodEater hands in his doubters badge 12.38.41 # * pixelma checks if everything that should be is in the zip ;) 12.39.16 # we also need testing that the binaries work as they should. plugins & codecs etc. 12.40.36 # I don't expect problems but as they say: faith is good. control is better. :-) 12.41.35 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 12.43.12 # B4gder: the file size delta table isn't working. it says 0/0 in every column. 12.43.20 # let the users do that! 12.43.55 # Zagor: yay nice 12.46.13 Quit pvbcharon (Read error: 110 (Connection timed out)) 12.47.13 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 12.47.21 # Zagor: the location of rockbox.map changed and i think that is what the delta table script it looking for 12.47.40 # n1s: ok 12.47.45 # Zagor: what's the specific reason to CC apps/ code after plugins and codecs? 12.48.45 # Zagor: congrats for the commit :) 12.48.52 Join LarsMoeller_ [0] (n=chatzill@e181232151.adsl.alicedsl.de) 12.49.02 # Nico_P: thanks 12.49.09 # I shall test with a sansa build :) 12.49.14 Join rvvs89 [0] (n=rvvs89@martello.ucc.gu.uwa.edu.au) 12.49.30 # kugel: there is no reason. make tries to build apps first, but things in there depend on other things like bitmaps and speex voice codec and so those must be built first. 12.49.50 # hmm, my newly built sim tells me this: "failed to load archos/_temp_codec0.dll 12.49.50 # dlopen(archos/_temp_codec0.dll): archos/_temp_codec0.dll: invalid ELF header 12.49.50 # " 12.50.00 # when trying to play a file 12.50.29 # Zagor: ah ok, makes sense 12.50.33 # n1s: ok, I'll look at that 12.50.35 # same for plugins, "invalid ELF header" 12.50.48 # Zagor: x86_64 if that matters 12.52.21 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 12.52.43 # * pondlife pops in to congratulate Zagor a bit more 12.53.08 # cheers 12.53.49 # No sarcasm, but I'm also getting the sim playback failure. 12.54.00 # "failed to load archos/_temp_codec0.dll" 12.54.09 # yup, sounds like a sim plugin/code link issue 12.54.50 # hehe: archos/.rockbox/rocks/games/blackjack.rock: VMS Alpha executable 12.54.55 # umm, not quite what I had in mind... 12.57.20 # Zagor: "make bin" followed by "make bin" doesn't work? do I need to rerun configure or something? 12.57.52 # define "doesn't work" 12.58.05 # or doesn't it want to compile because I didn't change anything? 12.58.22 # "Nothing to be done" means precisely that 12.58.31 # cool 12.59.16 # * Nico_P 's sansa doesn't seem to be recognized by linux 12.59.37 # dmesg reads "config 128 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 100, changing to 10" and no device seems to appear 12.59.38 Join LarsMoeller__ [0] (n=chatzill@e181235012.adsl.alicedsl.de) 13.00.17 Quit nuonguy ("This computer has gone to sleep") 13.00.26 Quit Juxta () 13.01.23 # Nico_P: have you trued fs#6800 already (on a h300)? 13.01.45 # kugel: I have no H300 at hand 13.02.02 # Zagor: a target build on my gigabeast also displays "Codec failure" when trying to play a file, plugins work there though 13.02.31 # * Nico_P was being stupid about the sansa... forgot to set it to MSC instead of MTP 13.02.56 # n1s: yeah I found a mistake in plugins.make and codecs.make 13.03.38 # n1s: try changing $(CODECFLAGS) to $(CODECLDFLAGS) in the %.codec pattern rule at the bottom of codecs.make 13.03.56 # no, wrong. 13.04.09 # Which also shows an unrelated bug, the "Codec failure" splash comes from a different thread than ui, it enven splashes on top of plugins... 13.04.58 Join LarsMoeller___ [0] (n=chatzill@e181236012.adsl.alicedsl.de) 13.04.58 *** Alert Mode level 1 13.04.58 DBUG Enqueued KICK LarsMoeller 13.04.58 DBUG Enqueued KICK LarsMoeller_ 13.04.58 *** Alert Mode level 2 13.04.58 DBUG Enqueued KICK LarsMoeller__ 13.04.58 DBUG Enqueued KICK LarsMoeller___ 13.04.58 *** Alert Mode level 3 13.05.31 # woah woah my sansa's screen is fading to white 13.06.29 # Nico_P: same here 13.07.39 Quit LarsMoeller (Read error: 110 (Connection timed out)) 13.07.40 Nick LarsMoeller___ is now known as LarsMoeller (n=chatzill@e181236012.adsl.alicedsl.de) 13.07.40 DBUG Enqueued KICK LarsMoeller 13.07.40 *** Alert Mode level 4 13.07.44 # 3.0 is ok... phew :) 13.07.46 # Zagor: sansa build doesn't seem to boot 13.08.16 # kugel: which sansa? It ran fine on my c200 yesterday 13.08.23 # e200 13.08.25 Join lasser [0] (n=chatzill@Wae3e.w.pppool.de) 13.08.34 # odd 13.09.30 # I remember the "screen melting bug" reported on e200s in the beginnings of the port 13.09.42 # Zagor: the screen fades out slowly after the bootloader says "calculating crc32" 13.10.00 # sim plugin/codec fix committed 13.10.03 # not sure what there was done to solve it but I guess one can find something in the commit logs 13.10.35 # -there 13.11.55 Join LarsMoeller___ [0] (n=chatzill@e181236223.adsl.alicedsl.de) 13.11.55 *** Alert Mode level 5 13.11.55 *** Alert Mode level 6 13.11.55 DBUG Enqueued KICK LarsMoeller___ 13.11.55 *** Alert Mode level 7 13.11.55 *** Alert Mode level 8 13.11.55 *** Alert Mode level 9 13.12.06 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 13.12.09 # n1s: can you try different codecs on the gigabeat s? do they all fail? 13.12.33 # seems like the bug where you need to make codecs twice is gone too 13.13.45 # Zagor: bot vorbis and mp3 fail, those are the only fiels on it ATM 13.14.02 # ok 13.14.36 Ctcp Ignored 6 CTCP requests in 6 minutes and 57 seconds at the last flood 13.14.36 Ctcp Version from J-23!n=zelazko@unix.net.pl 13.15.03 Quit Lynx_ (" Try HydraIRC -> http://www.hydrairc.com <-") 13.15.32 # so let's iron out the sansa build bug 13.15.52 # Zagor: with your latest fix, my sim build spits out a "cp: kan inte ta status på "/home/nils/rockbox/h300sim/adx.elf": Filen eller katalogen finns inte" for each codec, and codecs aren't linked... 13.16.09 # meh 13.17.18 # copy/paste mistake 13.17.26 Quit LarsMoeller_ (Read error: 110 (Connection timed out)) 13.17.28 # plugins are fine though :) 13.17.48 # try now 13.18.27 Quit LarsMoeller___ ("ChatZilla 0.9.84 [Firefox 2.0.0.18/2008102918]") 13.18.50 # pixelma: could you meanr13531 13.19.02 # lol, nice number 13.21.17 # Zagor: now i get the same cp error for plugins too, and codecs still :/ 13.21.44 # n1s: eh? I didn't change plugins.make 13.21.56 *** Alert Mode OFF 13.22.27 Quit LarsMoeller__ (Read error: 110 (Connection timed out)) 13.23.17 # Zagor: I don't know, i find make scary and confusing... anyway it seems to be looking for all plugins in subdirs, so those which have subdirs work... 13.27.13 # show me one of the error lines 13.27.52 Quit LarsMoeller (Read error: 110 (Connection timed out)) 13.29.26 # hmm, i was mistaken, it looks in the right place it seems, and the file is there... "cp: kan inte ta status på "/home/nils/rockbox/h300sim/apps/plugins/flipit.elf": Filen eller katalogen finns inte" 13.30.02 # if i run make a second time they are linked 13.30.14 # or cp'ed 13.30.38 # you have flipit.o in the same directory, right? 13.30.51 # yes 13.31.10 # then that error message is very strange. 13.31.46 # remove one rock and run make again 13.33.19 # it recreates the .rock just fine 13.33.25 # and no error? 13.33.30 # nope 13.33.46 # what if you rm -rf apps/plugins? 13.33.48 # Zagor: do I need to rebuilt the bootloader? my svn-of-a-few-days-ago bootloader doesn't boot into rockbox 13.34.33 # kugel: no there should be no functional differences 13.35.03 # kugel: did you try with bootloader and a daily build? Maybe this helps tracking down where the error is... 13.35.23 # pixelma: it worked after jhMikeS' 13.35.26 # latest commit 13.35.42 # it's Zagor's commit. Nico_P also has the problem 13.36.07 # screen fading doesn't mean it doesn't load. it just means the screen is fading. 13.36.32 # you need to be very specific when describing problems, so we are not chasing ghosts 13.36.37 # yea, true. I cannot get to the main menu 13.36.47 # cannot get, or cannot see? 13.37.15 # Zagor: I already told you: the screen fades out after the bootloader says "calculating crc32" 13.37.35 # screen fades out as in turns all black slowly over time 13.37.58 # that sounds like rockbox loading fine, but does something wrong in the lcd setup 13.38.19 # Zagor: if i delete the whole apps/plugins dir the cp errors are back 13.38.37 # n1s: and you don't get any .rock files? 13.39.00 # exactly, a missing dependency on the elf files, maybe? 13.40.36 # no, I think it is a make problem I've ran into before. try removing the $(shell ) around the cp line 13.40.59 # $(SILENT)cp $(BUILDDIR)/$*.elf $@ ? 13.41.04 # exactly 13.41.07 # kugel: "fading black" as in backlight fades out or the LCD turns black - and is this with your backlight fading changes, Nico_P mentioned fading to white... 13.41.35 # pixelma: the lcd turns black, the backlight is on all the time 13.42.02 # pixelma: well, it has very different colors when that fading starts, but in the end it's black 13.42.28 # Zagor: that fixed the plugins :) 13.42.41 # I wonder why I don't get the problem 13.42.42 # now it started with beeing white, then going over to orange then brown then black 13.43.16 Quit culture (Connection timed out) 13.43.24 # n1s: yeah I've found that make has a bug in that it doesn't run all commands sequentially(!). make function calls are executed before "normal" exec lines 13.43.41 # so the $(shell) call was called before the gcc linker 13.45.28 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) 13.46.03 # how fun, same fix in codecs.make works for codecs too, now only one small peculiarity left on the sim, midi.rock ends up in .rockbox/rocks while it should be in .rockbox/rocks/viewers when making install 13.46.20 # pixelma: it looks like lcd_enable(false) without clearing the lcd before 13.47.56 # n1s: ok, checking that. 13.48.31 *** Saving seen data "./dancer.seen" 13.49.57 # Zagor: could that be a linking error or some kind? I can't imagine how your commit breaks the build 13.51.19 # we simply have to be more imaginative... 13.51.48 # linking errors are usually caught in the linker since we have a relatively complex linker script 13.52.02 # but obviously there is something wrong 13.52.15 # Zagor: could it be related to the mi4-format? 13.52.40 # can we get some more people testing sansa, please? c200, c100 etc. does it happen on all? 13.53.20 # kugel: my guess based on your description is that it loads and starts. if mi4 was wrong it wouldn't be able to start, as I understand it. 13.53.57 # kugel: have you tried the rev before Zagor's commit? 13.54.33 # ah yea. but it's not responsive too. the backlight and the button light stays on, and you can only turn it off with holding power 10s (normally you only need to hold it 3s) 13.54.37 # Nico_P: yes 13.54.45 # ok 13.55.12 Join what [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-843db62cd9121dc8) 13.55.44 # going to test on my c200 13.57.50 # testing on c200 here, it freezes on a black screen with backlight on directly after the bootloader 13.58.07 Quit spiorf (Remote closed the connection) 13.58.12 # badness 13.58.37 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 13.58.37 Quit HBK (Read error: 104 (Connection reset by peer)) 13.58.48 Join HBK [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 14.02.00 # Zagor these are the last few lines of a "make bin V=1" and the whole compression thing looks fishy, http://pastebin.ca/1262590 14.03.15 # eww, that's not supposed to be done for sansas. well spotted. 14.05.52 Quit what ("CGI:IRC (EOF)") 14.06.08 # oh but it isn't done either. that's just the output of the line. but compression is never done. 14.07.10 Quit Darksair (Remote closed the connection) 14.07.22 # Zagor: are the files linked in the same oerder? 14.07.24 # order 14.07.31 # if it did, you'd see "Image too big, making a compressed version!" 14.07.50 Join Darksair [0] (n=user@125.33.196.169) 14.07.54 # LinusN: every single object file? most should be, but probably not all. 14.08.11 # Zagor: crt0.S might be important 14.08.28 # that one is loaded by the linker script, so that works 14.08.41 # also the linker complains loudly if it doesn't find the start symbol. been there... :) 14.09.03 # would it make sense to compare md5 sums? 14.09.17 # no, they will inevitably differ 14.09.19 # i mean, your makefile changes should produce identical binaries 14.09.29 # hmm, except the version string 14.09.44 # and only if the libraries and object files are linked in the exact same order 14.10.02 # well, shouldn't they? 14.10.19 # no 14.11.53 # if we have such a fragile system that moving a bitmap struct from one place in the image to the other, we have problems 14.12.03 Join Schmogel [0] (n=Miranda@p3EE21D79.dip0.t-ipconnect.de) 14.12.32 # insert "crashes" at a suitable place :) 14.16.45 # is rockbox-info.txt done correctly? 14.17.03 # http://build.rockbox.org/cvsmod/sizes-20081120T121013Z 14.17.07 # indicates it isn't 14.17.21 # no some fields seem to be missing 14.17.41 # "Actual size:" is empty and "RAM usage:" is 0 14.17.54 # rockbox.map moved to the root. I guess that's it? 14.18.03 # probably, yes 14.20.15 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 14.25.08 # .text segment size are nearly identical, suggesting no bug chunks of unlinked code: 0x72c60 now vs 0x72cf8 for last rev 14.25.16 # s/bug/big 14.27.26 # shouldn't they be exactly identical? 14.27.44 # gcc adds some randomness just to be fun 14.27.52 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-9c8e5a22835e130f) 14.28.38 # could anyone try a different mi4 target perhaps? might give some clues 14.29.26 # and lcd_init for example is in nearly the same location 14.29.43 # would there be a point in trying a cygwin compiled c200 build? 14.29.59 # pixelma: can't hurt. it might give some clues. 14.30.40 # e200v1 crashes also 14.30.49 # we know :) 14.31.03 # oh 14.31.07 # compiling went fine btw. (I think it was faster but am not sure if I remember build times correctly for the target build.) 14.31.17 # * JdGordon just saw the call for mi4 targets and only the c100 mentioned 14.31.18 # isn't that philips the only other mi4 target? 14.31.28 # h10 too iirc 14.31.32 # no, h10 too 14.31.40 # * pixelma too slow 14.31.47 # oh, h10 and mrobe100 also 14.32.24 # so let's hope the mrobe user comes here :) 14.32.26 Quit bmbl ("Woah!") 14.32.34 Join TheSphinX^ [0] (n=cold@p54A5DC1E.dip.t-dialin.net) 14.32.38 # yes, both :P 14.32.47 # I'm sure if there are any and its broken we will hear from them 14.33.57 # but maybe it's related to PP. then ipods would also experience that 14.34.01 Quit DerDome (Read error: 110 (Connection timed out)) 14.34.13 # did anyone test on an ipod? 14.34.20 # ? 14.34.27 # what needs testing on an ipod 14.34.35 # current build, if it boots 14.34.40 # ill check right now. 14.34.44 # using 5g 14.35.13 Quit amiconn (Nick collision from services.) 14.35.20 Join amiconn [0] (n=jens@p54BD4A5E.dip.t-dialin.net) 14.35.43 # I'll test too on my iPod color. 14.37.15 # * LambdaCalculus37 backs up his current build first 14.37.24 # broekn ipod reported in flyspray 14.37.36 # oh nice 14.37.44 # JdGordon: What's the tracker number? 14.37.49 # 9564 14.37.54 # 4min ago 14.38.19 Join CaptainKewl [0] (n=jason@207-237-173-165.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 14.38.59 # not booting 14.39.03 # Not booting. 14.39.13 # cygwin compiled build gives the backlit black screen too, right after the SanDisk logo. I see nothing of the Rockbox bootloader but I don't have the latest released, I think 14.39.17 # fyre^OS: Is yours stuck at the Apple logo? 14.39.19 # on c200 that is 14.39.20 # yes 14.39.22 # Zagor: H300 is the same as the Beast, codec failure (mp3, vorbis, flac, sid) but plugins working 14.39.25 # Same here. 14.39.40 # n1s: ok, thanks 14.39.42 # * LambdaCalculus37 boots back into the OF 14.39.50 # haha, good that Zagor broke the targets with the most user :) 14.40.03 # that should teach'em! 14.40.06 # it seems I broke all targets 14.40.10 # :D 14.40.11 # gg 14.40.18 # its good that i saw this too 14.40.24 # i had some kind of weird cache bug 14.40.26 # not bad for an all-green commit, eh? ;) 14.40.32 # Zagor: its nice to see the full paths now :) 14.40.32 # iPod 3G has a red! 14.40.35 # indeed 14.40.38 # i found files in my .rockbox dir that were over 2 gb 14.41.07 # linux e200 sim works (incase noone else tested yet) 14.41.55 # a nice round score ;) 14.42.20 # LambdaCalculus37: that's odd. it's not supposed to run the linker until that .link file is created 14.42.26 # Bagder: untill this is all sorted should you maybe still a link on the build page to the last daily? 14.42.47 # JdGordon: Good idea. 14.42.58 # ah, /bin/sh: cannot create /home/rbclient/build-ipod3g/apps/codecs/codec.link: Directory nonexistent 14.43.42 # Zagor: The iPod 3G is reported "broken?" on the current build page. 14.43.55 # What's it linking to? 14.44.11 # I just did a 3g build and it built fine.. might just be a server qwerk? 14.44.30 # JdGordon: it happens with massive -j (paralellism) 14.46.11 # fixed 14.46.56 # why is $(shell) needed for cases like that? 14.47.15 # to avoid the bug where make runs $(call) lines before "simple" exec lines 14.47.28 # ugh 14.47.29 # at I least I consider that to be a bug 14.47.57 Quit amiconn (Nick collision from services.) 14.48.04 Join amiconn_ [0] (n=jens@p54BD76D1.dip.t-dialin.net) 14.48.17 # Should we announce on the ML that current builds may be broken for a little bit? 14.48.24 # three functions are missing from the new e200 build, compared to the previous revision: speex_mode_query, statusbar_icon_play_mode and statusbar_icon_shuffle 14.48.41 Quit kugel (Nick collision from services.) 14.48.42 Join kugel_ [0] (n=chatzill@e178092210.adsl.alicedsl.de) 14.48.44 # LambdaCalculus37: probably a good idea 14.48.46 Nick kugel_ is now known as kugel (n=chatzill@e178092210.adsl.alicedsl.de) 14.48.58 # * Zagor sends a mail 14.50.06 # perhaps a note on the download page too 14.50.10 # instead, even 14.50.14 # why would the absence of these function already let booting fail? 14.50.41 # pixelma: I don't think they are the cause of this 14.51.00 # rather they are not used and the new link line removes them where the old didn't 14.51.12 # if they were called and not linked, the linker would scream 14.51.42 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 14.51.55 # aha, can't imagine these as the cause either 14.51.59 # I din't think they're not used. I know there's a shuffle icon in the e200 statusbar 14.52.06 # don't* 14.53.08 # Zagor: maybe we get an undefined instruction somewhere, but we cannot see it if it is before lcd init 14.53.20 # could be 14.54.43 Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 14.55.18 # statusbar init is way after lcd init, so we would probably see it if this 3 functions are missing 14.57.45 # * Zagor added a big red note to build.rockbox.org 14.57.59 # Zagor: so I moved lcd init up a bit, and it doesn't fade out anymore (but it still doesn't boot) 14.58.34 # ah 14.59.48 # Zagor: now that I moved i2c init before lcd init it fades out again 15.00.21 # i assume the bug is somewhere in i2c_init()? 15.02.13 # commented out i2c_init removes the fade out again 15.05.46 # Zagor: the plugins that have their own foo.make file are still objcopied when building a sim 15.06.17 # n1s: ah 15.07.17 # umm, not all 15.08.01 # at least midi and doom, "file" tells me they are "VMS Alpha executable" 15.08.35 # right. all but two, it turns out.. 15.11.49 # n1s: "VMS Alpha executable"? Strange. :) 15.12.29 # yeah that's what an objcopied ELF file becomes 15.17.16 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 15.18.57 # speaking of nothing at all, I wonder if we'd gain anything significant by adopting the linux kernel's likely() and unlikely() usage 15.19.10 # what is that? 15.19.15 # if(likely(wrong)) { do this; } 15.19.24 # compiler hints? 15.19.29 # using a gcc builtin thing to hint 15.19.36 # #define likely(x) __builtin_expect(!!(x), 1) 15.19.52 # we do use that in the tremor codec in a few places 15.20.29 # "GCC hacks in the Linux kernel" => http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/index.html has some good ideas to borrow 15.21.31 # ohh, switch ranges. I didn't know that. 15.21.44 # Zagor: possibly OC and OCFLAGS could be variables and then OC could be set to cp for sims 15.21.56 # switch ranges look pretty neat 15.23.30 # likely() looks like something one should get used to using 15.23.53 Quit Darksair (Remote closed the connection) 15.24.13 # I don't know if our current architectures/gcc versions benefit from it, but it's definitely a good programming practice imho 15.24.16 Join Darksair [0] (n=user@125.33.196.169) 15.24.18 # and it's not very disturbing in the code either 15.24.39 # exactly. one could actually argue it makes the code easier to follow. 15.24.41 # it's also actually a hint to the casual reader of the code 15.24.45 # haha 15.25.14 # it's almost like you're my brother! 15.29.35 # switch ranges is basically case 1: case 2: case 3: ? 15.29.56 # with fallthrough that is 15.30.17 # kugel: yes 15.30.31 # not sure if using a non-standard extension is worth it if it could be done as easily with standard stuff 15.33.36 Quit amiconn_ (Read error: 113 (No route to host)) 15.35.43 # kugel: a) we already use some gcc extensions and b) are pretty unlikely to start using a different compiler any time soon 15.35.53 # it could be rather nice if you have a value range of, say, 10000 and a dozen fields within those. 15.36.17 # a thousand case lines isn't quite the same :) 15.36.26 # yea, true too 15.36.36 # Bagder, Zagor: I tried the type-checking min/max macros a while ago. They would be nice, as they're also producing better code, but they cause a ton of warnings which need fixing... 15.36.40 # the un/likely looks pretty interesting to me too 15.36.57 Join amigan [0] (i=dcp1990@ip68-226-92-253.ri.ri.cox.net) 15.38.05 # kugel: did you do anymore boot tests? I would do it myself but I don't have a target here... :-( 15.38.44 # Zagor: no, I haven't time right now 15.38.50 # kugel: btw, in the likely/unlikely case it is easy to define an empty macro depending on __GNUC__ 15.39.22 # n1s: that's why I find it interesting :) 15.42.26 Join nplus [0] (n=nplus@141.25.Globcom.Net) 15.44.21 # anyone who can run some target tests for me? 15.44.51 # first test: remove option -Wl,--gc-sections from root.make line 115 15.45.16 # Zagor: sure, sansa or booting target? 15.45.27 # sansa 15.48.07 # with that option removed, the .text segment is exactly the same size as before 15.48.35 *** Saving seen data "./dancer.seen" 15.51.08 # yes, it boots with that option removed, same deal with codecs as the other targets too 15.51.23 # ah, great 15.51.42 # yes :) 15.52.06 # Zagor: Is there a reason why -Wl,--gc-sections is used for normal builds now? Previously it was only used for bootloaders 15.52.42 # I assumed it would remove unused code without harming anything. I was wrong. 15.52.57 # Imho using that is unwanted for normal builds, because it causes laziness in cleaning up unused stuff. But if it is wanted, some sections need to be marked using KEEP() in the linker script 15.53.11 # what sections? 15.53.14 # Compare app.lds and boot.lds 15.53.39 # vectors, for instance 15.55.20 # I think we should strive towards making it work with that option, but I'll disable it now 15.55.42 # it is very difficult to manually keep track of exactly which functions are used and not in every build 15.56.40 # n1s: please try removing the same option from codecs.make line 93 15.56.56 Quit sarixe ("Ex-Chat") 15.57.24 # n1s: did you say some plugins worked? 15.57.48 # yes, i tried some random ones 15.59.33 # Were there any non-arm targets affected by that? I guess not... 16.01.01 # gigabeat s even worked 16.01.10 # Zagor: i did rm-rf apps/codecs and rebuilt but get the same codec failure, would a make clean be needed in between? 16.01.27 # n1s: no that won't make a difference 16.01.53 # n1s: can you do a thorough plugin check? 16.02.04 # sure 16.03.45 # SH and coldfire seem to have proper KEEP() protection in both boot.lds and app.lds 16.03.56 # ARM has no .vectors but there must be an equivalent 16.04.39 # Zagor: Look at the gigabeat S .lds files... 16.07.10 Nick Darksair is now known as Awaysair (n=user@125.33.196.169) 16.07.36 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-7b7eeb1891318b3a) 16.08.07 Quit CaptainKewl (Read error: 110 (Connection timed out)) 16.09.30 # Zagor: tested all games on c200 and they seem to work as well (or poorly) as they used to :) 16.10.06 # n1s: great, thanks. now why doesn't codecs work... 16.11.37 Part linuxstb_ ("Leaving") 16.16.34 Join obo [0] (n=obo@rockbox/developer/obo) 16.17.28 # Zagor: regarding your commit message, it wasn't only sansa which didn't boot 16.17.40 # it seemed to affect pp targets 16.17.52 Quit ap0 ("Ba") 16.17.52 # true 16.17.59 Join ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net) 16.20.07 # B4gder: I would've a use for likey(x) if we decide to use it 16.20.43 Quit ap0 (Client Quit) 16.21.28 Quit kharo (Read error: 110 (Connection timed out)) 16.25.39 Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 16.25.51 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 16.29.52 # the codecs are quite a bit smaller 16.30.04 # Zagor: this might be a clue, in an old vorbis.map file i found codec_start is the first function in the text section (from codec_crt0.o) and in one from a new build it's second after codec_main (from vorbis.o) 16.30.32 # a good clue I'd say 16.30.33 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 16.31.14 # in the map files I'm comparing now, they are in the exact same order 16.31.29 # then perhaps not so good clue ;-) 16.31.35 # but the new has a .text section of 0x83f4 bytes while the old is 0x8534 16.32.17 Nick Awaysair is now known as Darksair (n=user@125.33.196.169) 16.32.30 # haha, that is because the old codec includes libcodec twice... 16.33.15 # so dual memcpy, memset, codec_malloc etc 16.33.50 # I'm surprised ld does that 16.33.55 # dual is much better than single 16.34.05 # :-P 16.35.21 Join captainkwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-d49504c2c368ef1c) 16.35.38 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 16.37.14 Quit TheSphinX^ (Read error: 145 (Connection timed out)) 16.38.11 # I want to try changing the order the object files are linked into the elf, how would i do that? 16.39.41 Join dany_21a_ [0] (n=dan@84-119-29-31.dynamic.xdsl-line.inode.at) 16.43.23 # n1s: the codecs are typically just one object file and a library 16.44.35 # and the order is the same as before 16.44.55 # there are actually two object files: codec.o and crt.o 16.48.23 # PLUGIN_RAM is defined differently in the lds file 16.48.30 Join {phoenix} [0] (n=dirk@p54B47959.dip.t-dialin.net) 16.49.19 # at least for an x5 build the order of crt0.o and codec.o in the codecs i checked is reversed 16.49.31 # so crt0 is no longer first 16.49.44 Quit mofux (Read error: 113 (No route to host)) 16.49.53 # (x5 is the only semi recent build from before your changes i have still) 16.49.59 # n1s: really? the old build I'm comparing with links the crt0.o after codec.o 16.50.31 Join mofux [0] (n=quassel@dslb-092-078-075-102.pools.arcor-ip.net) 16.50.31 # in any case the code maps turn out the same. I'm pretty sure the plugin_ram thing is the problem. 16.53.13 # yes, it preprocesses plugin.lds without -DCODEC 16.54.59 # update and try now 16.56.24 Quit robin0800 (Read error: 104 (Connection reset by peer)) 16.57.33 # ah, yes working now (h300) 16.57.43 # :) 16.58.10 # great! 16.58.24 # I'll remove the big red sign on the download page then 17.01.15 # B4gder: what is needed to fix dev.cgi to show size deltas again? 17.02.08 # rockbox-info.txt needs to be fine 17.02.18 # ah right, that was the problem 17.07.13 # meh, bootloaders still need gc-sections 17.07.58 # Zagor: where should individual compiler flags for plugins and codecs be set now? IIUC most of them were lost/removed? 17.09.13 # they should still be there, in their respective .make file. files (directories) which want special flags define a new pattern rule that matches only that directory 17.09.27 # see doom.make for example 17.13.59 # amiconn: do we want gc-sections on all bootloaders? it looks like only bootbox needs it 17.18.58 # umm, the h100 and player deltas look a bit strange 17.19.20 # anyone have a h100 to test on? 17.19.58 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 17.21.40 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 17.22.18 # will this change also fix the problem with garbled bitmaps when the size of a certain bitmap changes? 17.22.18 # * petur looks at LinusN 17.22.55 # I haven't heard about that problem or the cause of it, so I don't know. 17.23.37 # well the bitmaps look as if the old data is used and stuffed into the new size. I'll try that then 17.25.18 # was that plugin bitmaps or the core ones? 17.26.17 # both 17.26.33 # I tried touching some bmp files, and it seems to work. 17.26.52 # plugin bitmaps trigger a full rebuild of all plugins, but better safe than sorry :-) 17.27.01 Part B4gder 17.27.02 # nice :) 17.31.39 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 17.31.46 # oh dear we have a new fun "comes and goes" delta game. only this time it's 100k up and down instead of 26 bytes... 17.33.14 # it's also a pure ram delta no bin difference 17.33.24 # yes 17.34.11 # The bitmap-of-different-size problem is most probably not fixed by this rework 17.35.18 # not? 17.35.32 # It is an object naming problem within the .a 17.36.03 # ok, what IS the problem? 17.36.25 # Currently the bitmap objects names contain the size, but the provided variable is the same 17.36.36 # yes 17.37.06 # So if you change the size of a bitmap, the compiler will create an .o with a different name, which is then added to the .a, i.e. doesn't replace the old one 17.37.29 # But the linker will choose the first object that provides the variable it is looking for 17.37.29 # not at all 17.37.49 # the .a contains a specific number of files that are listed in SOURCES 17.38.50 # Yes of course. But it will also contain objects from a previous run 17.38.52 # and in fact the bitmaps aren't even in a library anymore 17.39.14 # Aha, then it might be fixed. Why not, btw? 17.39.31 # wrong, the plugin bitmaps are 17.40.11 # because making a library is an unnecessary step for objects that we know will be included in the elf 17.41.07 # the problem you describe is easily solved by removing the .a before running ar 17.41.58 # I must say I find it odd that ar does not have an option to create a new library 17.42.09 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 17.43.41 # Zagor: You need to remove both the .a and the old objects, otherwise ar will grab them again 17.44.00 # the old objects will only be grabbed if they are still listed in SOURCES 17.44.02 # (well, unless you specify them explicitly instead of a wildcard) 17.44.07 # I do 17.48.34 Quit pixelma (Read error: 110 (Connection timed out)) 17.48.38 *** Saving seen data "./dancer.seen" 17.50.10 Join herrwaldo [0] (n=waldo@ip-81-11-223-160.dsl.scarlet.be) 17.53.48 Quit Zagor ("Client exiting") 18.01.24 Quit petur ("work->home") 18.04.02 Part pondlife 18.05.27 Join MethoS [0] (n=clemens@host-091-097-243-211.ewe-ip-backbone.de) 18.06.01 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.09.25 Quit synergist (Remote closed the connection) 18.10.44 Quit Darksair (Read error: 60 (Operation timed out)) 18.11.21 Quit shodanX (Read error: 104 (Connection reset by peer)) 18.12.21 Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 18.14.14 Quit Kohlrabi_ ("leaving") 18.18.54 Quit tyfoo (Client Quit) 18.20.41 Join netzwurm [0] (n=david@75-101-23-133.dsl.dynamic.sonic.net) 18.20.43 # hey 18.20.55 # is there a linux program to update the rockbox db while connected via usb? 18.23.27 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.24.10 # netzwurm: there is a standalone app in the rockbox sources that can do it but it has not seen much love in quite a while so it probably doesn't work anymore... 18.24.48 # n1s: that's too bad. for some reason auto-updating doesn't work for me ever and that means i have to restart my rockbox twice after transfering podcasts. 18.25.05 # wow, the generating dependencies step takes seriously long 18.25.25 Join perrikwp [0] (i=98212aaf@gateway/web/ajax/mibbit.com/x-db089c4612608266) 18.25.52 # bertrik: IIUC that is because dependencies for _all_ object files are gnereated in one go, earlier they were spread into one dep per dir so less noticable 18.25.52 # n1s: thanks anyway. 18.26.01 # n1s: what's the app called? 18.26.25 # netzwurm: if you are able to hack some c you could probably make it work again. :) 18.26.38 # n1s: i'll look into it. 18.27.17 # the main file is tools/database.c as you can see it relies heavily on the rockbox code 18.29.52 # ok. 18.30.55 # running "make database" in the tools dir _should_ build it 18.32.33 # yeah. or not :) 18.34.21 # hmm, someone moved some files around 18.34.58 # and sansa clip no longer builds 18.36.59 Join Strife89 [0] (n=michael@204.116.245.152) 18.39.12 # netzwurm: even after fixing the paths it spits out a bunch of warnings and dies so it is probably quite a bit of work to get it working :) 18.42.20 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 18.45.03 Quit MethoS (Remote closed the connection) 18.45.59 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 19.01.17 Quit {phoenix} (Remote closed the connection) 19.02.53 Quit BigBambi (Read error: 104 (Connection reset by peer)) 19.05.30 Join {phoenix} [0] (n=dirk@p54B47959.dip.t-dialin.net) 19.06.32 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 19.10.39 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 19.13.12 Quit dany_21a_ (Remote closed the connection) 19.13.31 Join miepchen^schlaf [0] (n=miepchen@p579ECBCC.dip.t-dialin.net) 19.13.40 Join dany_21a_ [0] (n=dan@84-119-29-31.dynamic.xdsl-line.inode.at) 19.13.51 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 19.15.45 Quit herrwaldo (Remote closed the connection) 19.18.44 Quit robin0800 (Connection timed out) 19.19.12 Quit Strife89 ("Just removed and reseated my Belkin card. Switching computers.........") 19.19.47 Join Strife89 [0] (n=michael@204.116.245.152) 19.21.19 Join herrwaldo [0] (n=waldo@ip-81-11-212-253.dsl.scarlet.be) 19.32.10 Part LinusN 19.41.27 Quit n17ikh|Lappy () 19.41.54 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 19.42.32 Quit tarbo (Client Quit) 19.42.44 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 19.43.08 Join tarbo [0] (n=me@unaffiliated/tarbo) 19.46.51 Join mofux_ [0] (n=quassel@dslb-092-078-071-220.pools.arcor-ip.net) 19.47.59 Join Lear [0] (i=chatzill@rockbox/developer/lear) 19.48.40 *** Saving seen data "./dancer.seen" 19.48.57 Quit mofux (Read error: 60 (Operation timed out)) 19.51.42 Quit miepchen^schlaf () 19.52.23 Join petur [50] (n=petur@rockbox/developer/petur) 19.53.42 Join j-b [0] (n=jb@videolan/developer/j-b) 19.53.55 Join kharo1 [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 19.54.13 Join miepchen^schlaf [0] (n=miepchen@p579ECBCC.dip.t-dialin.net) 19.55.03 Quit kharo (Read error: 110 (Connection timed out)) 19.55.16 Part j-b 19.56.24 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 19.56.42 # what do we use the hi res timer for? backlight fading and... ? 19.58.44 Join reacocard [0] (n=reacocar@134.173.63.19) 19.59.31 Part dany_21a_ 19.59.57 Join dany_21a_ [0] (n=dan@84-119-29-31.dynamic.xdsl-line.inode.at) 20.00.05 Part dany_21a_ 20.01.08 Join mofux [0] (n=quassel@dslb-092-078-089-006.pools.arcor-ip.net) 20.02.43 # preglow: The core uses it only for fading (on targets which can do that), but several plugins need it: metronome, everything using the greylib, video.rock, doom (on colour targets), ... 20.02.55 Join guessed [0] (n=not@cpc2-hem18-0-0-cust7.lutn.cable.ntl.com) 20.03.24 Join ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net) 20.04.11 Part guessed 20.07.29 Quit mofux (Read error: 60 (Operation timed out)) 20.08.13 Quit mofux_ (Read error: 145 (Connection timed out)) 20.08.45 Join mofux [0] (n=quassel@dslb-088-075-001-179.pools.arcor-ip.net) 20.13.21 Join mofux_ [0] (n=quassel@dslb-092-078-071-124.pools.arcor-ip.net) 20.13.39 Quit mofux (Read error: 60 (Operation timed out)) 20.15.02 # can FS#9564 be closed? 20.15.33 # * amiconn wonders what the heck causes this weird behaviour of test_codec with ape -c5000 on his PP5022 targets 20.16.19 Join faemir [0] (n=quassel@88-106-186-147.dynamic.dsl.as9105.com) 20.17.45 Join mofux [0] (n=quassel@dslb-092-078-076-091.pools.arcor-ip.net) 20.19.53 # Nico_P: I think it can. 20.19.57 # * LambdaCalculus37 goes to close it 20.24.01 Join Talyn0 [0] (n=817749e4@gateway/web/cgi-irc/labb.contactor.se/x-ab329feb9aac0970) 20.24.04 # check your emails! I sent a mail to the dev-ml 20.24.19 Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) 20.24.54 Quit Thundercloud (Remote closed the connection) 20.25.29 # I installed Rockbox on an iPod v5.5 about a year and a half ago 20.25.54 # and at some point the album art images started loosing a strip of pixels 20.26.15 # a row about 20 pixels wide on every album 20.26.33 # it shows up for a second or two when I first bring up an album 20.26.46 # anyone have any ideas what this is? 20.28.23 # anyone have any ideas what this is? 20.29.01 Join webguest78 [0] (n=817749e4@gateway/web/cgi-irc/labb.contactor.se/x-ad77ac74dceca089) 20.29.12 Join pixelma [0] (i=pixelma@212.204.47.129) 20.30.32 Quit mofux (Read error: 60 (Operation timed out)) 20.31.16 # Bagder: using (un)likely() in the midi plugin actually gave a not insignificant improvement :) 20.31.29 # so, where should the macros go? 20.32.05 Join mofux [0] (n=quassel@dslb-092-078-090-087.pools.arcor-ip.net) 20.32.30 Quit kharo1 (Read error: 110 (Connection timed out)) 20.32.40 Quit faemir (Remote closed the connection) 20.33.23 Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 20.34.20 Quit mofux_ (Connection timed out) 20.35.30 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 20.35.32 Join mofux_ [0] (n=quassel@dslb-092-078-059-164.pools.arcor-ip.net) 20.35.40 # n1s: I suppose misc.h 20.35.57 Join DerDome [0] (n=DerDome@dslb-082-083-218-062.pools.arcor-ip.net) 20.36.30 # * n1s was thinking more system.h this is not apps specific really (in fact it could probably be useful in firmware too) 20.36.51 Join faemir [0] (n=quassel@88-106-186-147.dynamic.dsl.as9105.com) 20.39.17 Join funman [0] (n=fun@AToulouse-158-1-34-203.w90-50.abo.wanadoo.fr) 20.40.02 # n1s: is systems.h #lncluded in apps/ code commonly? if not put it in both :) 20.40.19 Join tvelocity [0] (n=tony@adsl6-251.her.forthnet.gr) 20.40.21 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-c48eac6f63c10e18) 20.41.34 # afaik it is, as it defines a bunch of useful macros, but having the same thing in several places is bad so i'll stick them in there and we'll just have to include it if we want them 20.43.00 # sounds good 20.43.10 # "put it in both" was more of a joke anyway 20.44.39 # the jumping big deltas seem to still be for rombx targets (maybe depending on which server compiled and including some race conditions or so) 20.46.00 # so instead of weird failing builds for those there are now weird binsize deltas 20.46.02 Quit FOAD (Remote closed the connection) 20.46.55 Quit Talyn0 ("CGI:IRC (EOF)") 20.47.41 # or RAM usage 20.49.14 Quit mofux (Connection timed out) 20.49.58 Join AndyI [0] (i=AndyI@212.14.205.32) 20.50.09 Join FOAD [0] (n=dok@dinah.blub.net) 20.53.35 # * domonoky just got his first interrupt from the DMAC :-) 20.54.06 # domonoky: nice ! ready to share your work? 20.54.09 # funman: you forgot the interrup masks in DMAC_C0_CONFIGURATION... 20.54.18 # bit 14 and 15.. 20.54.38 Quit mofux_ (Read error: 110 (Connection timed out)) 20.54.51 # i also move the dma_channele enable before asking the sd controller for data, but dont know if this matters.. 20.55.00 # oops ok 20.55.49 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.55.55 # * funman will only set bit 15 - errors can't happen O:-) 21.00.21 # domonoky: i get fast booting after clearing the terminal count interrupt 21.00.45 # and lang file loads fine :-) 21.00.47 # nice.. 21.02.04 # test_codec remains stuck on 'Loading...' however 21.02.09 Quit AndyIL (Read error: 110 (Connection timed out)) 21.02.14 # so DMA is now under our control.. :-) 21.02.36 # and hopefully write support is a straight adaptation from sd_read_sectors 21.03.05 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-071-197.ewe-ip-backbone.de) 21.03.52 # now the boring part : error checking, and put unique error codes all over the functions 21.05.03 Quit Lear (Read error: 104 (Connection reset by peer)) 21.05.33 # funman, can you still build a clip rockbox with recent svn? I get a TIMER_FREQ undeclared in grey_core.c 21.06.38 # bertrik: a lot of plugins fail to build. I should take some time to calculate the exact timer frequency 21.07.12 # I thought since the peripheral clock is at 64MHz, the timer would decrase 64M times per second but it seems it's quite less than that .. 21.07.42 Join merbanan [0] (n=banan@83.233.243.188) 21.08.08 Quit kharo (Read error: 60 (Operation timed out)) 21.08.37 # bertrik: http://paste.ubuntu.com/74924/ my current diff with keymaps for some plugins and dma for sd 21.08.54 Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 21.09.17 # funman, oh I haven't done ../tools/configure in a while. I may have edited something to prevent plugins to build for clip and forgot about it. 21.09.32 # domonoky: the api of dma-pl081.c needs to be changed a bit to support i2sin & i2sout, there is still quite a few assumptions (directions from/to peripheral, channel 0 only ..) 21.09.53 # bertrik: well if it fails in greylib they are being built. 21.10.15 # yes, sure.. but we now know that it works the way we think.. :-) 21.10.46 # funman, how are the clock frequencies for the ams sansas decided, i.e. why use 64 MHz and not some other frequency? 21.12.29 # bertrik: i chose what the OF uses, but I may have made a mistake: I thought it used a 384MHz plla, but it might be 96MHz. I guess testing lower speeds would help in reducing battery life 21.15.25 # if we want to use a fixed peripheral clock, and a variable cpu clock, we might need to enable the 2nd pll (pllb); i don't know what's the cost on battery 21.16.09 # which means we would need to use the as3514 to read battery levels first .. :) 21.17.31 Quit Strife89 ("Gotta go.") 21.18.01 # domonoky: do you want to work on cleaning up the dma code? 21.19.19 # funman: my time i very limited at moment, i will not be online this weekend.. but if it isnt cleaned up till next week, i will make a try on it.. 21.20.16 # ok, then if i have time i will work on it, and keep you informed by the forum if it's not ready to be committed by then 21.20.36 # oki 21.20.38 # at least the functionality is there ;) 21.24.05 # funman, I don't know yet what would be the best w.r.t. clocking, but I think the pll itself is not the biggest power user 21.24.45 # iirc clocking the peripheral clock at 24MHz caused no problems, and needs no PLL 21.27.38 Join Acky [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) 21.28.01 Join p3tur [50] (n=petur@rockbox/developer/petur) 21.28.21 # n1s: do you (or anyone) know why there is "!!" in the likelyness compiler hints? 21.29.04 # if I try to use DMA for writing, I got a reboot after 1 or 2 seconds of uptime 21.29.07 # Nico_P: maybe to reduce every expression to 0 and 1 21.29.18 # Nico_P: afaik !!(true) == 1, !!(false) == 0 21.29.55 # so !!4 == 1 21.30.01 # yep, that's what I meant 21.30.01 # ah, thanks 21.30.35 # * funman seds s/SD_READ/SD_WRITE/g 21.31.05 Quit petur (Nick collision from services.) 21.31.10 Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) 21.31.21 # yep writing support is fine, and I think read_ and write_ sectors() could be easily factorized 21.32.36 Join mofux [0] (n=quassel@dslb-092-078-065-215.pools.arcor-ip.net) 21.35.14 # hopefully i2sout support will be quick to implement! 21.35.23 # * funman looks at gevaerts 21.36.39 # ? 21.37.03 # i was mentioning the sansa-meizu race ;) 21.38.43 # race? 21.38.54 # * gevaerts tries to think of ways to cheat 21.39.12 # * kugel hopes funman doesn't make porting work into a competition :( 21.39.19 # kugel: _friendly_ competition on how the 2 ports evolve 21.39.30 Quit Horscht ("electromagnetic radiation from satellite debris") 21.40.10 # * domonoky defines the gen 21.40.21 # the winner gets the right to buy a new device and help the other port ;) 21.40.26 Quit jhulst (Remote closed the connection) 21.40.32 # * domonoky defines the target of this race, that gentlemen mail... 21.40.41 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 21.40.49 # funman: that would be with the rockbox fund then ;) 21.40.50 # and proposes a sansa for the winner :-) 21.40.52 Quit Acky (Read error: 60 (Operation timed out)) 21.41.52 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 21.43.54 Quit Acksaw (Read error: 110 (Connection timed out)) 21.44.26 # Gentlemen, start your coding! ;) 21.44.34 Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) 21.44.59 # 3....2.....1......data abort! 21.45.20 Join massiveH [0] (n=massiveH@pool-71-187-243-194.nwrknj.fios.verizon.net) 21.46.10 # hm it's not perfect yet : the system deadlocks in read() in test_codec .. 21.47.38 Quit funman ("leaving") 21.48.25 # n1s: nice idea 21.48.43 *** Saving seen data "./dancer.seen" 21.49.34 # preglow: wasn't my idea, Bagder and Zagor were talking about it before, but it actually helped a bit in the midi player and was pretty trivial to add so I'm happy :) 21.51.23 # been thinking about it myself 21.51.33 # should start using it here and there in codecs 21.51.40 # go! :) 21.53.02 # It is still somehow baffeling that we can play ape files (c1000) on the pp players in realtime but not a f*ing midi >8 21.59.10 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 21.59.55 Quit {phoenix} (Remote closed the connection) 22.06.40 Nick J-23 is now known as Pustelnik (n=zelazko@unix.net.pl) 22.06.44 Nick Pustelnik is now known as J-23 (n=zelazko@unix.net.pl) 22.06.58 Quit jhulst (Read error: 110 (Connection timed out)) 22.07.14 Nick J-23 is now known as blablabla (n=zelazko@unix.net.pl) 22.07.55 Nick blablabla is now known as J-23 (n=zelazko@unix.net.pl) 22.09.43 Nick J-23 is now known as J-23___ (n=zelazko@unix.net.pl) 22.10.19 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 22.10.32 Nick J-23___ is now known as J-23 (n=zelazko@unix.net.pl) 22.11.29 Quit nuonguy ("This computer has gone to sleep") 22.11.47 Join jeffdameth [0] (n=jeff@dyndsl-095-033-082-051.ewe-ip-backbone.de) 22.13.19 Quit jeffdameth1 (Read error: 60 (Operation timed out)) 22.14.44 Quit merbanan (Remote closed the connection) 22.15.50 Join kharo1 [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 22.16.40 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.16.46 Quit ap0 (Read error: 104 (Connection reset by peer)) 22.16.56 Quit kharo (Read error: 110 (Connection timed out)) 22.17.04 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-ba19c41e544354e9) 22.18.39 # n1s: heh, not really, a midi player is a whole synth, an ape decoder is just a stream processor 22.28.10 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 22.31.39 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 22.46.20 Quit massiveH ("Leaving") 22.48.30 # bluebrother, domonoky: At least on somewhat recent linux you can get from usb device to block device (and from there presumably to mountpoint) by walking /sys 22.52.11 # gevaerts: interesting. Should give it a look ... 22.52.58 Quit nplus (Remote closed the connection) 22.54.32 # domonoky: If gevaerts' method is correct, you could pair .rockbox folders with USB IDs and never have to worry about local HD "installations" 22.55.15 # Llorean: if there is already a .rockbox dir, we will find it... 22.55.22 # the problem is the first install. 22.56.01 # autodetection also uses rockbox-info.txt and many more detection methods :-) 22.56.06 # domonoky: Yeah, but we want to *not* find .rockbox directories on local HDs. 22.56.27 # but i want that. its good for testing :-) 22.56.40 # Well, then we want to clearly mark them as "not real" devices. 22.56.47 # it better to find more,then too less.. 22.56.52 Quit n1s () 22.57.11 # Another thing it'll help prevent, is accidentally installing the wrong build on a device. 22.57.28 # with our different detection methods, we could also assign a "liklyhood" of the result. but i thought that would be overkill.. 22.57.37 # * Llorean has too many times forgotten to reset his configuration, and installed an iPod Nano build on his Gigabeat F, because he forgot he updated his Nano recently 22.58.05 # rbutil, does already complain about that.. 22.58.17 # Hm 22.58.23 # at least svn, dont know if it made it into the last release... 22.58.25 # Clearly I haven't messed up since my last upgrade of RButil then. 22.58.36 # It may be in 1.0.7, I haven't done it in a few months. 22.58.57 # before installing it checks if the rockbox-info.txt matches you config, and complains if they are different.. 22.59.15 # * bluebrother suggests a compile-time switch to enable local hdd support ;-) 22.59.55 # bluebrother: I'd think displaying them after the "real" devices, and possibly in italics or otherwise visually distinguished (with a note somewhere else on screen as to what it means) would also work 23.00.08 # the problem is to integrate such a "local hd detection" into the detection system.. 23.00.14 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) 23.00.41 # the main problem is someone to find the time ;-) 23.01.12 Quit jhulst (Read error: 104 (Connection reset by peer)) 23.01.41 # Llorean: if you write a method to get the HD -> USB-Id relation on all three OS, i would try to integrate it :-) 23.02.15 # * bluebrother would prefer USB -> HD resolving ;-) 23.02.31 # the way doesnt really matter... 23.03.07 # but we dont have this, especially not for all three supported OS.... sadly. 23.03.18 # true, but we need that way for detection 23.03.46 # bluebrother: you could always iterate over the HDs and map it this way.. 23.05.45 # we're already doing this for UNC -> drive letter 23.06.21 # so the best we get at moment is to list all detected device.. maybe the presentation could be improved.. one target with multiple mountpoints (drop down perhaps) ? 23.06.21 Join MethoS [0] (n=clemens@host-091-097-243-211.ewe-ip-backbone.de) 23.06.21 # while it works I somewhat dislike that it's somewhat inefficient -- but better than no resolving at all 23.09.12 Quit Jabone (Remote closed the connection) 23.09.15 Join Jabone [0] (i=jpylvana@jumi.lut.fi) 23.09.52 # bluebrother: If you plug in a USB storage device, you'll get (e.g.) /sys/block/sdb. In there there is a "device" symlink, and if you get the target path from that you can extract usb bus number and device id, the same as shown by lsusb 23.10.12 # You can probably also go the other way. It's a bit of a maze 23.12.57 # You may be able to get more help via the linux usb people, at http://www.linux-usb.org/mailing.html 23.15.32 Quit domonoky (Read error: 104 (Connection reset by peer)) 23.18.07 Quit bertrik ("Leaving") 23.27.03 Quit mofux (Read error: 110 (Connection timed out)) 23.27.21 Join mofux [0] (n=quassel@dslb-088-072-153-134.pools.arcor-ip.net) 23.28.10 Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) 23.31.34 # * gevaerts suddenly realises one possible reason why his multidriver tests didn't work properly 23.34.59 Quit obo (Read error: 110 (Connection timed out)) 23.35.15 Quit kharo1 (Read error: 110 (Connection timed out)) 23.35.21 # \o/ 23.35.44 # * gevaerts decides that he is less of an idiot today than he was yesterday 23.35.54 Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 23.35.59 Join obo [0] (n=obo@rockbox/developer/obo) 23.36.16 # It's working now? 23.36.24 # yes 23.36.32 # Congrats 23.36.56 # If you format an 8mb filesystem as FAT16, you need to make sure the number of sectors per cluster is small enough 23.39.54 # * gevaerts does a few more test builds before committing 23.41.54 Join LambdaCalculus37 [0] (n=rmenes@c-68-83-177-181.hsd1.nj.comcast.net) 23.45.31 Join mofux_ [0] (n=quassel@dslb-088-075-000-075.pools.arcor-ip.net) 23.48.21 Quit mofux (Operation timed out) 23.48.46 *** Saving seen data "./dancer.seen" 23.50.13 Join eightfold [0] (n=qwerty@c213-89-104-195.bredband.comhem.se) 23.52.03 Part eightfold