--- Log for 11.11.109 Server: lindbohm.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 9 days and 16 hours ago 00.01.03 # New commit by 03kugel (r23604): Fall back to info vp from sbs when intersection fails (again, r23575 changed it despite it was agreed on info vp beforehand). 00.02.39 # "/home/chshrcat/build/rockbox/firmware/target/arm/s3c2440/crt0.S:558: Error: symbol vectors is in a different section" <- building eabi for beaft. would a reasonable solution be to make .vectors a subection of .text? can i still make sure that things go into their proper places that way? 00.04.05 Quit scorche (Nick collision from services.) 00.04.08 Join Riku [0] (n=Lss@cm46.delta91.maxonline.com.sg) 00.04.49 Quit Lss (Read error: 131 (Connection reset by peer)) 00.04.50 Quit evilnick_B ("Page closed") 00.04.51 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 00.05.28 Quit ender` (" Two things are infinite: the universe and human stupidity, even though I'm not yet sure about the universe. -- A. Einstein") 00.06.36 Join kugel [0] (n=kugel@rockbox/developer/kugel) 00.07.20 # Unhelpful: I changed to to non-pc relative adressing, that worked on the mini2440 as far as i can tell 00.08.08 # it doesn't seem that we should need to do that, though? 00.08.41 # the vector address is fixed, i dont' see why you should need a symbol reference for it tbh ;) 00.09.00 # well, it loads to lr, isn't that supposed to contain a absolute address anyone? 00.09.05 # why doesn't it just jump to start annyway? 00.09.06 # s/anyone/anyway/ 00.10.17 # declaring the vectors symbol in the .lds would also work, wouldn't it? 00.10.27 # or return to start in this case 00.11.34 # or maybe set lr to PC+4 00.13.06 Join Mike_lifeguard [0] (n=Mike@wikimedia/mikelifeguard) 00.14.49 Part Mike_lifeguard ("Mike is a four-letter word.") 00.17.25 # and I don't see why vectors is a separate section either 00.20.21 # Unhelpful: yah, non-section-relative symbols shoudl be fine 00.20.39 # (i haven't actually looked at this code) 00.21.40 # There already is a symbol "vectorstart" in the lds btw 00.21.42 Quit daggett ("Ex-Chat") 00.23.05 Join GeekShado_ [0] (n=Antoine@APoitiers-552-1-108-198.w92-156.abo.wanadoo.fr) 00.26.46 # so using .text.vectors could be one solution, or vectorstart... 00.27.27 Quit domonoky1 (Read error: 131 (Connection reset by peer)) 00.33.38 Quit BBBradley ("CGI:IRC (EOF)") 00.37.10 Quit mt (Read error: 113 (No route to host)) 00.39.22 Quit kugel (Remote closed the connection) 00.39.57 Quit Grahack ("Leaving.") 00.40.43 Quit GeekShadow (Read error: 113 (No route to host)) 00.52.06 Quit mikroflops (Remote closed the connection) 00.52.07 Quit antil33t (Read error: 104 (Connection reset by peer)) 00.52.31 Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 00.57.32 Quit mikroflops (Remote closed the connection) 00.57.53 Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 00.58.37 Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 00.59.25 Join antil33t [0] (n=Mudkips@122-57-245-10.jetstream.xtra.co.nz) 01.00.09 Join GeekShadow [0] (n=Antoine@APoitiers-552-1-108-198.w92-156.abo.wanadoo.fr) 01.02.42 Quit GeekShado_ (Read error: 60 (Operation timed out)) 01.05.24 Join Strife1989 [0] (n=michael@adsl-81-160-3.mcn.bellsouth.net) 01.09.12 Quit pixelma (Nick collision from services.) 01.09.12 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 01.09.16 Quit amiconn (Nick collision from services.) 01.09.18 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 01.09.32 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 01.09.38 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 01.13.03 *** Saving seen data "./dancer.seen" 01.14.17 Quit Tuplanolla (Read error: 110 (Connection timed out)) 01.14.29 Quit Stephen__ ("Leaving") 01.16.40 Quit mikroflops (Read error: 54 (Connection reset by peer)) 01.17.39 Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) 01.18.39 # evilnick: still here? 01.18.46 Quit Rondom (Nick collision from services.) 01.18.57 Join Rondom [0] (n=Rondom@dslb-084-057-133-218.pools.arcor-ip.net) 01.20.34 Join Addison__ [0] (n=Addison@69.169.134.61.provo.static.broadweavenetworks.net) 01.21.29 # I was unhappy with the crossfade logic so I actually made some changes. There's a new option for crossfade: auto track skip only. It only crossfade for automatic track changes, but not for manual ones. 01.22.52 Quit Strife89 (Read error: 110 (Connection timed out)) 01.22.56 # I was also unhappy with the crossfade decision logic. It was a mess, so I changed it to a much clearer switch/case tree. The svn update is coming shortly, after fixing the manual. 01.22.59 Quit GeekShadow (Read error: 113 (No route to host)) 01.31.01 Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 01.31.16 Quit killan_ ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 01.32.11 Quit goffa (Read error: 113 (No route to host)) 01.34.08 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 01.36.00 Nick Strife1989 is now known as Strife89 (n=michael@adsl-81-160-3.mcn.bellsouth.net) 01.36.51 # Blue_Dude: that sounds good, I have had some issues with the cross fade when skipping tracks a lot 01.37.33 # We'll see how well this works. I'm just finishing up the manual now, and I'll commit in a few minutes. 01.37.39 # cool 01.37.54 Quit addisonj12 (Read error: 110 (Connection timed out)) 01.38.00 # while you're here, any thoughts on this? http://rguk.eu/s/rockbox_spazz.avi 01.38.13 # I'm unsure if I should be logging it as a bug on the tracker or not 01.38.47 Quit AaronM (Remote closed the connection) 01.39.44 Join MethoS- [0] (n=clemens@134.102.106.250) 01.39.58 # something has changed between recent builds and the preivous one I was using from some months ago, something to do with what it does with the WPS while the screen is off - seems to hault it now causing that buffer of changes to spew out at once 01.41.03 # I'm unsure if it's something which should be fixed in the DGT themes or if it's a rockbox issue 01.41.11 Join AaronM [0] (n=Aaron@adsl-4-241-157.mem.bellsouth.net) 01.42.09 Part toffe82 01.43.54 # I don't want to waste developers time by posting rubbish in the tracker 01.44.39 # The skin code has undergone so many changes in the past few weeks, I can't even keep up. It's very actively in development right now. It broke legacy skins a while back so I'm not surprised that you're seeing issues. Make sure you're using a current theme. 01.45.39 # yeah, DGT had an update fairly recently when there was a major change to the theme code which broke it completely 01.45.51 # I'll have a hunt around for any updated versions 01.46.33 Quit StealthyXIIGer (Read error: 131 (Connection reset by peer)) 01.46.39 # They redid a lot of the theme tags so unless a theme has been very recently updated, it's probably not going to work as you'd expect. 01.46.40 # I guess if the worst comes to the worst I'll attempt to modify the old version to work with newer builds 01.46.43 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 01.46.51 # Blue_Dude: ok, thanks 01.47.12 # Sure. Ran into that problem myself not long ago. 01.48.21 # New commit by 03blue_dude (r23605): Crossfade: added a new option, rewrote decision logic, updated manual and menus. Translators please note that updated translations may be required ... 01.48.43 # This ought to shake the tree some. :) 01.49.05 Quit Thundercloud (Remote closed the connection) 01.50.46 # :) 01.50.47 Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) 01.50.54 # I'll try it out tomorrow 01.50.55 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 01.53.41 # Some devs hate, hate, hate it when you modify the lang files, but I think I did it right this time. Everything was changed at once. 01.53.58 # cool 01.54.11 # http://www.rockbox.org/wiki/WpsIriverH300#DGT1_4 -- * DGTV1.4_NEW.zip: Latest Syntax DGTV, 1.5 I guess ? - StephenCarroll - 22 Sep 2008 01.54.16 # sep 2008 is definitely too old 01.56.59 # Ha, all green. I'm outta here. I'm going to hide until the smoke clears. :) 01.57.53 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 01.59.41 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 02.00.26 # can you increase playback speed? 02.02.38 Quit Llorean ("Leaving.") 02.02.38 # togetic: Yes you can 02.02.48 # It's in the manual 02.13.45 Join JdGordon|_ [0] (n=Miranda@72-62-46-168.pools.spcsdns.net) 02.23.54 # evilnick: the only thing i'm seeing in the manual is timestretch, but i don't see it anywhere in my sound settings 02.25.12 # What player do you have? 02.25.26 # evilnick: ipon nano 1st gen 02.25.48 # rockbox version 3.3 02.26.38 # http://download.rockbox.org/daily/manual/rockbox-ipodnano/rockbox-buildch4.html#x7-520004.3.3 and look for Pitch Screen 02.27.22 # Hmmmm, it might be worth upgrading to 3.4 as I'm not 100% sure that timestretch is in 3.3 02.27.30 # I don't think 3.3 has timestretch 02.28.12 # can i upgrade without removing any of my files? 02.28.18 # and can i upgrade using linux? 02.28.29 # i've had to install rockbox using windows every time 02.28.43 # But you can either simply speed up the song and the pitch will go up, or use timestretch and affect the speed but not the pitch. 02.29.18 # togetic: Check out rbutil, once you have RB on your player, you can use any program that can write to your player 02.29.25 # can you speed up the audio without using timestretch, with a feature that is in 3.3? 02.29.32 # no 02.29.47 # upgrading should be easy 02.30.00 # gevaerts: Pitch will speed it up, I thought. 02.30.19 # yes, but the pitch will go up, which I assume is not desired 02.30.37 Quit AaronM (Remote closed the connection) 02.32.42 # togetic: if you have problems installing from linux, you're likely doing something wrong 02.33.01 Join AaronM [0] (n=Aaron@adsl-4-241-157.mem.bellsouth.net) 02.33.01 Join AEnima1577 [0] (n=clbarnob@c-98-244-106-206.hsd1.va.comcast.net) 02.34.09 Join goffa [0] (n=goffa@70.33.8.114) 02.34.29 # do i select 'complete installation' to upgrade? 02.35.07 # you don't need a new bootloader, but it won't hurt either 02.36.17 # grr, it can't open the ipod, so i'm told 02.37.06 # rbutil may need root rights 02.37.09 # do i need to mount it first and then select /mnt/ipod 02.37.20 # or do i need to not mount it and select something like /dev/sdb2 02.37.51 # i already had it running as root 02.37.53 # doesn't the autodetection work? 02.37.58 # still do 02.38.19 # yeah, but it doesn't write 02.38.56 # does dmesg mention anything about FAT errors? 02.39.26 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 02.40.01 # http://pastebin.com/f3083973f 02.40.18 # gevaerts: yes it does 02.40.45 # http://pastebin.com/f647f2d9 02.41.11 # ok, so it probably remounted the device read-only 02.41.34 # you'll need to fix that first 02.41.39 # how? 02.41.45 # it is what? 02.41.53 # rbutils? 02.42.18 # │20:33:46 gevaerts | ok, so it probably remounted the device read-only 02.42.25 # this is not a rockbox problem. Your ipod has a corrupted filesystem, and when linux detects that it switches to read-only to avoid further damage 02.42.58 # so to fix this, i wipe the drive with fdisk and then install rockbox? 02.43.48 # * TheSeven is observing a very weird phenomenon 02.43.56 # uhm, no. (a) fdisk does not wipe drives, and (b) fsck.vfat sounds like a better option. First try to repair 02.44.16 # if i bypass the HCLK=>PCLK factor 2 clock divider, SDRAM access slows down by a factor of 2 02.45.00 # erm... 02.45.05 # whoops? 02.45.16 # setting an undocumented bit just sped it up by a factor of 4! 02.45.44 # imagine what could happen if you set a documented bit! 02.46.26 # heh, the documented bit for the clock divider isn't even there 02.46.49 # we thought it was just shifted by one for some reason (both on 8700 and 8701, so probably just a bug in the preliminary ds) 02.47.06 # oh wait a sec 02.47.13 # this is influencing my timer readings 02.47.30 Quit JdGordon|_ ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 02.47.32 Join saratoga_ [0] (i=9803c264@gateway/web/freenode/x-uichamwndznxnaqn) 02.47.38 # oh yes, these are based on pclk 02.48.12 # but nice to know that we can switch between clock divider factors of 1/2/4/8 while only 1/2 is documented 02.53.33 # i can't make it work in synchronous mode though 02.54.08 # async and fastbus both work fine, but sync doesn't 03.00.43 Quit Riku (Read error: 104 (Connection reset by peer)) 03.03.02 Quit MethoS- (Remote closed the connection) 03.07.22 # norboot is running it in async mode when i take over, even though they run at 192/96/48MHz, so sync should be possible 03.10.41 # hm, "FCLK must be HIGH whenever there is a BCLK transition." 03.10.52 # that's the only thing i could think of that may be violated 03.11.48 # but the penalty of async vs. sync shouldn't be high anyways 03.13.04 *** Saving seen data "./dancer.seen" 03.24.31 # are codecs any faster with a faster memory bus? 03.24.53 # we're already driving the AHB at it's maximum speed 03.25.22 # but yes, memory access performance seems to be proportional to AHB speed 03.26.01 # liar: ping 03.26.49 # saratoga_: judging from the datasheet, I would expect HCLK = SDRAM_CLK 03.27.22 # TheSeven: isn't there a divider in there somewhere? or do you mean thats disabled? 03.27.53 # if the datasheet is right, there is an optional factor 2 divider which is off 03.28.13 # however, the datasheet seems to be inaccurate in the MIU area 03.28.34 # there are some regs that don't match at all, but MIUCON seems to match 03.28.47 # (and that's where that clock divider bit is) 03.30.12 # btw apple's bootloader is clocking the same way as rockbox 03.33.26 Quit robin0800 (Remote closed the connection) 03.34.03 # liar: I finally have an idea where your USB problem could be coming from, or rather, I'm wondering why it works for me. 03.34.41 Quit DerPapst ("Leaving.") 03.35.29 # USB doesn't seem to like an AHB clock <66MHz at all. We are the only guys who are using boosting builds, right? 03.37.16 # you maybe want to have a shot at increasing the boosting min clock to 63897600Hz (CLKCON=0x32803280/CLKCON2=0x80) 03.38.36 # 47923200Hz doesn't work at all for me if I do it in iBugger, and I'm still wondering why it works within rockbox. Or is it just always running at full speed while USB is connected? Who knows... 03.40.31 # be aware that the 66MHz clock will result in timer inaccuracy (32% too fast when going to min speed) 03.41.19 # so in the long term we may want to go for 95846400Hz instead, or just always run at full speed if USB is connected, as we don't need to care about power in that case anyway 03.46.25 Quit goffa (Read error: 104 (Connection reset by peer)) 03.48.34 Quit uflops (Remote closed the connection) 03.48.57 Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 03.50.12 Join goffa [0] (n=goffa@70.33.8.114) 03.54.46 # * TheSeven is going to sleep now 03.56.33 Join T44 [0] (n=Topy44@f048203244.adsl.alicedsl.de) 03.59.38 Quit uflops (Read error: 104 (Connection reset by peer)) 04.01.07 Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 04.04.56 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 04.07.58 Quit Rondom (Nick collision from services.) 04.08.08 Join Rondom [0] (n=Rondom@dslb-084-057-186-138.pools.arcor-ip.net) 04.14.58 Quit Topy44 (Read error: 113 (No route to host)) 04.31.49 Quit TheSeven (Nick collision from services.) 04.32.07 Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) 04.32.19 Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) 04.35.56 Join Bob_C_ [0] (n=chatzill@host86-142-212-198.range86-142.btcentralplus.com) 04.35.57 # Torne: so it seems to me the relevant thing would be DVFEN(bit 4) in PMCR0? and possibly FSVAIM (bit 15) "This bit masks the DVFS frequency adjustment interrupt." 04.36.23 # it sure looks like you can say "manage voltage and frequency for me, and no, i don't really care to know when you change things" 04.46.06 Quit phanboy4 (Read error: 54 (Connection reset by peer)) 04.54.45 Quit Bob_C (Read error: 113 (No route to host)) 05.13.05 *** Saving seen data "./dancer.seen" 05.15.08 Quit AEnima1577 (Client Quit) 05.30.52 Quit Horscht ("Verlassend") 05.35.45 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 05.36.34 Join Llorean [0] (n=DarkkOne@adsl-99-4-146-40.dsl.hstntx.sbcglobal.net) 05.45.00 Quit StealthyXIIGer (Read error: 145 (Connection timed out)) 05.45.06 Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net) 05.55.51 # brain fart time.... 05.56.08 # with the removal of the inbuilt statusbar there is no need for the statusbar config option 05.56.32 # but, what do we do for screens which want to force the bar? 05.56.57 # JdGordon, is it intended that the custom statusbar will show in plugins? 05.56.59 # The obvious answer is to supply a hardcoded one... but then how do we have the user tell us if he wants the hard coded one or none? 05.57.05 # kkurbjun: its not 05.57.19 # JdGordon, I think some status is needed in the plugins 05.57.28 # kkurbjun: Few plugins have it now. 05.57.34 # they can enable it if they want 05.57.38 # there needs to be a way you can get battery readouts and the like 05.57.46 # almost none have it.. and only in their lists/menus 05.57.49 # they used to all have it in the menus 05.57.54 # where it should magivally pop up anyway 05.57.57 # yeah, that's what I'm referring to 05.58.00 # Can't plugins implement their own status indicators, since it should be themed to match the plugin rather than the WPS anyway? 05.58.16 # plugins will be fixed once the core is working properly 05.58.24 # the plugins all use the standard menus I think they should look as integrated as possible to rockbox 05.58.55 # Even when they use the standard menus, they often use their own color scheme or what not. 05.59.10 # if you preserved the backdrop image and custom status bar, a plugin choosing to use its on colors could be a disaster and unusable. 05.59.24 # *own 05.59.30 # * JdGordon really hates calling the skinned bar the statusbar :) 05.59.42 # They should not choose their own colors in the menu, and the backdrop should be preserved in menu 05.59.57 # how do you guys feel about having a blank .[r]sbs named "rockbox-none" which would have the effect of disabling the sbs? 06.00.05 # kkurbjun: So theme authors can never have their menus match their plugin unless they want an entirely custom menu (which we frown on)? 06.00.39 # theme authors plugins? 06.00.40 Quit panni__ (Client Quit) 06.01.07 # JdGordon instead of a menu option to disable the statusbar? 06.01.10 # yes 06.01.18 # a disable option is redundant 06.01.37 # kkurbjun: Sorry, plugin authors. 06.01.51 # either a sbs is loaded, or its not 06.01.54 # none of the plugins have menus that are particluarly tailored to the plugin 06.02.09 # * JdGordon thinks even rockbox-none isnt needed 06.02.11 # kkurbjun: Jewels uses the same background and text color in the menu as it does in the game. 06.02.15 # This looks rather nice 06.02.25 # but not the background image 06.02.39 # JdGordon: Yes, but using the theme's background image there could be horrible, if it's a light image. 06.02.48 # sure 06.02.55 # but thats up to the plugin authour to disable 06.03.05 # Llorean, which menu are you referring to in jewels? 06.03.18 # JdGordon: Yeah, but kkurbjun's position appears to be that plugin authors should not be allowed to choose - the plugin menus should always match core menus in appearance. 06.03.39 # in the menus and in the plugins UI are two seperate things imo 06.04.03 # kkurbjun: Has it changed? 06.04.44 # I think plugin authors should be allowed to decide *not* to match the core UI theme, rather than being forced to be constrained to it if they wish to use a list. 06.05.04 # If a plugin went to the effort to provide it's own backdrop in the menus I could see allowing them to pick their own colors, but unless they went all the way I don't think that plugins should just pick arbitrary colors on a solid background 06.05.09 # Maybe simply give them the tools to create their own "list + sbs" within the plugin itself. 06.05.27 # kkurbjun: So it's only an artistic choice if there's an image involved? 06.05.57 # Llorean, the menu's are hardly artistic now 06.06.02 # they are just plain jane 06.06.22 # You have a very narrow view of artistic if you think "having it be the same colors as the rest of the application" isn't an artistic consideration 06.06.27 # take a look at the jewels menu in a recent build 06.06.35 # You want the menus to "belong" to Rockbox's look, and the author might want them to "belong" to the plugin's look instead. 06.06.37 # can I but in here for a sec? :D 06.06.57 # what plugin author are you referring to? 06.06.57 # kkurbjun: simple isn't the same as "not an artistic choice" 06.07.02 # are you an author? 06.07.15 # either a sbs is loaded or it isnt.... would a user ever be expected to actually *want* to use the inbuilt skinned bar (assuming its uber crap and we supply good replacements?) 06.07.21 # kkurbjun: is this the "nobody's asking for it right now, so surely nobody could want it" argument then? 06.07.52 # JdGordon: Can we have plugins default to using the list and built in SBS, but be able to use their own alternative via some method? 06.08.09 # sure 06.08.13 # (in theory) 06.08.42 # Llorean: the menus are not integrated in the plugins right now - it is a complete separation from the game or app or whatever as it currently stands 06.08.45 # That seems the most ideal way. If they don't explicitly say "override settings" they get whatever the core settings are for their lists, if they do override they can (and must) provide their own alternative 06.08.48 # the skin buffer needs to be able to be told to use a different buffer to do that, but its doable 06.09.00 # maintaining the rockbox look in those cases seems reasonable 06.09.38 # iff they went to the effort to make something more custom I don't see a reason not to allow that, but until that is done I don't see a reason to break the standard rockbox look 06.09.43 # kkurbjun: Forcing it seems unreasonable though. 06.09.44 # *very* few plugins have a need to keep close to the rockbox look 06.10.18 # nearly all of the plugins have an almost uniform look 06.10.26 # teru did a good job with that 06.10.29 # kkurbjun: That's because the list widget is limited right now. 06.10.44 # the plugin's menus that is 06.10.48 # They have a uniform look because they aren't offered options for having a non-uniform look without ceasing to use the built in list. 06.11.08 # Many plugins *had* custom menus that looked much, much nicer than the existing ones. 06.11.09 # tehy could do a uniform look 06.11.16 # * JdGordon would like to see the list being more skinnable soon also 06.11.21 # it is completely possible for a plugin to set it's own backdrop 06.11.33 # I experimented with it in the doom menus 06.11.34 # A backdrop isn't a significant change in look. 06.12.39 # Llorean: the plugins old menus were barely usable across targets and quite a few did nasty things like force the builtin font 06.12.47 # kkurbjun: Yes. 06.12.50 # You keep missing my point 06.13.05 # They offered *artistic* options which were taken away for a good reason - so that they could function better. 06.13.15 # Now we can return the artistic options without removing the functionality (in theory) and should 06.14.16 # you can't make universal skins that work on all targets currently. Forcing a new port to port all of the custom skins for a new screen size seems insane 06.14.36 # if we had something more relative for skins I would agree that more flexibility should be allowed 06.14.37 # you asctually can :) 06.14.40 # They have to port all the plugins to a new screen size anyway. 06.14.53 # negative values are somewhat relative 06.15.03 # Seriously, if you need to resize the bitmaps to 32% larger and then tweak a few numbers, resizing all the windows and fonts is hardly much harder. 06.15.11 # but it's not relative enough that you could go across all targets 06.15.28 # Llorean: have you ever gone thorugh it on a port 06.15.39 # it's awful already and you want to make it worse 06.16.04 # kkurbjun: So shouldn't we get rid of themes and plugins entirely then? 06.16.07 # It'd make it much, much easier. 06.16.20 # * JdGordon is going to make the inbuilt sbs stupidly simple.... just battery, playback status and RTC... anything else *really* required? 06.16.32 # JdGordon: Volume 06.16.40 # You always need to know if pressing "play" is going to deafen you 06.16.42 # baring in mind this will almost never be shown 06.17.49 # Llorean: if you want to volunteer to change all the skins that plugin authors come come up with for a new screen size I'm all for it - but we should make porting a new target/screen harder than it already is 06.18.04 # should not that is 06.18.10 # kkurbjun: Plugins are not required for a port to be usable. 06.18.16 # So, frankly, if they're harder it's not a big deal. 06.18.46 # Plugins on the other hand are a "nice bonus" and should be allowed to look as nice as their authors or maintainers want them to look. 06.19.21 # If you don't make the default list flexible, as the core starts looking nicer and becoming more flexible with its menus, people will start simply coding custom menus for the plugins again so they can get that same sort of flexibility 06.19.38 # Llorean: that's a ridiculous argument, seriously try it some time, pick an arbitrary screen size and look at the amount of work required already. 06.20.35 # it's a little better with some plugins now than it used to be - it could be alot better if good decisions and planning was done 06.20.47 # What, drop bitmap support in plugins entirely? 06.20.55 # Remove absolute positioning, making all drawing relative? 06.21.10 # It's always going to be a lot of work, but that's not a reason to restrict authors arbitrarily. 06.21.12 # Llorean: I don't mind bitmap rescaling, its all the other hard coded numbers you have to change 06.21.14 # calculate 06.21.20 # and understand what they are being used for 06.21.22 # Do you honestly believe people will NOT create custom menus, given that they did in the past? 06.21.58 # Themes are easy to resize. Very easy. It's a couple minute's work after the bitmaps are done, especially if it's an actual skin and sbs file. 06.22.14 # It's not like you need to "figure out what the numbers are used for", the theme syntax isn't terribly bad. 06.23.00 # Llorean: till you start contributing code I have a hard time seriously considering your argument for making development harder. 06.23.22 # That's frankly a bullshit excuse. 06.23.36 # I'm allowed to have an opinion whether or not I've contributed any code recently (or at all for that matter) 06.23.55 # You on the other hand seem to be thinking that creating skins is some enormously difficult task. 06.24.11 # How many themes have you actually made or resized? You could probably automate it and then correct it if it looks funny. 06.25.20 # Am I allowed to say "I won't take you seriously until you show me some themes you've resized" or does that argument only work when you say it (even though this isn't about adding new C or ASM tasks) 06.26.05 # yeah, you can say that just fine and I will point you to the mr500 theme 06.26.11 # So you've resized one? 06.26.15 # And how long did it take you? 06.26.26 # Was it your first theme? How long would it take you to do a second one? 06.26.28 # yes, I made scripts to automate making icons of all different size 06.26.29 # s 06.26.34 # from svgs 06.26.48 # but it's not something that I would argue for lightly 06.26.58 Quit Strife89 (Read error: 110 (Connection timed out)) 06.27.04 # How hard would you say it is to take an existing WPS and adjust it to a new target size? 06.27.31 # Because that's what we're talking about doing here basically. An SBS and a list viewport. 06.28.52 # if you are talking the scale of all the plugins I would say a big pain - especially when you consider how complex some themes can get 06.29.01 # if you had relative positioning I would be all for it 06.29.13 # Do you think the plugin is going to be displaying the WPS or something? 06.29.19 # with a well thought theme you could hit all the targets 06.29.22 # SBS and list viewport. 06.29.25 # why not? 06.29.42 # If you can do relative positioning, then you can also do automatic scaling 06.29.44 # you could have an sbs displaying everything the wps has 06.29.44 # So problem solved 06.29.49 # A simple script, no work for the plugin authors at all 06.29.57 # It's the exact same math. 06.29.58 # is "char mytext[NB_SCREENS][] = {"blaaa", "fdslakhfsalkjh"};" correct? 06.30.02 # :-D agreed 06.30.10 # So you don't need relative positioning 06.30.29 # sorry, thought you were speaking relative positioning 06.30.30 # And you can't do relative positioning for all targets anyway 06.30.39 # 1:1, 4:3, 3:4, 16:9 and other aspect ratios exist 06.30.53 # You'd need to create new variants as new screen dimensions existed. 06.31.08 # You'd also need to manually tweak to deal with rounding issues. 06.31.18 # dimensions are alot less work than all the different screen sizes 06.31.23 # So it's better to use a conversion script to create the new SBS then tweak the output after looking at it. 06.31.25 # or ratios I mean 06.31.28 # So use scripts 06.31.37 # It's the exact same math as relative positioning 06.31.38 # Exactly. 06.31.44 # And you get nicer looking themes. 06.31.57 # Because you can fix them, rather than permanently being at the mercy of rounding. 06.32.14 # someone has to write and maintain the scripts you are decoupling the plugin author from the responsibility of making their screens work for more than one target 06.32.30 # g'night 06.32.51 # kkurbjun: And? 06.32.58 # arg... I hate pointers.... how do i do a static array or 2 strings? 06.33.34 # kkurbjun: I thought the idea was to remove the responsibility from the plugin author so as not to make it "too hard" to convert these non-essential parts of Rockbox. 06.33.59 # it is alot simpler if it "just works" 06.34.09 # Relative positioning will never "just work" 06.34.20 # look at brickmania now 06.34.28 # Any time you have a new ratio, the people porting to the target will need to readjust *every* plugin to deal with the new dimensions. 06.34.41 # It's the same problem as the scripts. 06.35.07 # it requires custome bitmaps, but you don't have to do anything beside that - before there were a ton of defines for each screen saying how fast things should b emoving, how fast the screen should update, etc 06.36.18 # So basically you'd rather a way that is technically more interesting, but creates harder to fix errors, than the one that requires a bit more work to maintain, and allows the authors to easily create the exact screen they want? 06.36.47 # there are no errors that I am currently aware of - it just works 06.36.55 # For relative positioning, not brickmania 06.37.18 # Relative positioning of elements - if the screen gets only slightly larger, elements that are evenly spaced may not be any more due to rounding differences 06.37.21 # hell, doom can scale it's screen to any size target, you don't have to rescale all the sprites it uses and make the maps work for each target, etc 06.37.28 # The author may prefer to keep them evenly space and just add padding on the outside edges 06.37.54 # You're refusing to address the actual problems with your method, instead citing examples where it does work. 06.38.01 # I've admitted in some cases it does work 06.38.04 # But there are cases where it doesn't, too. 06.38.12 # If you don't care about them, that's fine. But out and say it. Don't keep ignoring htem. 06.39.54 # and I think in most (if not all) cases it can work, I agree there might be an exception, but if you put some thought into it it ends up being alot less maintenance and work in the long run. You might have to make a minor sacrifice, but it's better than sacraficing your time and energy on tasks that do nothing to further real development 06.40.11 # There's no "if not all" about it. 06.40.18 # There are cases where it will, and must, fail. 06.40.39 # Scaling everything is not always going to give the best possible result. 06.40.50 # yes, there are no absolutes, but in the situation we are discussing I would be hard pressed to find one in the current sampling we have 06.41.03 # Ah yes, the "we don't need to care about the future" argument. 06.41.04 # Fair enough 06.41.20 # In the existing case, relative scaling is probably fine, especially now that most or all menus have been stripped of any artistry. 06.41.35 # Llorean: if that future comes then so be it, it can be dealt with then, but making bad decisions now doesn't help anything 06.41.46 # kkurbjun: But it's not a bad decision. It's simply a decision you don't like. 06.41.53 # Because "what if the scripts break" 06.41.59 # If the scripts *don't* break however, it works fine. 06.42.14 # what happened to checkwps not too long ago 06.42.16 # And while it's possible to avoid the scripts breaking, relative positioning is fundamentally broken from the get-go 06.42.24 # checkwps is far more complex. 06.42.31 # OK 06.42.33 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 06.42.37 # :-D 06.43.20 # As well, how would your relative positioning deal with different font sizes? 06.43.30 # A screen with 1.2 times the height is unlikely to use a font that's exactly 1.2 times the height 06.44.23 # You're basically thinking entirely in graphical senses from the samples you've given (brickmania and doom) were everything displayed can be scaled uniformly. But we don't scale fonts in lists, and are quite unlikely to any time soon. 06.45.06 # so plugin authors should be able to make skins that could very likely not work with the user selected font 06.45.24 # which would break just as much as a relative positioning 06.45.28 # if not worse 06.46.40 Join Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 06.48.00 # True, without some way to deal with fonts it's mostly useless for both cases. 06.48.26 # But even for scaling the core theme, relative positioning is going to have more troubles with fonts than allowing the author of the theme to simply tweak it after an automated pass. 06.53.24 Join sutefani [0] (n=6167a8db@giant.haxx.se) 06.54.23 Quit sutefani (Client Quit) 06.54.26 Join sutefani [0] (n=6167a8db@giant.haxx.se) 06.55.16 # Llorean: I'm not arguing to take away absolute positioning, but I think that relative positioning would be a good option for alot of problems 06.56.17 # and I could see plugin specific themes being a good place for them if the decision was made to allow them to be themed 06.56.47 # or if you took the theming out of the port and make it something like a universal theme that could cover plugin screens too then I wouldn't mind that 06.57.10 # I just would not want to have to work with each plugin's theme when doing a port 06.57.38 # In that case I would rather leave it to the themer than the plugin author 06.57.58 # and the plugin author could still create a theme/skin if they wanted to external to the main builds 06.59.30 Quit sutefani ("CGI:IRC (Ping timeout)") 07.01.12 Quit liar (Read error: 113 (No route to host)) 07.05.56 Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) 07.13.09 *** Saving seen data "./dancer.seen" 07.14.32 # * JdGordon has everything working corectly :) 07.14.56 # almost :p 07.21.52 # yay! actually working 07.24.09 Join sutefani [0] (n=spancrat@97.103.168.219) 07.25.07 # * sutefani waves. i'm reading the ircguidelines before sounding foolish. hope everyone's having a good night :-D 07.30.29 # sutefani: no worries, there's not too many people active right now though 07.31.15 # 8 hours earlier is usually more active 07.31.18 # right-o; kkurbjun. i just got my first rockboxable sansa from the wootoff, and i'm trying to figure it out. thanks for your reply! 07.31.38 # roger; perhaps if i have specific questions after this thorough read, i'll come back tomorrow 07.32.23 # (i haven't been in an irc chat in about ... 13 years. i'm feeling a bit nostalgic) ha! 07.34.08 Quit bluebrother (Nick collision from services.) 07.34.11 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) 07.35.17 # using relative positioning etc. for plugin( menu)s and having this work right on all screen size and aspect ratio is a dream and will probably look degraded on half of the screen sizes or lead to exceptions all the way. I rather have absolute positioning and more control about it - you have to do it once to adapt to new sizes, you need to do the work with the bitmaps anyways - and yes I did a lot of this for the c200 port and ported a few other 07.35.17 # plugins to different screen sizes 07.36.44 # in general. Surely some things could and should be improved but very carefully 07.37.41 Quit saratoga_ ("Page closed") 07.39.25 # New commit by 03jdgordon (r23606): remove 3 bad viewport functions: ... 07.39.38 # and I think the troubles with PLA proves my point that uniformity isn't always good 07.42.45 # " Batt:%bl %bc%ac%?lh<*|> %mh%ar%?ca<%?St|time format|<%cH|%cI>:%cM|--:--> " is the inbuilt sbs I'm planning on having (i.e the fallback when I screen forces it on but none are loaded)... any objections? 07.43.31 Join teru [0] (n=teru@ZQ174123.ppp.dion.ne.jp) 07.48.57 # New commit by 03jdgordon (r23607): fix build, ? buttonbar.... 07.56.43 # wouldn't --:-- show up on non-RTC targets? 07.56.58 # no, its #if-ed out for rtc 07.57.04 # non rtc 07.57.22 # and what about volume? 07.58.14 # this bar will almost never be displayed... its the absolute most crucial info only 07.59.45 # well, I found Llorean's argument earlier that you should know if pressing the "resume" button will deafen you very logical so I would say volume info is crucial too 07.59.56 # the only real screens which it will be visible in right now is the rec and fm screens... and both shuold be fixed to use the real sbs 08.01.51 # JdGordon: change for draw_slider() in onplay.c in r23606 doesn't looks correct for me. i think vp.x and vp.y should be replaced by 0? 08.02.20 # New commit by 03blue_dude (r23608): pcmbuf: bug fix with pcmbuf flush, code cleanup, added comments 08.02.38 # I think volume is far more crucial than RTC. 08.03.23 # teru: no? 08.03.45 # ok, I'll stick the volume in... just starts being low on space 08.03.59 Join kugel [0] (i=kugel@rockbox/developer/kugel) 08.04.05 # So drop the clock. 08.04.20 # but I think you guys are not understanding just how impossibly hard it will be to see this... 08.04.29 # Nothing bad's going to happen if your MP3 player isn't showing the time, several of the players simply can't, and most of the ones that can't don't in a lot of themes 08.07.40 Join Rob2223 [0] (n=Miranda@p4FDCCC69.dip.t-dialin.net) 08.09.37 Join Bagder [0] (n=dast@83.168.254.42) 08.11.16 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 08.11.19 Quit Dgby714 (Nick collision from services.) 08.11.20 Join DG-2 [0] (n=Dgby714@pool-173-78-89-195.tampfl.fios.verizon.net) 08.11.28 Nick DG-2 is now known as Dgby714 (n=Dgby714@pool-173-78-89-195.tampfl.fios.verizon.net) 08.11.30 # Bagder: can you put these test files on the download server? http://duke.edu/~mgg6/rockbox/applelossless.m4a and http://duke.edu/~mgg6/rockbox/a52_stereo_192.ac3 08.11.41 Join Unhelpful_ [0] (n=quassel@pool-71-173-205-32.hrbgpa.fios.verizon.net) 08.13.34 # done! 08.13.37 Join kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 08.14.05 Quit teru (lindbohm.freenode.net irc.freenode.net) 08.14.05 NSplit lindbohm.freenode.net irc.freenode.net 08.14.05 Quit Tuplanolla (lindbohm.freenode.net irc.freenode.net) 08.14.05 Quit droidcore (lindbohm.freenode.net irc.freenode.net) 08.14.05 Quit HBK (lindbohm.freenode.net irc.freenode.net) 08.14.05 Quit lol3 (lindbohm.freenode.net irc.freenode.net) 08.14.05 Quit Unhelpful (lindbohm.freenode.net irc.freenode.net) 08.14.05 Quit kadoban (lindbohm.freenode.net irc.freenode.net) 08.14.13 Nick KBH is now known as HBK (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 08.14.59 NHeal lindbohm.freenode.net irc.freenode.net 08.14.59 NJoin droidcore [0] (n=mark@69-196-151-127.dsl.teksavvy.com) 08.15.02 NJoin Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 08.15.10 Quit Rob2222 (Read error: 60 (Operation timed out)) 08.18.22 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 08.18.42 Quit sutefani () 08.20.09 # JdGordon: why do you introduce bugs without having a proper replacement? 08.20.32 # what bugs? 08.20.47 # I told you that set_*() need the current viewport, the buttonbar change is rather buggy too 08.21.14 # get the current viewport from the damn set_defaults() 08.21.36 # and I told you that that doesn't work always 08.21.51 # everywhere where you pass a non-NULL vp to do_menu() 08.22.29 # in that case the function i just removed wont help... 08.23.09 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.23.12 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.23.48 # I would have had to remove code from menu.c or list.c or anywhere... but i didnt... set_current was never set except for plugins 08.24.20 # so you broke several plugins 08.24.44 # nope 08.24.49 # they were broken befoe 08.25.37 # * kugel will just file a bug report later 08.26.16 # if any plugins broke because of tha chaneg, the build would have broken 08.27.22 # try setting the zoom level in pictureflow with a theme that uses ui vp/%Vi 08.28.18 # or is it even worse, all plugins use the ui vp now even if they are on a black background? 08.30.02 # ??? the loader disables the sbs/bar which means its always going to use the fullscreen 08.31.08 # it doesn't disable the ui vp 08.32.35 Join AndyIL [0] (n=pasha_in@212.14.205.32) 08.33.41 Quit kugel ("exit(0);") 08.36.23 Join Tomis [0] (n=Tomis@70.134.91.17) 08.37.54 # * JdGordon cant see the problem 08.39.03 Quit goffa (Read error: 104 (Connection reset by peer)) 08.41.20 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 08.43.28 Join goffa [0] (n=goffa@70.33.8.114) 08.43.56 Quit AndyI (Read error: 110 (Connection timed out)) 08.46.35 Join kugel [0] (i=kugel@rockbox/developer/kugel) 08.47.08 # JdGordon: I don't think plugins should use the ui vp if they don't draw lists or draw lists without backdrop 08.47.58 # then they will be using the fullscreen viewport and doing everything themselves 08.48.35 # you fixed no plugin to do that 08.48.58 # funny... all the ones i tried work exaclty like that 08.49.20 # with a ui vp enabled theme? 08.50.37 Quit phanboy4 ("Leaving") 08.50.42 # yep 08.53.16 Join flydutch [0] (n=flydutch@host119-166-dynamic.8-87-r.retail.telecomitalia.it) 08.59.33 Join liar [0] (n=liar@213142102130.public.telering.at) 09.05.21 Quit bertrik ("De groeten") 09.06.07 Join lol3 [0] (n=lol3@d198-166-19-110.abhsia.telus.net) 09.06.13 # TheSeven: pong 09.06.20 # TheSeven: what have you found out? 09.07.52 Join dmb [0] (n=Dmb@unaffiliated/dmb) 09.09.32 Quit dmb (Read error: 104 (Connection reset by peer)) 09.09.58 Join dmb [0] (n=Dmb@unaffiliated/dmb) 09.10.24 # kkurbjun: ping 09.12.17 # JdGordon: r23607 seems buggy too 09.13.12 *** Saving seen data "./dancer.seen" 09.14.06 Join gregorovius [0] (n=diego@190.55.80.21) 09.17.20 # Hi, one small thing that's bothering me: since upgrading my ipod 5.5g to 3.4, the song title/year and artist in the AAfreak theme get hidden behind the album art 09.18.01 # anybody seen this? I don't really know how wps works 09.21.23 # found something, will try 09.21.26 Quit gregorovius ("Leaving") 09.24.15 Join liar_ [0] (n=liar@213142102130.public.telering.at) 09.25.08 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.25.18 Quit liar (Operation timed out) 09.39.49 Quit kugel (Read error: 60 (Operation timed out)) 09.48.55 Join kugel [0] (i=kugel@rockbox/developer/kugel) 09.52.44 Nick liar_ is now known as liar (n=liar@213142102130.public.telering.at) 09.52.58 Join petur [0] (n=peter@rockbox/developer/petur) 09.59.30 Quit Thundercloud (Remote closed the connection) 10.02.34 Join dionoea_ [0] (n=dionoea@91.121.105.214) 10.05.22 Quit dionoea (Read error: 104 (Connection reset by peer)) 10.11.55 Quit reid05 (Read error: 110 (Connection timed out)) 10.12.03 Join reid05 [0] (n=reid85@CPE001cdf73661f-CM001ceacec55e.cpe.net.cable.rogers.com) 10.23.20 # Blue_Dude: ping (for the logs) 10.29.56 Quit Llorean (Read error: 104 (Connection reset by peer)) 10.34.37 Join uflops_ [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 10.34.38 Quit uflops (Read error: 54 (Connection reset by peer)) 10.34.43 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 10.37.52 Join Llorean [0] (n=DarkkOne@adsl-99-4-146-40.dsl.hstntx.sbcglobal.net) 10.38.19 Join kugel_ [0] (i=kugel@141.45.206.158) 10.44.42 Quit kugel (Read error: 60 (Operation timed out)) 10.54.34 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 10.57.57 Quit robin0800 (Remote closed the connection) 11.02.13 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 11.04.44 Quit robin0800 (Remote closed the connection) 11.11.00 Quit Grahack ("Leaving.") 11.12.04 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 11.13.15 *** Saving seen data "./dancer.seen" 11.18.26 Join Highlander [0] (n=Highland@mek33-4-82-236-45-205.fbx.proxad.net) 11.25.56 Quit freqmod_qu (Read error: 104 (Connection reset by peer)) 11.26.17 Join freqmod_qu [0] (n=quassel@129.241.208.240) 11.29.11 Quit Highlander ("Quitte") 11.30.44 Quit BHSPitMonkey (Read error: 113 (No route to host)) 11.35.51 Join DerPapst [0] (n=DerPapst@79.232.247.22) 11.35.54 Quit kugel_ (Read error: 110 (Connection timed out)) 11.37.08 Quit DerPapst (Read error: 131 (Connection reset by peer)) 11.37.26 Join DerPapst [0] (n=DerPapst@p4FE8F716.dip.t-dialin.net) 11.42.20 Quit bubsy () 11.47.01 Join bubsy [0] (n=bubsy@94.139.72.137) 11.49.33 Join Highlander [0] (n=Highland@mek33-4-82-236-45-205.fbx.proxad.net) 11.54.11 Quit shaggy-h (Read error: 104 (Connection reset by peer)) 11.54.34 Quit killan (Read error: 104 (Connection reset by peer)) 11.54.35 Join killan_ [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 11.59.20 Nick Unhelpful_ is now known as Unhelpful (n=quassel@rockbox/developer/Unhelpful) 12.07.30 Join robin0800_ [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.08.19 Quit robin0800 (Remote closed the connection) 12.10.07 Join kugel_ [0] (i=kugel@141.45.206.158) 12.10.56 Nick kugel_ is now known as kugel (i=kugel@141.45.206.158) 12.14.37 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.14.39 Quit AndyIL (Read error: 104 (Connection reset by peer)) 12.16.19 Join Lynx_ [0] (n=Lynx@xdsl-78-34-245-215.netcologne.de) 12.17.35 Quit JdGordon| (Read error: 104 (Connection reset by peer)) 12.19.20 # Unhelpful: indeed, you'd also probably need to tune the actual levels it went up and down at a bit, but hey 12.22.45 # TheSeven: yes, the USB driver boosts for MSC. Something that we probably need to finetune a bit, as probably not all targets need it 12.22.46 # Torne: yes, i saw about the complicated and long list of adjustable scaling triggers 12.24.11 # Unhelpful: the tradeoff is hilariously complicated 12.24.29 # you start with the assumption that you want to run as *fast* as possible so you get to being idle quicker 12.24.41 # then you go "wait shit but power changes with a square relationship to voltage" 12.25.00 # then you tear all your hair out and guess 12.30.37 Join kugel_ [0] (i=kugel@141.45.206.158) 12.30.48 Quit kugel_ (Read error: 104 (Connection reset by peer)) 12.38.25 Part LinusN 12.39.15 # Torne: in the case where the relationship is linear, and idle cycles still have high cost at high speed, yes, run-fas-then-idle is the way to go 12.39.47 # which i believe is about where things are with some other targets that have clock-only scaling and less efficient idle 12.40.06 Quit kugel (Read error: 104 (Connection reset by peer)) 12.40.14 # i think for beast the best we can manage is "try to run just about as fast as we need to to keep up" 12.40.59 # Unhelpful: Well, it depends 12.41.17 # ARM11 should idle pretty effiiently, as I believe we've already observed 12.41.53 # but the nonlinear relationship between speed and consumption is the trick 12.48.23 Join kugel [0] (i=kugel@rockbox/developer/kugel) 12.52.45 # if the voltage/clock relationship is roughly linear with auto voltage/clock scaling, and power has a square relationship to voltage, i don't think it *ever* makes sense to go faster than you "need to". if you finish the work in half the time, at four times the cost, it will hurt you even if idling the other half of the time is completely free. 12.53.21 Quit kugel (Read error: 131 (Connection reset by peer)) 12.53.52 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 12.58.31 Join kugel [0] (i=kugel@rockbox/developer/kugel) 12.59.23 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 13.03.34 # Unhelpful: The problem is working out how fast you actually need to, though 13.03.48 # Unhelpful: to actually get the "perfect" solution you need an oracle function 13.04.08 # which you can only implement perfectly in a statically scheduled hard-RT system :) 13.04.34 # it's one thing having the hardware to measure the pipeline busy/idle state and ramp up and down based on that 13.04.50 # but what that hardware doesn't know is what's coming next.. 13.05.19 # if we know "we need to do exactly X amount of work every Y milliseconds to continue to refill pcmbuf" then you could calculate the freq you need to be at to make that work just barely in time (static scheduling) 13.06.04 # the pipeline analyser doesn't know that although you are at 100% load right now, you are going to be idle in 10,000 instructions time at this rate, and thus you can afford to slow down. 13.07.39 # the automatic scaling in the hardware is more or less predicated on the assumption that a good approximation is to run at the slowest speed which doesn't cause the core to be fully utilised. 13.08.15 Join evilnick_ [0] (n=evilnick@ool-4571af51.dyn.optonline.net) 13.08.22 # this is pretty reasonable for an interactive system, but not a realtime one 13.08.29 # which is *kinda* what we are, when just doing playback ;) 13.09.08 Join Strife89 [0] (n=michael@adsl-81-160-3.mcn.bellsouth.net) 13.09.12 Quit Strife89 (Read error: 104 (Connection reset by peer)) 13.09.13 # So, yah. 13.09.19 # It's definately worth experimenting with 13.09.49 # But it's far from certain that letting it scale freq automatically will come out "better" than if we just implemented boosting using the same hardware and *also* turned on the appropriate voltage scaling to go with a boost/unboost freq 13.10.16 # the voltage scaling is basically an automatic win whatever we do though, so that should go on first :) 13.13.17 *** Saving seen data "./dancer.seen" 13.25.33 Quit seani ("Leaving") 13.25.54 Quit evilnick (Read error: 110 (Connection timed out)) 13.25.58 Quit petur ("reboot") 13.26.19 Nick evilnick_ is now known as evilnick (n=evilnick@ool-4571af51.dyn.optonline.net) 13.26.41 # also i doubt that freq/voltage is linear 13.31.17 Quit gevaerts (Nick collision from services.) 13.31.22 Join seani [0] (n=seani@78.33.109.70) 13.31.26 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 13.33.37 Join draft [0] (i=draft@damaged.ihku.org) 13.35.03 # howdy 13.35.21 # hrm. yes, that will be a problem. :/ 13.35.32 # great that the second generation iPod Nano is now cracked as well. has anyone here installed it? 13.36.08 # i might have some questions about Manually installing it from http://build.rockbox.org/data/rockbox-ipodnano2g.zip 13.40.39 Join uflops__ [0] (n=yogurt@90.231.195.226) 13.44.00 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 13.52.02 Quit seani (Remote closed the connection) 13.52.16 Join seani [0] (n=seani@78.33.109.70) 13.53.47 Quit kugel (Read error: 110 (Connection timed out)) 13.56.24 # gevaerts: It does make sense for nano2g though 13.56.42 # TheSeven: that's what I assumed after what you said :) 13.57.28 # TheSeven: Are you sure the work-threshold is 66MHz though? I'd expect 60 13.57.50 Join uflops__1 [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 13.58.28 Quit Highlander (Read error: 104 (Connection reset by peer)) 13.58.44 # well, 47923200 fails while 63897600 works 13.58.56 # TheSeven: one thing that may be wrong though is that we only boost when going to MSC mode, not when connecting. That's fine on PP, because the issue there is that packets larger than 96 bytes don't work without boosting, but if even small packets are unreliable that's not good enough 13.59.02 # so 60 may be true, even though I don't see any reason why it should fail at lower freqs 13.59.02 Quit uflops__ (Read error: 131 (Connection reset by peer)) 13.59.10 Quit uflops_ (Read error: 110 (Connection timed out)) 13.59.23 # it has huge fifos and an auxillary clock source for the whole utmi+ domain 14.00.12 # gevaerts: USB seems to instantly break even for smallish (8/16 byte) packets on nn2g at 47923200 14.02.16 # TheSeven: maybe a stupid question, but does it also break if you keep the voltage within spec? :) 14.02.29 Join kugel [0] (i=kugel@rockbox/developer/kugel) 14.03.05 # Torne: so, what we probably need is to set frequency manually when "only" decoding... unless there's some way we can manually feed dvfs our own measure of how "busy" we are? 14.04.07 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 14.07.16 Part Bagder 14.07.31 Join kugel_ [0] (i=kugel@141.45.206.158) 14.08.17 # but then if some interactive load needs more, we need to be able to boost. hrm. perhaps a cpu_boost for beast that uncaps DVFS, and a manually set frequency the rest of the time? 14.10.34 Quit kugel_ (Client Quit) 14.10.50 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 14.11.34 Quit z35 ("Leaving") 14.15.55 Join Biont [0] (n=chatzill@drsd-4db3d4d1.pool.mediaWays.net) 14.19.21 Join Bagder [0] (n=dast@83.168.254.42) 14.21.46 # Hi!the WPS I made is showing an ugly redraw bug after some changes I made, but I just can't find the mistake. I spent 2 hours looking over the code now and nothing seems to solve it. Is it possible that it just happens? 14.22.40 # I get the same glitch every time anmd it wasn't there before, so there must be a bug *somewhere* but I'm pretty desperate right now 14.25.50 Join angelwolf71885 [0] (n=chatzill@cpe-173-171-133-36.tampabay.res.rr.com) 14.30.43 Nick uflops__1 is now known as mikroflops_ (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 14.32.25 Quit Grahack ("Leaving.") 14.36.28 # OT, but how do I suppress join / leave / quite messages in IRC? Are they client specific, server specific, or some mysterious combo? 14.36.29 Quit DerPapst ("Leaving.") 14.36.49 # client-specific 14.40.21 # seani: which client? 14.42.51 # The client is "muxi", although I can see someone confirming the error of my ways :-) 14.43.05 # Oops "Smuxi" that is 14.44.10 # You can create a set of "On Connect" commands, I thought it might be one of those but... 14.46.37 # Unhelpful: haven't much of a clue, to be honest. I suspect we need to implement the code to control the hardware and then just fiddle about with it :) 14.49.44 Join drafti [0] (n=draft@91.153.112.66) 14.50.05 # Shouldn't Rockbox support 2nd Generation Nano? 14.50.17 # i just tried to run ipodpatcher and it says like this: http://pastebin.ca/1666483 14.52.18 # drafti: this is an ipodpatcher bug that was fixed in svn a while ago 14.54.24 Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 14.55.59 Quit kugel ("exit(0);") 14.56.00 Join petur [0] (n=peter@d54C6F9B2.access.telenet.be) 15.04.23 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 15.04.50 Join uflops_ [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 15.06.46 Join kugel [0] (i=kugel@rockbox/developer/kugel) 15.07.24 Quit kugel (Client Quit) 15.08.26 Quit angelwolf71885 (Remote closed the connection) 15.08.40 Join uflops__ [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 15.09.10 Join kugel [0] (i=kugel@rockbox/developer/kugel) 15.09.31 Quit kugel (Read error: 104 (Connection reset by peer)) 15.13.19 *** Saving seen data "./dancer.seen" 15.13.38 Join kugel [0] (i=kugel@rockbox/developer/kugel) 15.14.18 Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 15.16.46 Quit mikroflops_ (Read error: 60 (Operation timed out)) 15.18.50 Quit reid05 (Success) 15.19.21 Quit uflops__ (""Maailmanpyoramuualta"") 15.19.29 Join reid05 [0] (n=reid85@CPE001cdf73661f-CM001ceacec55e.cpe.net.cable.rogers.com) 15.19.58 Quit drafti (Remote closed the connection) 15.22.00 Quit liar (Read error: 104 (Connection reset by peer)) 15.25.40 # Can someone help me with my WPS code? I just can't get rid of a redraw glitch that's normally caused by overlapping viewports. But I can't find any mistake in it. Is it possible that it just happens when a WPS gets too complex? 15.25.51 Quit uflops_ (Read error: 110 (Connection timed out)) 15.26.41 # It's nothing severe, it's just ugly, because it cuts of 15-20px from the album art whenever playback is paused 15.27.51 # Maybe I just got blind for mistakes after spendig so much time with the WPS, if someone wants to have a look at it, I can post it on pastebin 15.28.01 Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) 15.28.32 # kugel: pong! 15.31.13 Join n1s [0] (n=n1s@rockbox/developer/n1s) 15.34.19 # Biont: is your wps available somewhere? I'm not an expert, but I imagine that maybe more people can help if they can actually see it :) 15.34.28 Quit Hadaka (Read error: 60 (Operation timed out)) 15.37.21 # gevaerts: The thing is, its a touch enabled theme for Cowon D2 and the simulator is outdated, so I'd had to upload some 30mb somewhere just to show it (including the new simulator which is pretty bloaty) 15.37.49 Quit kugel (Read error: 110 (Connection timed out)) 15.38.14 # *have 15.38.33 Join Naked [0] (n=naked@naked.iki.fi) 15.38.34 Nick Naked is now known as Hadaka (n=naked@naked.iki.fi) 15.39.01 Quit AEnima1577 ("Leaving.") 15.41.28 # Unless you have a D2, of course 15.42.31 # Biont: lots of people can build their own simulator :) 15.44.52 Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) 15.47.29 Join liar [0] (n=liar@213162066173.public.t-mobile.at) 15.47.34 Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) 15.48.31 # gevaerts: Okay then, give a minute 15.49.13 # Did the last crossfade update break the %xf tag? If so, where should I go to fix it? 15.49.37 Join evilnick_B [0] (i=0c140464@rockbox/staff/evilnick) 15.50.14 # Also, the changelog in the manual seems very out of date... 15.50.27 Join DerPapst [0] (n=DerPapst@asr-nat2.its.fh-giessen.de) 15.52.30 # gevaerts: http://www.mediafire.com/download.php?m1l03x2jijk 15.57.20 # * gevaerts tries to find how to pause the sim 15.57.37 # gevaerts: long click on album art/middle of the screen 15.58.54 # Biont: in absolute mode? 15.59.03 # * gevaerts isn't really used to touchscreens in rockbox yet 15.59.31 # Yes. Sorry, I forgot to mention that 16.02.24 # Biont: so the problem is, when you long click and it shows this "Options" box, the AA gets clipped? 16.03.39 Join AEnima1577 [0] (n=clbarnob@nc6521944.cns.vt.edu) 16.03.59 # gevearts: exactly. The problem showed up while fiddling around with the conditional viewports for the volume change display and I have no idea how to get rid of it 16.05.19 Quit Lss (Read error: 104 (Connection reset by peer)) 16.05.48 # Biont: there's more. If the screen turns off and I make it wake up again, the AA is gone 16.06.44 Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) 16.07.43 # gevaerts: I know. But I think that's just the way the skin engine works. It's not designed for that kind of stuff, after all 16.08.23 Quit polobricolo () 16.11.52 Join Strife89 [0] (n=michael@168.16.237.214) 16.16.14 Quit antil33t (Read error: 131 (Connection reset by peer)) 16.16.22 Join antil33t [0] (n=Mudkips@122-57-245-10.jetstream.xtra.co.nz) 16.16.22 # gevaerts: maybe that can be solved anyway, but I noticed the parser is very very picky about that 16.16.28 # Biont: I have to admit that this WPS is too complex for me right now :) 16.17.20 # gevearts: Okay no problem, maybe I'll find out myself. (I hope you like the wps anyway :) ) 16.17.48 # gevaerts: Thanks you for your time :) 16.17.51 # Biont: only it looks to me like you ask the AA not to be shown while paused 16.18.37 # Viewport c shows the AA, viewport d doesn't. 16.18.45 # Blue_Dude: The new crossfading works great - thanks for adding that extra option as that's precisely what I've always wanted 16.19.07 # So I think it looks like a bug that there are still bits of AA being shown when paused, not that there isn't enough of the AA :) 16.19.31 # If you're manually skipping tracks then it makes sense (to me) that you'd have the instant feedback of a non-crossfaded trackchange, for pocket operation etc. 16.19.41 # gevaerts: You're right. I'm working on that right now, but I fear that I did it that way for a reason "back then" 16.20.04 # evilnick_b: Welcome! It might need a bit of work, but it's 95% of the way there. I'm not really certain what the shuffle and man track skip option is for, but it was already there, so... 16.20.37 # The options might need some work on the naming system 16.21.01 # Er... I mean: The options could be named better/more obviously 16.21.48 # I tried to do some of that with the latest update. I thought there would be more screaming from the .lang purist crowd though. 16.22.38 # Shuffle now means that you need to have shuffle enabled, but that crossfades "auto"-changes AND manual changes, which to me seemed unexpected (from the name) 16.22.47 # But since I don't know what good the shuffle and man skip option is, I had a hard time coming up with a new name for it. 16.23.03 # And that's precisely where I'm now stuck :) 16.23.58 # Maybe we ought to ditch the second shuffle option and just fix the plain vanilla shuffle one. 16.24.38 # What would "expected" behavior be? Since I redid the decision tree, fixing crossfade behavior is trivial now. 16.27.43 Quit Strife89 ("Gone to class.") 16.27.53 Quit liar (Read error: 104 (Connection reset by peer)) 16.31.38 Join toffe82 [0] (n=chatzill@12.169.218.14) 16.33.55 # *sigh*....I don't get this theme myself any more. I guess I'll just live with that small issue 16.34.39 # asking the AA not to be shown when playback's paused seems to be the only way to do it 16.35.16 # Biont: can't you show the images option images on the same VP as the AA? 16.37.50 # gevaerts: Maybe, but I need a viewport for the different touch areas so that they don't interfere with each other, so I can as well show the images in their respective viewport 16.38.04 # gevaerts: Or did I miss something? 16.38.40 # I don't know. I do simple wpses :) 16.39.58 # it's a nice looking theme though. I spent a while trying to find your sbs until I saw that it was where I'd been looking all along, so it looks very well integrated :) 16.41.04 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 16.41.07 # gevaerts: thank you :) 16.42.03 # gevaerts: But making touchscreen WPS that actually have some functionality is still quite a pain atm. I think it doesn't get bigger thatn this anytime soon 16.43.00 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 16.43.33 # gevaerts: That's why I called for custom tags/actions in the forums :/ That would make many thing much more awesome^^ 16.43.41 # +s 16.46.26 # evilnick_B: for shuffle, maybe it should be much the same as Auto Track Skip, and only crossfade at the end of the track with shuffle enabled. Man track skips would still occur immediately. 16.47.04 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 16.48.33 # Blue_Dude: That'd get my vote, but it is changing an option that's been the other way round for quite a long time. 16.49.09 # Provided that it's a justifiable change then it probably should be changed, but perhaps worth sending a dev-ml email round? 16.49.44 # Yeah, I could see that. Right now it's really an Always if Shuffle option. 16.49.53 Quit AEnima1577 ("Leaving.") 16.50.23 # I'll send one off... 16.50.42 # Biont: I guess you have to talk to the experts for that 16.52.54 # gevaerts: I'll just keep on hoping that some of them comment on the thread :) 16.56.07 Join AEnima1577 [0] (n=clbarnob@nc6521ae5.cns.vt.edu) 17.02.04 Quit Zagor ("Don't panic") 17.10.00 Join liar [0] (n=liar@83.175.83.185) 17.11.42 # Any WPS tag gurus here? 17.11.53 Quit DerPapst ("Leaving.") 17.13.23 *** Saving seen data "./dancer.seen" 17.13.32 # will gcc let you pass litteral numbers (or ints with the value of the enum) to a function that takes an enum as a type? 17.13.45 # * n1s guesses no 17.14.45 # maybe if you cast it, but this isn't clean at all... why do you need to do this? 17.14.50 # For low memory targets, crossfade doesn't exist. So for those targets, should the crossfade WPS tag be removed entirely or just return 0? 17.16.44 Quit adiroiban ("Leaving.") 17.17.01 Quit seani (Remote closed the connection) 17.17.07 # I would have it still exist but return 0 so that WPSs can be used on low and high mem targets with the same screen size 17.17.30 Join seani [0] (n=seani@78.33.109.70) 17.17.43 # So keep the token but make it a dummy function? 17.17.44 # otherwise the theme site will have to sort targets by memory as well as screen which is bound to be confusing 17.18.24 # k 17.18.24 # i don't know how wps works, but IMO it should be implemented in a way that makes the token still work 17.19.54 Part draft 17.20.10 # It's supposed to return the crossfade enable state, but that setting doesn't exist for some targets. I made it return NULL just to get the thing to compile, but I'm thinking that just returning 0 (disabled) all the time might be a better approach. 17.20.38 # maybe having the crossfade state variable still exist and always be zero would be cleaner? 17.20.55 # Or get rid of the token entirely if it doesn't apply. That will cause syntax errors in the WPS script though. 17.20.57 # unless theres a lot of overhead to having it around 17.20.59 # TheSeven: some functions in sound.c take ints as args but are really passed the values of an enum, but i assume these values are saved in the settings so if i start converting these to take enum args i will have problems with the settings reading 17.21.06 Part toffe82 17.21.52 # if its just a few bytes having the variable still exist makes sense to me, asking if crossfade is enabled is perfectly valid even if you don't have it, the answer logically should be "no" 17.22.00 # saratoga: Nah, I killed off all related variables. It would only be needed in this one spot, and returning 0 is easy. 17.22.02 # then you should cast them at a point as near as possible to the settings code, i think 17.22.24 Quit seani ("Leaving") 17.23.06 # TheSeven: i guess so, not sure i will mess with it today though 17.23.11 Join polobricolo [0] (n=polobric@AGrenoble-257-1-29-75.w86-194.abo.wanadoo.fr) 17.24.19 # saratoga: I'll keep the token. I didn't think about sharing themes. 17.24.54 Nick dionoea_ is now known as dionoea (n=dionoea@91.121.105.214) 17.26.06 Join jgarvey [0] (n=jgarvey@cpe-174-097-130-131.nc.res.rr.com) 17.28.14 Join Strife89 [0] (n=michael@168.16.239.253) 17.31.22 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 17.33.41 Quit Dgby714 (Nick collision from services.) 17.33.41 Join DG-2 [0] (n=Dgby714@pool-173-78-89-195.tampfl.fios.verizon.net) 17.33.50 Nick DG-2 is now known as Dgby714 (n=Dgby714@pool-173-78-89-195.tampfl.fios.verizon.net) 17.36.47 # Hm. Where can you find a list of the \opt{} settings for the manual? 17.37.32 Join Strife1989 [0] (n=nds@168.16.239.253) 17.38.36 Join seani [0] (n=seani@78.33.109.70) 17.41.42 Join toffe82 [0] (n=chatzill@12.169.218.14) 17.43.28 # Blue_Dude: most are autogenerated from /apps/features.txt and the rest are in the platform files 17.43.52 # maybe not most 17.43.55 # Thanks very much, I'll look there. 17.44.22 # I'm trying to use the HAVE_CROSSFADE tag in the manual, but it ignores it... 17.45.30 # Oh I see. I'll add the tag in features.txt and it should behave... 17.47.01 Quit krazykit (Read error: 60 (Operation timed out)) 17.47.17 Join Omlet [0] (i=omlet05@91.182.34.16) 17.47.39 Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) 17.48.02 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 17.48.54 # If I add:#if defined(HAVE_CROSSFADE) \ crossfade \ #endif at the end of features.txt will it screw everything else up? 17.49.38 Join krazykit [0] (n=kkit@76.251.250.122) 17.52.46 Quit Biont ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 17.54.19 # New commit by 03nls (r23609): Comstify a function pointer array 17.54.32 # s/m/n/ 17.55.37 # Blue_Dude: that should not screw anything up, but iirc it's alphabetically(ish) sorted so you might not want to add it to the end 17.56.12 # functionally it doesn't matter where in the file you add it 17.56.42 # There's a note in the beginning about breaking backward compatibility. I really, really don't want to go there. 18.00.08 Part Bagder 18.02.38 Quit Strife89 ("My number of files is OVER 9000!") 18.05.33 Nick Strife1989 is now known as Strife89 (n=nds@168.16.239.253) 18.10.53 Quit Strife89 ("Going, going, gone.") 18.19.11 Join kugel [0] (i=kugel@rockbox/developer/kugel) 18.23.05 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 18.25.58 # Now that I've added a tag in features.txt, should I use it in the lang files? Would that save memory if I did? 18.28.13 # ah, but changing the order of the features will not break anything, changing the conditions so that a feature that was present on one device is no longer *will* and that breaks voice files 18.28.43 Join gtkspert [0] (n=gtkspert@124-169-86-150.dyn.iinet.net.au) 18.29.05 Quit einhirn (Read error: 104 (Connection reset by peer)) 18.29.23 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 18.29.36 # Blue_Dude: it could save memory on devices that don't have te feature if they previously had the string but it will break voicefiles on those devices, btu now that we have pretty regular releases i don't know how much we care about the voicefiles 18.29.40 # Right now the crossfade lang tags are keyed to swcodec. You're saying that changing them to crossfade would be a bad idea? 18.29.42 # ... breaking 18.29.53 # Blue_Dude: no 18.30.27 # Blue_Dude: i'm saying that it will break compatibility with older vociefiles on the targets which have swcode but not crossfade 18.30.45 # which are those targets btw? 18.31.50 # There are only three that have swcodec but not crossfade: Sansa Clip, Sansa c200v2 and Sansa m200v4 18.32.30 # you should be fine then 18.32.41 # At least, those are the only ones that showed any memory savings when I carved out crossfade code a day or two ago. 18.32.43 # as those are unstable targets with serious bugs anyway 18.33.08 # So just do it and get it over with? :) 18.35.20 # I'm going to commit what I've got and tweak the lang files later... 18.35.24 # sure 18.35.25 # Blue_Dude: none of those actually works properly anyway 18.35.54 # OK. It's going to be cut and paste for a while, but better to do it now than later. 18.36.14 # I'll post lang changes tonight. 18.36.22 # Manual changes coming right up though. 18.36.37 # the reason for this somewhat unfriendly behaviour of the voice system is that it's very simple and lacks proper version management 18.38.01 # New commit by 03blue_dude (r23610): Add crossfade feature tag, update manual, fix crossfade WPS tag behavior 18.38.12 Quit phanboy4 (Read error: 104 (Connection reset by peer)) 18.38.21 Quit kugel (Connection timed out) 18.39.15 Join funman [0] (n=fun@rockbox/developer/funman) 18.39.28 Quit fyre^OS (Read error: 60 (Operation timed out)) 18.44.17 Quit gtkspert_ (Read error: 101 (Network is unreachable)) 18.47.41 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 18.47.43 Join DerPapst [0] (n=DerPapst@p4FE8F716.dip.t-dialin.net) 18.47.48 Quit Sajber^ (Read error: 131 (Connection reset by peer)) 18.52.01 Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) 18.56.18 Quit funman ("free(random());") 18.58.57 Quit AEnima1577 (Read error: 104 (Connection reset by peer)) 18.59.22 # I may say, despite the fact there may be changes in the works, messing around with themeing / wps is fun. Any plans for multiline / text wrapping? I can always scroll of course but on a C240 lots of ghosting 18.59.29 Quit fyrestorm (Read error: 60 (Operation timed out)) 19.00.02 Quit petur ("later") 19.00.15 Join antil33t1 [0] (n=Mudkips@219-89-245-231.adsl.xtra.co.nz) 19.00.21 Quit antil33t (Nick collision from services.) 19.00.43 Join Tomis2 [0] (n=Tomis@70.134.74.152) 19.01.03 Quit ender` (" Replication with a nonconfigured partner is not allowed. -- net helpmsg 4006") 19.01.44 # I played around a lot with colour schemes (basically settled for black on white), contrast, brightness and scrolling settings to get less blur on my c200's display. Values most probably vary per actual target (screen) 19.01.59 Join AEnima1577 [0] (n=clbarnob@nc6521ae5.cns.vt.edu) 19.02.56 Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) 19.03.04 # pixelma: Yes. I've gone for essentially a few shades of amber on black (for nighttime use) and scrolling that's jerkier and slower rather than smoother and faster 19.03.35 # pixelma: Smooth and fast looks great in the sim. F40, very different on a C240. 19.04.20 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 19.04.37 Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) 19.05.32 Join gtkspert_ [0] (n=gtkspert@203-206-49-158.dyn.iinet.net.au) 19.05.44 Join ChelseaToner [0] (n=chelsea@host-84-9-246-159.dslgb.com) 19.05.44 Join shaggy-h [0] (n=kiwi@host-87-74-127-193.dslgb.com) 19.07.09 Join funman [0] (n=fun@rockbox/developer/funman) 19.07.13 Quit Tomis (Read error: 110 (Connection timed out)) 19.07.13 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.74.152) 19.08.29 # Hey - Having problems putting music on to my 2nd gen ipod nano now that I've put Rockbox on it. None of my music applications (gtkpod, banshee, rythmbox etc) will recognise it. I can put music on it if i change to the apple firmware, but the music still doesn't appear on Rockbox when i switch back. I am aware that the 2nd Gen ipod nano isn't fully supported yet, is this a common problem with generation of devices? Or am i doing someth 19.08.29 # ing wrong? 19.09.19 # either drag and drop your music onto the nano, get software that can add music to an MSC device, or use the rockbox database so you can see music added by the Apple software 19.10.05 # ChelseaToner: also check file view is set to all 19.10.29 # robin0800: why? 19.11.37 # gevaerts: to make sure you can see hidden files etc. 19.12.41 # i don't think you can use and ipod as a mass storage device either way.. I'll try anyway 19.12.55 # sure you can 19.13.19 # ChelseaToner: set it to disc mode in i-tunes 19.13.24 *** Saving seen data "./dancer.seen" 19.14.38 # I don't have i-tunes. Is there an alternative way? 19.15.38 # if you don't have itunes it should show up as an msc device 19.15.53 Quit shai ("Leaving") 19.15.58 # itunes hides this fac on systems where its installed 19.16.18 # fact and it's 19.17.08 Quit gtkspert (Read error: 101 (Network is unreachable)) 19.19.46 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 19.20.39 # is there a way i can build rockbox using cygwin 19.20.50 # polobricolo: Yep, that's on the Wiki 19.20.57 # ok 19.21.33 Join funman_ [0] (n=fun@rockbox/developer/funman) 19.22.36 Nick funman_ is now known as namnuf (n=fun@rockbox/developer/funman) 19.23.40 # the thing is i don't have any problems to use the cross-compiler (i build my own arm code succesufully) the thing is i get a "No rule to make target '/home/Paul/rockboc/tools/root.make'" 19.23.46 Join iHPUser [0] (n=84aa5785@giant.haxx.se) 19.23.49 # but i checked the file exists 19.25.02 # i get that error when running make 19.25.50 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.26.12 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 19.31.03 # Is it possible to install a larger hdd on an iRiver iHP-140 using rockbox? The standard is 40g, if I put anything larger in it will it be readable? 19.31.59 # iHPUser: Yes 19.32.13 # iHPUser: i would say yes by rockbox but maybe not with the original firmware 19.32.46 # There's the usual 137GB limit to using the regular builds, but if you can compile your own then it's a simple couple of changes. 19.33.19 Join freddyb [0] (n=fred@pool-70-104-101-195.chi.dsl-w.verizon.net) 19.33.25 # iHPUser: I've used a 60GB drive in an H140 successfully 19.33.53 # As long as rockbox is as stable as the original firmware, I don't see any reason to go back to the OF. 19.34.05 # iHPUser: http://www.rockbox.org/wiki/HardDriveReplacement may help in choosing a working disk 19.35.13 # anyone has an idea about the problem in cygwin with root.make not found 19.36.01 # polobricolo: did configure run without problems ? 19.36.14 # Is there any top limit that the hardware can't handle, I don't want to drop a 500G hdd in and not be able use it all (after doing the custom compile)? 19.36.52 # iHPUser: for ihp1x0 staying under 137gb is preferable.. (it gets complicated if you want to use more) 19.37.23 # iHPUser: I don't think there are 50 pin drives bigger than 80GB 19.37.25 # You're also limited by the dimensions of the case, unless you want to start using desktop drives 19.38.14 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 19.38.14 # there are adapters for ZIF-40 drives though, but then you run into fun space issues in the case 19.39.11 # 80G should be fine at this point -- I've seen 320G Samsung 1.8" drives though 19.39.34 # 1.8", yes, but probably not PATA, and definitely not 50 pin 19.39.35 # I didn't see the pins on them though 19.41.08 # domonoky: as on my linux box a warning becausemy arm-elf-gcc is too recent 19.41.14 # *because my 19.41.43 Quit funman (Read error: 110 (Connection timed out)) 19.41.51 Nick namnuf is now known as funman (n=fun@rockbox/developer/funman) 19.41.54 # polobricolo: maybe line ending issues? 19.42.21 # polobricolo: are you trying now on linux or cygwin ? 19.43.03 # i'm on cygwin (i can't use linux right now) 19.43.52 # but did configure in cygwin give any error ? 19.44.46 # no just the gcc version warning (but i had this warning on linux too) 19.45.23 # is there an ipodpatcher zip i could download but with nano2g support 19.45.42 # generally you should use the recomended gcc/binutils versions.. (can be installed with rockboxdev.sh (at least on linux)) 19.46.52 # * domonoky points to the wiki for ipodpatcher 19.47.12 # take a look at the IpodNano2GPort page 19.49.44 Join stoffel [0] (n=quassel@p57B4C236.dip.t-dialin.net) 19.50.13 Join Strife89 [0] (n=michael@168.16.237.214) 19.52.10 # Ugh. 19.52.33 # I can't find any information on how to tell a v1 Fuze from a v2 without opening it. 19.52.42 # I was just looking at modding the iHP with a compact flash card, looks good but gives less space than I have currently. Would it be possible just to put a solid state drive in it? 19.53.24 Part polobricolo 19.53.43 # Strife89, I think it has a different original firmware version 19.54.55 # This one I just got has firmware version 01.01.07A 19.56.37 # Nevermind, they're too big 19.56.58 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-mvmsqwoxxasrczry) 19.57.00 # iHPUser: there are SSDs that fit 19.57.21 # I'm going to assume that that's a v1. 19.58.40 # Strife89, I think that's correct, see for example http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=33874 20.00.34 # bertrik: Would it be better to update the firmware to 01.02.28, or leave it? (I intend to put Rockbox on it when the port is finished, naturally. 20.00.51 Part ChelseaToner ("Leaving") 20.03.25 # Strife89: no need to update it, rockbox already works pretty good on the v1 fuze :-) 20.03.32 # gevaerts: I just found some, they're incredibly expensive. 20.03.35 # Come to think of it, I'd be willing to test it, since it's in the Unstable section. 20.05.04 Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) 20.05.14 # iHPUser: I think some people have used photofast ssds in irivers 20.05.39 # Strife89, whether to update is up to you (I would do it, I'm an update-junkie). It will get upgraded during rockbox installation anyway (during installation the OF is replaced with a patched OF + rockbox bootloader) 20.06.04 # Ah. 20.08.05 Quit JdGordon| (lindbohm.freenode.net irc.freenode.net) 20.08.05 NSplit lindbohm.freenode.net irc.freenode.net 20.08.05 Quit Strife89 (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit bertrik (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit DerPapst (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit Dgby714 (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit reid05 (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit fdinel (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit Horscht (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit robin0800 (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit robin0800_ (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit Bob_C_ (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit AaronM (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit amiconn (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit kkurbjun (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit thegeek (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit blithe (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit FOAD (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit togetic (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit BlakeJohnson86 (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit topik (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit ej0rge (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit Tristan (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit GodEater (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit jordan`` (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit jhulst (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit ps-auxw (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit markun (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit rjg (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit fish_ (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit Overand (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit elcan (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit fxb__ (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit feisar- (lindbohm.freenode.net irc.freenode.net) 20.08.05 Quit knittl (lindbohm.freenode.net irc.freenode.net) 20.12.26 # gevaerts: Those are nice looking but still quite expensive. I did find an adapter to make SDHC to CF, I think that will work. 20.12.58 # iHPUser: maybe, maybe not. I tried one of those in my h300, and it didn't work 20.13.04 Join hebz0rl [0] (n=hebz0rl@dslb-088-065-058-079.pools.arcor-ip.net) 20.13.15 # they're cheap enough to just try of course 20.14.13 # The one I found has a 16G limit though, smaller than what I currently have 20.15.12 Join Sajber^ [0] (n=Sajber@h-65-31.A213.priv.bahnhof.se) 20.17.47 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.18.08 Join domonoky1 [0] (n=Domonoky@g229178033.adsl.alicedsl.de) 20.18.15 Join antil33t [0] (n=Mudkips@222-152-89-3.jetstream.xtra.co.nz) 20.20.43 # Thanks all 20.21.24 Quit funman ("free(random());") 20.22.10 NHeal lindbohm.freenode.net irc.freenode.net 20.22.10 NJoin bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.22.42 Quit iHPUser ("CGI:IRC") 20.22.51 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-sewrjeiecjqibdwo) 20.23.19 Quit domonoky (Read error: 104 (Connection reset by peer)) 20.23.29 Quit flydutch ("/* empty */") 20.24.28 Join ender` [0] (i=krneki@foo.eternallybored.org) 20.31.04 Quit antil33t1 (Read error: 110 (Connection timed out)) 20.35.10 NJoin Strife89 [0] (n=michael@168.16.237.214) 20.39.13 Join kugel [0] (n=kugel@rockbox/developer/kugel) 20.42.32 Quit antil33t (Read error: 145 (Connection timed out)) 20.43.07 Quit HellDragon (Read error: 104 (Connection reset by peer)) 20.43.19 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 20.47.26 NJoin markun [50] (n=markun@rockbox/developer/markun) 20.47.26 NJoin Overand [0] (i=overand@crappy.domain.name) 20.47.26 NJoin elcan [0] (i=user36@pr0.us) 20.47.26 NJoin feisar- [0] (i=jljhook@irkki.fi) 20.47.26 NJoin ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) 20.47.26 NJoin fish_ [0] (n=fish@freigeist.org) 20.47.26 NJoin fxb__ [0] (n=felixbru@h1252615.stratoserver.net) 20.47.26 NJoin knittl [0] (n=knittl@unaffiliated/knittl) 20.47.26 NJoin rjg [0] (i=rgordon@odie.tomelliott.net) 20.48.01 NJoin DerPapst [0] (n=DerPapst@p4FE8F716.dip.t-dialin.net) 20.48.01 NJoin Dgby714 [0] (n=Dgby714@pool-173-78-89-195.tampfl.fios.verizon.net) 20.48.01 NJoin reid05 [0] (n=reid85@CPE001cdf73661f-CM001ceacec55e.cpe.net.cable.rogers.com) 20.48.01 NJoin fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 20.48.01 NJoin Horscht [0] (n=Horscht2@xbmc/user/horscht) 20.48.01 NJoin robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 20.48.01 NJoin robin0800_ [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 20.48.01 NJoin Bob_C_ [0] (n=chatzill@host86-142-212-198.range86-142.btcentralplus.com) 20.48.01 NJoin AaronM [0] (n=Aaron@adsl-4-241-157.mem.bellsouth.net) 20.48.01 NJoin amiconn [0] (i=quassel@rockbox/developer/amiconn) 20.48.01 NJoin kkurbjun [0] (n=kkurbjun@c-98-245-170-51.hsd1.co.comcast.net) 20.48.01 NJoin thegeek [0] (n=nnscript@s168c.studby.ntnu.no) 20.48.01 NJoin blithe [0] (n=blithe@blakesmith.me) 20.48.01 NJoin FOAD [0] (n=dok@dinah.blub.net) 20.48.01 NJoin togetic [0] (n=togetic@unaffiliated/ibuffy) 20.48.01 NJoin BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 20.48.01 NJoin jhulst [0] (n=jhulst@jhulst.com) 20.48.01 NJoin jordan`` [0] (n=jordan@78.235.252.137) 20.48.01 NJoin GodEater [0] (n=bibble@rockbox/staff/GodEater) 20.48.01 NJoin Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 20.48.01 NJoin ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) 20.48.01 NJoin topik [0] (i=awesome@213.203.214.114) 20.52.56 # A theme / language question: if I'm including plain text - "Artist" - in a conditional - %?ia<%ia|Artist Unknown> how do I "nest" this with the new language neutral format? 20.54.01 Quit crwl (lindbohm.freenode.net irc.freenode.net) 20.54.01 NSplit lindbohm.freenode.net irc.freenode.net 20.54.01 Quit crashd (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit tha (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit ThomasAH (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit Kohlrabi (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit bzed (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit Dhraakellian (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit jds2001 (lindbohm.freenode.net irc.freenode.net) 20.54.01 Quit CIA-6 (lindbohm.freenode.net irc.freenode.net) 20.54.02 Join bzed_ [0] (n=bzed@devel.recluse.de) 20.54.03 Join Kohlrabi_ [0] (n=Kohlrabi@frustrum.nosebud.de) 20.54.04 Join tah [0] (n=thomas@aktaia.intevation.org) 20.54.05 # Actually I'll pop that in the forum may be general and fiddly to discuss here 20.54.10 NHeal lindbohm.freenode.net irc.freenode.net 20.54.10 NJoin tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) 20.54.11 Join Dhraakellian [0] (n=ntryon@72.226.197.191) 20.54.16 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 20.54.19 Join crashd [0] (i=foobar@195.62.28.70) 20.54.31 NJoin crwl [0] (n=crwlll@a91-156-100-168.elisa-laajakaista.fi) 20.54.37 Join CIA-5 [0] (n=CIA@208.69.182.149) 20.55.39 Nick tah is now known as ThomasAH (n=thomas@aktaia.intevation.org) 20.56.25 Join phanboy4 [0] (n=benji@gate-20.spsu.edu) 20.59.22 # I'm not sure you can have the "unknown" part in this. As I understood you can reuse language strings that exist in the rest of Rockbox (for the menus, info screens, splashes etc), would have to look up in a language file what exists 21.00.03 # haven't tried this tag myself yet though 21.01.22 # is this documented yet (CustomWPS or manual)? 21.02.11 Quit goffa (Read error: 113 (No route to host)) 21.04.34 Join goffa [0] (n=goffa@70.33.8.114) 21.05.20 Quit StealthyXIIGer (Connection timed out) 21.06.12 # pixelma: Quite right, JDG is correcting me :-) It's documented in a sticky in the forum. 21.07.15 Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) 21.07.17 # I wouldn't call that documentation 21.07.17 # Ugh. 21.07.29 # I'm trying to make the bootloader for the Fize. 21.07.37 Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell) 21.07.53 # Strife89: the Fize isn't supported 21.08.00 # mkamsboot says that it is "unable to open bootloader-fuze.bin". 21.09.17 # gevaerts: Good point, but it would appear that you might be hosting a broken piece. 21.09.52 Quit Addison__ ("Leaving") 21.10.26 # * bertrik should enable SDRAM for meizu m3 tonight 21.11.09 # Strife89: IIRC you need bootloader-fuze.sansa (if you indeed have a fuze, and not a fize like you claimed) 21.11.13 # seani: there is also a generic "unknown" string so you could combine the two but the resulting combination might not work (nicely) in all languages 21.11.37 # gevaerts: Ah, I didn't notice the typo. Yes, I have a *Fuze*. :) 21.11.38 Join Stephen_ [0] (n=S@86-40-191-208-dynamic.b-ras2.srl.dublin.eircom.net) 21.12.19 # gevaerts: I downloaded that file, using the link in the Fuze manual, and followed the instructions to combine it with the Fuze OF with mkamsboot. 21.12.54 # Strife89: yes, I mean you need to run "mkamsboot fuzea.bin bootloader-fuze.sansa patched.bin " 21.13.25 *** Saving seen data "./dancer.seen" 21.13.46 # Ah, whoops. 21.14.02 # I had typed "bootloader-fuze.bin" instead. 21.14.15 # The idiot strikes again! 21.14.31 # that's what the manual says :) 21.15.10 # seani: http://svn.rockbox.org/viewvc.cgi/trunk/apps/lang/english.lang?revision=23605&view=markup for a reference 21.15.12 Quit kugel (Read error: 60 (Operation timed out)) 21.15.17 # That I'm an idiot, or what? 21.15.28 # Seriously. 21.15.39 # no, the manual says bootloader-fuze.bin, but that's wrong 21.15.44 # Ah. 21.15.47 # I see now. 21.16.49 # pixelma: Thanks, JDG makes a good point that if I restyle it as "Artist: Unknown" it's would probably work with two separate translated string, unlike "Unknown Artist" as a "phrase" 21.17.32 # Strife89: please tell us if it works :) 21.17.51 # gevaerts: The Fuze is in the Firmware Upgrade process now. 21.18.53 # seani: more likely yes 21.19.02 Join Nz17 [0] (n=nz17@host-72-174-158-57.vrn-ut.client.bresnan.net) 21.19.35 # Which is better for a Rockbox user, Sansa e200 or c200? 21.20.16 # e200 21.20.22 # depends 21.20.40 # Most likely an e200, but as gevaerts said, it depends. 21.20.48 # Well I want long battery life, FM usage, and Ogg/FLAC. 21.20.49 # e200 has bigger and higher quality screen, but is also bigger and heavier 21.21.03 # and has a scroll wheel 21.21.03 # Weight and size doesn't matter. 21.21.12 # Ooh, scrollable. :) 21.21.23 # I think the e200 has a bigger battery than the c200 21.21.37 # That's what the table seems to indicate. 21.21.46 # Nz17: The e200 lasts about 4-6 hours longer than a c200, I think. 21.22.02 # I see. 21.22.14 # battery life with the c200 is really ok too though 21.22.26 # I guess what I'm also trying to do is find something cheap too. ;) 21.22.46 # also, while I think the v1 is probably still preferable for normal users, the e200v2 should work without problems, while the c200v2 port isn't as far yet 21.23.15 # That's important to remember. 21.23.23 # one other advantage of the e200 would be that there are ones with a bigger internal memory. Although with a microSDHC that gets a little less important 21.23.34 # :) 21.24.02 # Well I'm going to see if eBay has any listings for wall and car adapters for the e200 then. :D 21.24.21 Quit dfkt (Nick collision from services.) 21.24.29 Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) 21.24.33 # e200s exist with or with radio, while c200 seem to be sold with a label "with or without radio" but still both have the hardware (at least all reports I read suggest that) 21.25.11 # gevaerts: It boots nicely - in 1.5 seconds flat! 21.25.57 # Nice. But there is a warning about FM on the table at http://www.rockbox.org/wiki/BuyersGuide . 21.26.03 # New commit by 03gevaerts (r23611): The downloaded bootloader is bootloader-e200v2.sansa or bootloader-fuze.sansa, not bootloader-e200v2.bin or bootloader-fuze.bin 21.26.15 # TheSeven, I think you implemented pcm_play_dma_get_peak_buffer, right? there's still a comment saying it isn't implemented 21.27.35 # shall I remove it (the comment)? 21.28.04 # gevaerts: I don't see anything on that page about the Fuze. Perhaps you meant this? http://www.rockbox.org/wiki/SansaAMS 21.28.47 # Strife89: huh? 21.28.59 # bertrik: you may do so :-) 21.29.06 # gevaerts: Whoops, wrong person. ^^; 21.29.15 # this is (of course) still true for the corresponding rec function though 21.29.38 # gevaerts: I thought Nz17 was speaking to me back there. "Nice, but there's a warning on the radio." 21.29.48 # I was. 21.29.58 # It says, "Some" for the e200 series. 21.30.55 # New commit by 03bertrik (r23612): pcm-s5l8700: add missing header file, remove out-of-date comment 21.31.13 # which header was missing? 21.31.33 # Nz17: Ah. 1) I thought you were speaking about the Fuze I just set up. 2) Right; Rockbox fails to detect the FM Radio on some e200s. 21.31.45 # :/ 21.32.25 # Strife89: does it? 21.32.28 # I wish these hardware companies would take a lesson in consistency and external markings. 21.32.34 # gevaerts: Does it what? 21.32.41 # That table means that they don't all have FM 21.32.42 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 21.33.01 # Strife89: fail to detect FM 21.33.02 # gevaerts, Nz17 : Ah; my mistake. 21.33.34 # I guess I'd better be careful about which one I buy from eBay. 21.33.43 # Unless you guys have a favorite you'd like to recommend. 21.34.10 # Nz17: Likely not in their interests. If customers differentiate on an unadvertised / inadvertent / unsupported feature or side effect, they could find themselves with more stock on their hands 21.34.44 # I guess it's just not fair by design. 21.35.17 Quit robin0800 (Remote closed the connection) 21.36.02 # Nz17: Life in general, then. 21.36.12 # ;) 21.36.23 # I ordered from here and got v2 with FM - http://cgi.ebay.ie/Sandisk-Sansa-e280-8GB-MP3-Player-1-8-LCD-Voice-Record_W0QQitemZ390051198347QQcmdZViewItemQQptZUK_AudioTVElectronics_PortableAudio_MP3Players?hash=item5ad0dcf58b&_trksid=p3286.c0.m14 21.37.17 # what's the policy on bug reports in Flyspray for unstable targets? is that ok? 21.37.27 # I think so 21.37.31 # I can't decide if this car adapter is brilliant or stupid: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=370261065299 21.37.46 # The rule was about supported targets, which unstable targets are 21.38.18 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 21.38.20 # * shotofadds has a look 21.39.23 Quit barrywardell () 21.39.30 # well, the FlySpray doesn't have any rules at all ;) 21.39.39 # *wiki page 21.41.47 # Nz17: this adapter looks very similar to one from belkin 21.42.13 # just a white case instead of a black one and the led in a slightly different position (and red instead of blue) 21.42.36 # Gah, I hate blue LEDs - they are so bright! 21.43.08 # the belkin one has the led internally and just a translucent piece of plastic to the outside where it shines through - looks nice and isn't too bright 21.43.18 Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) 21.43.30 # it's a blueish-glowing light strip instead of a red point 21.43.59 # Oh, maybe I should check it out. 21.44.09 # Either one, I'm starting to think the adapter is brilliant - it can be used with any PMP that charges via USB. The only problem is you need your device's USB cable to use it. 21.44.27 # the e200 (and c200) has blue LEDs too ;) 21.44.30 # I suspect your claim there is mistaken ;) 21.45.01 # USB charging is, to my great disappoitnment, way more complicated than you might think 21.45.28 # Yeah... wait, huh? 21.45.45 # the belkin one is pulling the data pins to iirc 2.8 and 2.0 volts to make at least the zen and the ipods even recognize it 21.46.00 # that still doesn't cover everything, no? 21.46.03 # New commit by 03bluebrother (r23613): Fix missing space caused by incorrect usage of the \dap macro (FS#10774 by Diego Herranz). 21.46.15 # I thought USB is supposed to be 5v? 21.46.20 # there's also D+/D- shorting for very recent things that follow the ccharging spec 21.46.25 # Nz17: yes, at the power pins 21.46.29 # Nz17: Charging from USB is generally a spec violation. 21.46.42 # Nz17: people make this less bad by trying to detect the charger specifically 21.46.44 # >:( 21.46.46 # Torne: not neccessarily 21.46.52 # TheSeven: well yes. we've been through this one ;) 21.46.57 # The way many devices do it is a spec violation. 21.47.17 # some people are not quite that brave and do soemthing that's still wrong but less likely to be horrible :) 21.47.21 # actually, what the ipods are doing is rejecting non-apple chargers while *still* violating the spec... 21.47.26 # indeed 21.47.36 # Well, they don't *now* 21.47.49 # the current devices use the real charging spec 21.48.01 # really? so they don't work with old apple chargers? nice one. 21.48.44 # indeed 21.48.47 # see iphone 21.48.51 # Ooh that Apple - if it didn't have the "cool" image it wouldn't get away with half of what it does. 21.48.53 # there are also some inbetween ones which do both 21.49.06 # and some apple chargers *implement* both, with a crazy resistor network 21.49.16 # i've had great fun finding all this out, and trying to decide what we should do ;) 21.49.47 # i can't say i've decided. 21.49.57 # i mean not tha tit's down to me but i've not decided what my opinion is ;) 21.51.31 # ... 21.51.51 # hm, my opinion is to allow the user to choose either the standards compliant way or the "drain whatever you get" way 21.51.59 Quit robin0800_ (Connection timed out) 21.52.28 # and maybe a third choice that still tries to obey the 100mA limit if it enumerates that way but drains 500mA if the host isn't responding at all 21.52.42 # yeah i was gonna try for some compromise 21.52.47 # but haven't ahd time/motivation to implement any of the above yet :) 21.52.53 # things get even worse if we also take into account that some devices can do 100/500/1000mA nowadays 21.53.23 # (with 1000 being only allowed from charging-spec compliant chargers and USB3) 21.53.26 # TheSeven: drawing more than 500 without the thing on the other end shorting D+/D- or ossibly being an apple charger is probably a very bad plan 21.53.37 # even if the user tells us to :) 21.53.49 # most chargers support 1000 21.54.11 # yes, but if you don't know it is one, then that's quite a lot worse than just pulling 500 without knowing, no? 21.54.24 # because loads of devices do that already so most of hte bad usb ports have been weeded out by natural selection ;) 21.54.33 # You guys have to deal with way too much trouble. ;) 21.54.41 # (clearly darwinian evolution is the way to decide specs) 21.55.34 # Don't say that or IE will get you. 21.56.19 # hm, if you do 1000 on a charger that doesnt support it, you will hit it's inner resistance and thus drop the voltage a little, making it in fact draw around those 500mA the charger supports but moving heat dissipation from the PMU to the charger :-) 21.56.28 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.56.44 # TheSeven: Hooray :) 21.56.56 # TheSeven: This is one of those "no good answer" things. 21.57.20 # Especially givent hat *even* being spec compliant can still cause bad things to happen. Its not *your fault* then, but hte bad things can still happen while your device is plugged in :) 21.57.43 # so *someone* will blame you. 21.57.56 # basically the worst that can happen is the charger getting blown :-P 21.58.07 # Not at all :) 21.58.13 # Think of dodgy ports on laptops, etc 21.58.14 # which is some way of darwinian evolution as you said above :-D 21.58.20 # See if you can mmelt the entire motehrboard :) 21.58.40 # you can do way worse than crisping a charger if you have a sufficiently pathological combination of stupid broken hardware. 21.59.02 # ports on laptops will enumerate properly, and even if they don't, they can either supply 1000mA (lots of external hdds need this) or will just shut off the port if we're sucking too much. we may re-try drawing 500mA then. :-P 22.00.08 # the worst thing i've seen (besides on acer motherboards that indeed blow up sometimes when you plug an innocent pendrive) is non-resetting fuses :-D 22.06.49 Quit freddyb (Remote closed the connection) 22.08.25 # it looks like sdram now works on the meizu m3 too 22.09.27 # TheSeven: Oh sure, it has to be *really broken* hardware, to the point that it's not really in any way the devices' fault 22.09.31 # but people still blame the devices :) 22.09.39 # whatever was connected at the time is *obviously* the cause! 22.09.58 # i guess we can offer them a refund :) 22.10.47 # * gevaerts thinks that those refund jokes could backfire 22.11.03 # What will you do if someone actually paid for rockbox? 22.11.23 # THey didn't pay *us*, presumably 22.13.50 # well, no 22.14.04 # But what if they did? 22.14.28 # Maybe someone is nutty enough to appreciate your efforts and in a fit of madness, MADNESS, gave $5? 22.14.38 # that's a donation 22.14.40 # that's not paying for it, that's a donation 22.15.18 # What do you want? Them to "donate" and then say in the comment section, "Software please."? 22.15.22 # :P 22.16.15 # the point is that someone can sell rockbox to people, and if they then ask for support here and someone (jokingly) proposes to refund what this person paid, it will be awkward 22.16.30 Quit Grahack ("Leaving.") 22.16.40 # I know. 22.16.42 # Though... it would be cool if, as a fund-raising endeavor the Rockbox group sold pre-modded players. 22.17.08 # fascinating legal issues there! 22.17.13 # we don't really need money I think 22.17.16 # Then at least people wouldn't need to hunt on eBay and such, just find them centrally and make the group a few dinero. 22.17.16 # Nz17: which may imply warranties etc. 22.17.34 # Ther eare hilarious legal issues with that one 22.17.45 # Steering clear is best :) 22.17.53 # Nah, just say, "Hey this is aftermarket, no warranty, as-is, but we will do our part to help out if reasonable." 22.18.06 # there are issues other than warranty/etc. 22.18.08 # Nz17: this is not possible in several countries 22.18.16 # or at least, *potentially* 22.18.19 # you'd probably have to pay taxes too 22.18.26 # and we don't ahve the wherewithal to prove whether there are or not ;) 22.18.27 # Those countries can go back to the medieval ages. 22.18.34 # You can say that, but it doesn't override consumer laws 22.18.59 # Then there is no choice. 22.19.14 # "High enough" donations get various levels of "gift" players. 22.19.21 # Problem solved. 22.19.27 # An advantage of open software is not having to sell stuff 22.19.33 # ;) 22.19.36 # in Germany at least, and I think this is actually EU law, you *always* have to provide at least 1 year of warranty on *used* goods and 2 years on *new* ones... 22.20.23 # Can your warranty be to guarantee that it might fail? 22.21.22 # if anything, we could offer some kind of rockboxing service for devices that users send in, but this is still pretty risky from several legal aspects 22.21.29 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 22.21.57 # Yeah, but that loses the appeal. 22.22.05 # You'd still need to find compatible players. 22.22.39 # this could be solved easier, trust me. 22.22.48 Quit DerPapst ("Leaving.") 22.22.49 # by just supporting players that are still being sold 22.23.02 # heh 22.23.08 # well people are *trying* 22.23.19 # sansa aren't making it easy ;) 22.23.27 # nobody is making it easy 22.23.33 # Nz17: so why would we want to make it easier for other people to get players with rockbox? 22.23.35 # iirc the ipod video was the last target that got a usable port while still being sold new 22.24.08 # The D2's dead easy to hack and are still made, but no other devs seem interested :/ 22.24.16 # gevaerts: I suppose because FREEDOM FEELS GOOD. ;) 22.24.19 Quit phanboy4 ("Leaving") 22.24.33 # Nz17: but we are already free! 22.24.41 # \o/ 22.24.42 # * TheSeven thinks the first device that will both be sold and supported for a long time simultaneously, if it will ever work, is the lyre. 22.25.02 # Let us free the other proletariats! 22.25.29 # Nz17: my point is that if you want to do this sort of thing, go ahead, but it's not something the rockbox project is interested in 22.25.50 # * bertrik agrees with gevaerts 22.25.53 # That's not 100% true. 22.26.01 # If so, the code wouldn't be public. 22.26.11 # The group wants people to use the software. 22.26.16 # why? 22.26.31 # Why what? 22.26.57 # If people want to use it, they're free to do so, but why would we necessarily want *more* users? 22.27.10 # Would you want less? 22.27.20 # Nz17: sometimes yes 22.27.21 # we want more robots! 22.27.24 # at least for the player :-P 22.27.38 # * TheSeven would like to abolish charcell lcds :-P 22.27.39 # Nz17: Users often clutter up the nice tidy lists/forums with useless stuff :) 22.27.58 # But who would be so bold? ;) 22.28.01 # Nz17: Open source projects often *really do not care* if they have more users 22.28.11 # Users beget developers, developers beget code. 22.28.14 # i work on rockbox because it makes *my mp3 player* awesome 22.28.27 # and then a bit more because it's kinda fun 22.28.39 # And code begets new features. 22.28.55 # Users generally *don't* become developers, though 22.29.12 Quit HellDragon (Client Quit) 22.29.13 # and even if they do, the chance of them working on anything I'm that bothered about is not huge ;) 22.29.20 # * Torne is being cynical somewhat, but you see the point :) 22.29.23 # Torne: developers don't become code either :-D 22.29.29 # Yeah, i hope not 22.29.44 # Become? I wrote, "beget." 22.30.02 # In which case I hope users don't go around begetting developers too much :) 22.30.02 # But aren't most developers users first? 22.30.16 # * B4gder was a developer first 22.30.27 # Nz17: not necessarily 22.30.28 # * gevaerts was a user for more than a month 22.30.35 # Nz17: i got my ipodvideo to run rockbox 22.30.36 # Users beget support questions... so many questions... 22.30.40 # i started building rockbox a couple of days later 22.30.50 # I knew when I bought it that I was very likely to want to make at least minor changes 22.31.19 # And then this happened! 22.31.20 # and iknew that i would probably be able to 22.31.26 # so, i pretty much planned on *doing some development* for it. 22.31.40 # New commit by 03bertrik (r23614): Meizu M3: configure and use SDRAM 22.31.42 # i didn't actually plan on becoming a committer but they're nice guys and gevaerts bullied me 22.31.50 # ;) 22.31.58 # Plus the benefits. 22.32.18 # benefits? :) 22.32.24 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 22.32.36 # Yeah, you know, like... such as... something kind... um, groupies? 22.33.02 # he already mentioined gevaerts :-P 22.33.11 # * B4gder ducks 22.33.12 # :O 22.33.21 # * gevaerts throws eggs at B4gder 22.33.24 Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 22.33.51 # Nz17: well it means i can gradually reduce the number of patches i need to apply to build for my ipod, by finishing and committing them ;) 22.34.01 # that is a benefit, tbh :) 22.34.06 # the stack was getting unmanageable 22.34.26 # Not to mention the buffer. *rimshot* 22.34.41 Join LambdaCalculus37 [0] (n=LambdaCa@rockbox/staff/LambdaCalculus37) 22.38.44 # Now this is ridiculous. I tried to get ROLO working again on the D2 to do some testing, of course this needed a build with IRAM enabled - that's easy since IRAM is only disabled ATM for speed reasons. But I'm getting some pretty weird side effects. 22.39.04 # Like the UI will freeze after the backlight's faded out due to inactivity. Music plays on, but I can't wake the UI. WTF?! 22.41.01 # OK guys, thanks for the advice and good conversation. Happy coding! 22.41.14 Part Nz17 ("to buy a player.") 22.42.57 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 22.44.00 Join phanboy4 [0] (n=benji@gate-20.spsu.edu) 22.45.31 # As for ROLO, it still won't work due to some stupidity: the rolo_restart() is in IRAM, but it calls invalidate_idcache() which isn't (and has since been overwritten with the new ROLO'd image). D'oh... 22.46.01 # hehe 22.46.04 # shouldn't those ARM cache functions be in .icode? 22.47.23 # sounds reasonable, as this is probably breaking rolo in even more places 22.47.43 # it's probably the bug I'm observing on nn2g right now that rolo sometimes locks up (as soon as that function moved?) 22.49.23 # sounds like it. presumably just changing those ".section .text" lines in mmu-arm.S to .icode should do it... if .icode even exists on all ARM :/ 22.50.07 # * kugel wonders why other ARMs don't have that problem 22.51.09 # kugel: because they forgot to flush the cache? :-P 22.51.12 # I guess rolo is probably not used that much so any problems are not reported 22.51.37 # TheSeven: that's generic arm code in rolo.c as far as I know 22.51.53 # bertrik: it's probably used by developers that always rolo very similar builds and then grumble from time to time if it fails 1 out of 10 times 22.52.37 # yeah, if the functions are "early" in the binary there's a good chance the addresses will match 22.52.45 # shotofadds: .icode should exist on every arm target. if it doesn't, it should be added to the linker script in the .text output section 22.52.52 # I assume it's used rather often (on targets that have usb), it kicks in if you update rockbox with rockbox usb 22.53.14 # let me check where that function is for me 22.53.25 # I don't think the Gigabeat F/X use IRAM do they? 22.53.35 # hardly 22.53.50 # ooh look, ROLO works now ;-) 22.54.15 # Bob_C_: but .icode is still defined, I did check that one at least 22.54.16 Quit kugel (Nick collision from services.) 22.54.24 Join kugel [0] (n=kugel@e178089093.adsl.alicedsl.de) 22.54.49 # Bob_C_: they do use it for rolo 22.54.49 # for this exact reason (code can't overwrite itself) 22.54.49 # the iram on those chips is small though, 4kB iirc 22.54.52 # 0x08063a08 invalidate_idcache 22.54.54 # aha 22.54.57 # broken for me, too 22.55.22 # * shotofadds wonders how many reds this might get 22.55.37 # I tried ROLO a couple of times without success, but that was on some dodgy builds 22.55.48 Join kugel_ [0] (n=kugel@e178090169.adsl.alicedsl.de) 22.55.54 Quit kugel (Nick collision from services.) 22.56.06 # and it's pretty much at the end of the image, so it should fail rather often 22.56.47 Join kugel__ [0] (n=kugel@e178091068.adsl.alicedsl.de) 22.56.50 Nick kugel__ is now known as kugel (n=kugel@e178091068.adsl.alicedsl.de) 22.56.53 Quit kugel (Read error: 104 (Connection reset by peer)) 22.57.13 # presumably I just need to change invalidate_idcache and invalidate_dcache, as those are the only ones called from ROLO. Any benefit in moving the others? 22.57.35 Quit adiroiban (Read error: 60 (Operation timed out)) 22.57.56 Join kugel [0] (n=kugel@rockbox/developer/kugel) 22.58.28 Quit kugel_ (Read error: 60 (Operation timed out)) 22.58.36 Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) 22.59.11 Join JdGordon|| [0] (n=Miranda@nat/microsoft/x-vudzhukktxaksaum) 22.59.34 # shotofadds: for consistency at best, but you'll need to watch for the gigabeat iram size 23.00.01 # * shotofadds does a couple of test builds 23.00.04 Join kugel_ [0] (n=kugel@e178092224.adsl.alicedsl.de) 23.00.08 Quit kugel (Nick collision from services.) 23.00.12 Nick kugel_ is now known as kugel (n=kugel@e178092224.adsl.alicedsl.de) 23.00.24 # the question why it works on other targets is still open (?) 23.00.30 # maybe we should have a section that is protected against rolo and move it there instead of relying on magic/iram 23.00.59 # I don't think relying on IRAM is magic 23.01.24 # kugel: it's definitely broken for me in a way that should fail almost always (judging from it's address) but it still works 90% of the times 23.01.38 # it is since many targets can remap it whereever they want 23.02.02 # but why's that a problem? 23.02.24 # kugel: the point is that iram is not overwritten untill rockbox starts 23.03.11 # anyway, some targets might not even have iram/or too little 23.03.34 # kugel: then these have either some extra precautions or rolo just doesn't work for them 23.03.44 # at least for the targets that don't have any iram 23.03.53 Quit JdGordon| (Read error: 60 (Operation timed out)) 23.04.11 # this won't make any difference on F/X anyway since their .icode is inside .text 23.04.16 # so it's luck that it works on all other targets for years? 23.04.43 # kugel: seems so 23.04.50 # kugel: this error is in mmu-arm.S so only relevant to ARMv4/v% 23.04.54 # v5 23.05.18 Quit Lynx_ (Read error: 54 (Connection reset by peer)) 23.05.21 # that basically only excludes PP 23.05.38 # shotofadds: the v6 one was split off only very recently and probably has the same issues (if it isn't even using mmu-arm.S for the common things) 23.06.08 Join Lynx_ [0] (n=Lynx@xdsl-78-34-101-117.netcologne.de) 23.06.39 # shotofadds: these days we have almost more targets that actually have a caches than those that dont't I believe 23.07.30 # yes, but this is a sane fix regardless 23.08.09 # go for it, I'm just curious that it never caused problems 23.08.22 # which targets are ARMv6? just Gigabeat S? 23.09.11 # hmm. it won't make any difference there either since IRAM isn't enabled on the S either. 23.09.28 # ROLO has no hope on the Gigabeats at the moment, by the looks of it 23.10.01 # * shotofadds wonders whether kugel's "safe area" might be a better bet ;) 23.10.02 # shotofadds: they could just use some fake iram at the end of dram for rolo's purposes 23.10.02 # a separate section makes it work on all targets 23.10.09 # 23.10.41 # bah, that's a lot of .lds's to edit :/ 23.11.29 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 23.12.29 Quit killan_ (Read error: 104 (Connection reset by peer)) 23.13.27 *** Saving seen data "./dancer.seen" 23.15.54 # couldn't it be fixed by just invalidating caches before loading the "huge" binary? 23.17.07 Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 23.17.33 Nick JdGordon|| is now known as Jdgordon| (n=Miranda@nat/microsoft/x-vudzhukktxaksaum) 23.17.37 Nick Jdgordon| is now known as JdGordon| (n=Miranda@nat/microsoft/x-vudzhukktxaksaum) 23.17.45 # kugel: no, there's a final copy stage after loading the binary (from audiobuf to DRAM start addr) 23.17.51 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 23.18.25 # invalidating before that final copy? 23.19.10 # or even turning the caches off entirely 23.20.06 # * kugel doesn't think it's a good idea to call functions after they're overwritten generally ;) 23.21.35 # having cache functions available at all times is generally a Good Thing, no? 23.22.17 # turning off dcache also means no MMU? 23.22.26 # all Good Things have an exception. Are the caches critical for rolo to work? 23.22.44 Quit jgarvey ("Leaving") 23.23.57 # Bob_C_: AFAIK, no 23.24.23 # oh, afaik it does :) 23.24.42 # perhaps depends on arch 23.27.24 Quit Strife89 ("Going home.") 23.27.29 # Bob_C_: mmu, dcache and icache all have separate enable/disable registers 23.27.46 Quit evilnick_B ("Page closed") 23.30.00 # ok, in that case it should be ok 23.34.24 Join shot0fadds [0] (n=rob@79-70-113-53.dynamic.dsl.as9105.com) 23.34.56 Quit phanboy4 (Read error: 104 (Connection reset by peer)) 23.35.17 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.35.17 Quit n1s ("Lämnar") 23.36.24 # can I convince anyone to work on wpsbuild.pl please?? 23.38.34 Nick Ypsy is now known as YPSY (n=ypsy@geekpadawan.de) 23.39.33 # * shot0fadds doesn't think adding a .safe section to ALL targets is a very clever idea. take a look at imx31/rolo_restart.S for a rather easier solution... 23.40.45 # * shot0fadds goes for a cuppa 23.42.33 # JdGordon|: I thought I made it work with sbs? 23.43.20 # I need it fixed so it can handle a single .sbs for all targets unless there is one for -rechwcodec and -recswcodec or something similar 23.44.02 # why exclude those? 23.44.13 # they would be from a different file 23.44.13 # I thought you added a number of redundant tags to make that workj 23.45.37 # no? 23.45.51 # what where those recording tags for then? 23.45.57 # it could be done using feature tags, but only if one is added for swcodec and hwcodec 23.46.05 # they have different tokens 23.46.43 # and anyway... it was ONE "redundant" tag... 23.46.44 # which tags exactly? 23.48.31 Quit shotofadds (Read error: 110 (Connection timed out)) 23.49.25 Quit bertrik ("De groeten") 23.49.26 # which are you talking about? 23.49.30 # * JdGordon| is a bit confused 23.50.06 # New commit by 03mc2739 (r23615): Add Diego Herranz to docs/CREDITS for r23613 / FS#10773 23.51.42 # JdGordon|: which ones are incompatible? 23.52.12 # off the top of my head I couldnt tell you... 23.52.36 # I tihnk actually only one of the tags makes sense in both 23.53.02 # and, unlike rtc, swcodec and hwcodec are mutually exclusive so there is no need to compile in the tags for both of them 23.53.51 Quit kugel (Remote closed the connection) 23.55.22 Quit domonoky1 (Read error: 104 (Connection reset by peer))