--- Log for 10.10.110 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 23 hours ago 00.07.06 # * kugel makes a complete run 00.09.02 Join wop [0] (~swagga@dsl-216-221-39-132.aei.ca) 00.09.43 # hi,can i access my files from usb using rockbox?because i cant a way to do it 00.11.22 # wop: What do you mean exactly? Access files from where? 00.12.04 # on the computer 00.12.19 # With which player? 00.12.25 # ipod video 00.12.48 # that should work fine 00.13.11 # i dont see it on the computer and i cant even get into apple mode 00.13.48 # do i have to enable usb or someting so i can explore the files? 00.14.03 # What operating system are you using? 00.14.42 # windows xp 00.15.07 # Is anything shown on the ipod screen when you plug it in? 00.15.22 # yeah it turns on in rockbox mode 00.15.31 # its charging 00.15.46 # but i cant see the device 00.16.34 # gevaerts: c5000 seems to be about 40% realtime 00.16.47 # kugel: ah, good. The beast still wins :) 00.16.49 # this is without asm optimizations 00.17.01 # wop: so you're plugging it in while it's switched off? 00.17.05 # the beast is probably faster than my phone 00.17.46 # yes gevaerts 00.17.54 # gevaerts: are there complete results for the beast? 00.20.14 # wop: ok. What happens if you turn the ipod on first, wait until rockbox has started, and then plug it in? 00.21.26 # same thing 00.22.39 # wop: what happens if you turn the ipod off, switch hold *on*, and then plug in? 00.23.33 # * kugel isn't sure about 40% rt 00.23.39 # i looked in universal serial bus controller and i have this when i plug it in !generic usb hub 00.23.47 # it sounded like, but in the actual benchmark it seems slower 00.23.54 # we'll know in a few minutes :) 00.24.43 # when i put on hold it just restarts over and over 00.25.04 # apple logo 00.25.27 # the ipod video doesn't have usb in 3.6, does it? 00.25.38 # huh?> 00.26.15 # howcould i messed it up i used the auto installer from the website 00.26.19 # kugel: hm, yes, but I don't think that explains this on its own 00.26.35 # ha, 40.17%! 00.26.43 # what an accurate guess 00.27.09 # It should detect USB and then reboot to the Apple in-rom disk mode, which apparently doesn't happen here 00.27.36 # And booting with hold enabled should just boot the Apple firmware 00.27.55 # yes thats why im here im confused 00.28.03 # i used auto installer 00.28.09 # and its all messed up 00.28.17 # what bootloader does that install? 00.28.46 Quit bertrik (Ping timeout: 240 seconds) 00.29.05 # rockbox utility v1.2.8 00.29.09 Join stoffel [0] (~quassel@p57B4CEEA.dip.t-dialin.net) 00.29.11 # kugel: doesn't really matter. Unlike about all other targets, the ipod bootloader doesn't care about whether or not the main build can do USB 00.29.11 # IIRC the latest released PP bootloaders think USB is enabled, but I'm not sure if that's true for all PP bootloaders 00.29.34 # oh, and the ipods don't use the PP bootloaders right? ignore me :) 00.34.25 # wop: I don't really have a clue about what's wrong here 00.34.37 # Maybe someone else will know 00.35.32 # when i plug it it say found new hardware but it doenst work something is messsed up 00.36.20 Quit Topy44 (Read error: No route to host) 00.36.33 # wop: Can you try putting it into Emergency Disk Mode, as described in http://support.apple.com/kb/HT1363 ? 00.39.36 Join Topy44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 00.40.17 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) 00.44.48 Quit _s1gma (Quit: Leaving) 00.47.16 # it just restarts 00.48.48 Quit ender` (Quit: The Web is a procrastination apparatus: It can absorb as much time as is required to ensure that you won't get any real work done.) 00.49.17 # Have you tried several times? That part is fully handled in hardware and by the Apple code, rockbox isn't involved at all there 00.49.32 # So if that doesn't work, there's likely something wrong with your ipod 00.51.32 # all codecs except mp3 seem to crash with asm enabled 00.52.50 # I suspect it's a similar problem that the tremor guys have with our mdct 00.53.37 # (the asm uses register in the asm even though it's used for a different purpose) 00.54.57 # hm no it works now after make veryclean 00.55.29 # S_a_i_n_t: ping 01.03.55 *** Saving seen data "./dancer.seen" 01.04.37 # wma, vorbis, aac, a52, cook do not work 01.06.02 # kugel: asm enabled on android? 01.06.07 # yes 01.06.21 # Neat 01.08.36 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 01.10.06 Join Evilnick_ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) 01.11.17 # rasher: not if half of the codecs crash with it 01.12.46 Quit BHSPitMonkey (Quit: Ex-Chat) 01.12.57 # kugel: more exciting things to work on! 01.13.28 # JdGordon: does my (partial) fix of FS#11589 make sense? 01.13.44 Quit evilnick (Ping timeout: 276 seconds) 01.15.13 # possibly, but I think there is more to it than that 01.17.49 # flac, mpc almost twice as fast (flac 5500% realtime!), lame a little slower(!), applelossless a bit faster 01.18.31 # JdGordon: I know my h120 freezes after disconnecting early USB without that, and it works fine with it 01.18.57 # ok 01.19.00 # ape c3000 about 1.8x faster 01.21.10 # wavpack ~20% faster 01.23.02 # I'm curious as to why mp3 is slower 01.24.46 # did someone try to reproduce FS#11642 ? 01.26.27 # JdGordon: i have put apks up 01.26.40 # cool 01.41.01 # can someone who has a clip+ try to reproduce FS#11642 ? It doesn't crash for me, it's too vague 01.46.56 # pamaury: that could well be caused by a file with bad metadata 01.48.02 # bad metadata shouldnt be able to break anyhing :/ 01.48.31 Quit hebz0rl (Quit: Leaving) 01.48.36 # Shouldn't, no 01.49.17 # bad metadata CAN crash rockbox, I experienced it not so long ago 01.49.43 # And it's true that crashes while building the database are less common than they used to be, but I wouldn't expect them to be totally gone 01.49.45 # yes it could but I'll better ask :) 01.50.36 # true, the code is so complicated, I wish the bug is not database related :D 01.51.44 # * JdGordon has too many files on his clip+ now and cant build the db at all 01.52.55 Quit kugel (Remote host closed the connection) 01.53.36 # JdGordon: can you test a usb patch on your clip+ ? 01.53.52 # yeah 01.54.18 # Did you ever enable rockbox usb on it ? 01.54.32 # i dont tihnk so 01.54.47 # do you know how to do it ? 01.55.05 # nup.. 01.55.09 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 01.56.01 Join kugel [0] (~kugel@g231104191.adsl.alicedsl.de) 01.56.03 Quit kugel (Changing host) 01.56.03 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.56.09 Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 01.56.18 Quit stoffel (Ping timeout: 272 seconds) 01.57.12 # ok so have a look at this patch: http://pastebin.com/vH9KgdNR. In a first time you just apply the first hunk (about USB_HANDLED_BY_OF and USE_ROCKBOX_USB ). This enables USB. Then try to plug/unplug it several times (say 10 or 20) and count the number of times it fails (typically it doesn't mount). Then apply the whole patch and repeat the produce. Ideally, it should go from 1 or 2 failure before to 0 after 01.58.32 # fun :p 01.58.35 # ok, hang on 02.00.18 # * JdGordon needs a faster compile box! 02.00.33 # just recompile the core, it's super fasteer 02.00.55 # 4 cores :) a full zip takes about a minute :D 02.02.02 # ok, so just boot rockbox and connect usb and see how many reconnects it takes to work? 02.02.32 Quit Rob2223 (Quit: Rob2223) 02.03.15 # hehe it connected first go 02.03.48 # JdGordon: from what I understand it works most of the time 02.04.02 # 2/3 so far 02.04.29 # yeah it works most of time but sometimes, it just doesn't do anything, the kernel keep resetting the device and then give up. 02.04.48 # JdGordon: do you copy a full zip just for a firmware update ? 02.05.05 # full zip that time because i hadnt updated in ages 02.05.09 # ok 02.05.54 # it only failed to connect once without the full patch... do i bother with the pacth? 02.05.59 Join Rob2222 [0] (~Miranda@p4FDC9F2E.dip.t-dialin.net) 02.06.38 # yes 02.06.55 # the goal of the patch is zero failures 02.08.15 Quit mikroflops (Ping timeout: 255 seconds) 02.10.13 # dmesg shows one reset but it has connected every time 02.10.43 # that's to be expected, but that's a good point if it connected every time :) 02.10.44 # another reset+connect 02.11.10 # the patch does a hard reset after too many failures :) (Or try to do so) 02.11.32 # (a hacky solution to a nasty problem I would say) 02.13.18 # if you see funman, can you ask him to test the patch ? It seems we have disjoint schedules even though we live in the same timezone :P 02.14.37 Part wop 02.14.58 # k 02.18.11 Quit pamaury (Remote host closed the connection) 02.18.57 Quit kugel (Ping timeout: 245 seconds) 02.19.29 Join kugel [0] (~kugel@g231104191.adsl.alicedsl.de) 02.19.31 Quit kugel (Changing host) 02.19.31 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.21.17 Quit basti (Quit: A-well-a bird, bird, bird, the bird is the word!) 02.23.00 Join mikroflops [0] (~yogurt@h-34-59.A238.priv.bahnhof.se) 02.25.50 Quit ps-auxw (Ping timeout: 240 seconds) 02.34.25 Quit GeekShadow (Quit: The cake is a lie !) 02.34.28 Quit DerPapst (Quit: Leaving.) 02.37.32 Join ps-auxw [0] (~arneb@p4FF7F392.dip.t-dialin.net) 02.42.36 Join hcs [0] (~agashlin@rockbox/contributor/hcs) 03.03.58 *** Saving seen data "./dancer.seen" 03.06.34 Join Chronon [0] (~Chronon@c-67-171-217-43.hsd1.or.comcast.net) 03.10.22 # TheSeven: Errr...sorry about leaving you hanging there. Had a lazy morning. 03.10.32 # * S_a_i_n_t calls "pong" from the rooftops. 03.11.22 # S_a_i_n_t: can you try FS#11663 03.12.17 # Sure, I'll let you know once I've had a fiddle with it. 03.12.27 # Clickwheel/button stuff I imagine? 03.12.32 # exactly. 03.12.47 # Coolies, yep. I can do that. 03.13.17 Join daurnimator_ [0] (76d1fb10@freenode/staff/daurnimator) 03.13.37 # anyone know of anything that lets you play additional audio formats on an ipod touch? 03.13.58 # Not that would be in any way relevant here... 03.14.23 # RaaA for the iPod touch, once someone ports it :) 03.16.49 Join [AndrewR] [0] (~andrewrot@d24-36-251-35.home1.cgocable.net) 03.17.00 # <[AndrewR]> hello 03.17.33 # btw, where can I grab a copy of raaa? 03.17.50 # raaa = rockbox as an application 03.18.01 # which has so far only been ported to android 03.18.17 # <[AndrewR]> I'd like to draw some stuff using drawline, drawrect, etc. to a secondary buffer, then blit a subset of it to screen. anyone know the best way to do that? 03.18.22 # http://www.rockbox.org/wiki/AndroidPort 03.18.30 # <[AndrewR]> this is for a plugin 03.18.58 # <[AndrewR]> can I use a viewport? 03.22.17 Quit kugel (Ping timeout: 245 seconds) 03.26.48 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 03.44.21 Join drizztbsd_ [0] (~quassel@unaffiliated/drizztbsd) 03.45.22 Quit drizztbsd (Ping timeout: 250 seconds) 03.57.20 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 04.00.16 Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) 04.03.22 # S_a_i_n_t: I'll go to sleep now... If you find any issues with my patch, please leave me a note on flyspray 04.08.23 Join Jasons [0] (~jasons@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 04.09.07 Quit Jasons (Client Quit) 04.09.33 Quit pixelma (Disconnected by services) 04.09.34 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.09.49 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.09.54 Quit amiconn (Disconnected by services) 04.09.54 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.10.14 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.11.44 Join captainkewllllll [0] (~jasons@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 04.12.04 Quit captainkewllllll (Client Quit) 04.12.05 Quit TheSeven (Ping timeout: 240 seconds) 04.12.16 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 04.18.12 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.23.37 Join panni__ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 04.26.43 Quit panni_ (Ping timeout: 276 seconds) 04.32.53 # * JdGordon curses at people who put the %xl() lines at the top of the skin with a x,y offset and then %xd inside a viewport 04.35.27 Quit Rob2222 (Quit: Rob2222) 04.35.46 Join Rob2222 [0] (~Miranda@p4FDC9F2E.dip.t-dialin.net) 04.45.36 Quit [AndrewR] (Quit: [BX] Save water -- drink beer!) 04.52.02 Join xavieran [0] (~xavieran@ppp118-209-131-252.lns20.mel6.internode.on.net) 04.52.53 Join Barahir_ [0] (~jonathan@frnk-590f7730.pool.mediaWays.net) 04.53.25 Join dys` [0] (~andreas@krlh-5f72c75b.pool.mediaWays.net) 04.53.31 Quit dys (Ping timeout: 276 seconds) 04.54.01 Nick dys` is now known as dys (~andreas@krlh-5f72c75b.pool.mediaWays.net) 04.56.15 Quit Barahir (Ping timeout: 265 seconds) 04.56.48 # JdGordon: Pastie an example? 04.57.00 # I think I know what you're on about, and I dislike that too. 04.57.29 # as far as I'm concerned...%xl should almost always have a 0,0 offset 04.57.50 # left the viewport it should be in dictate the positioning. 04.57.57 # s/left/let/ 04.59.28 # 320x480 cabbie 04.59.37 # unless im reading it wrong 04.59.55 # whew...it wasn't me, so...I don;t care ;) 05.00.35 # I need to re-dl the source, my dev environment got wiped out...really should get back to that. 05.00.55 # it has an annoying alignment problem, the next track line overlaps the progresbar, which ends up cutting off lettes like jgp 05.01.54 # but yeah, unless I'm completely misunderstanding things, %xl(blah) should pretty much always be at 0,0 in the %xl declaration, and the viewport should dictate the placement. 05.02.05 # anything else seems sloppy, and fucking hard to work out. 05.04.02 *** Saving seen data "./dancer.seen" 05.04.12 # ....weird, we're agreeing on skin related stuff. 05.04.31 # * S_a_i_n_t looks for the black clouds, and listens for the sound of ice crystals forming in hell. 05.04.37 # ;) 05.11.38 # sorry 05.12.03 # actually what I was going to say was "/me contemplates forcing xl lines into the viewport its xd()'d in"! 05.31.50 Quit anewuser () 05.33.54 Quit ps-auxw (Ping timeout: 252 seconds) 05.42.53 Quit fdinel (Read error: Connection reset by peer) 05.44.49 # Nah, that sucks...I like having all %xl's up the very top of the skin personally. 05.45.13 Join ps-auxw [0] (~arneb@p4FF7F15F.dip.t-dialin.net) 05.45.51 # Unfortunately, there's just no way to force people to skin sanely. 05.46.20 # says the one who insists Xd(Af) is good :) 05.49.00 # http://imagebin.ca/view/DyxLdQDF.html top left corner is the MENU button, top right is context menu, the bottom playlist area I want to use for navigation buttons 05.49.41 # I'm not sure what to tihnk about the title and list fonts being wierdly backwards sized 05.49.55 # i.e the title font should be bigger.. but thats the bar size in the wps 05.58.14 Quit spike_ (Quit: leaving) 06.01.14 # putting the AA at 0,0 sized 32,32 in the sbs looks shite :p 06.10.29 Join Jeshikah [0] (~ad466bcf@giant.haxx.se) 06.11.19 Quit edboyer93 () 06.11.38 # there is no touchscreen button to jump to the wps?! 06.12.25 # hi there. is there anyone on that's familiar w/ the fuze? 06.13.12 # just ask your question. if someone can answer it, they will 06.14.17 # i installed rockbox today on my fuze v1 using the full install option in the rockbox utility 06.14.38 # then i disconnected and firmware updated. so far so good. 06.15.15 # then when i try to reconnect it w/ comp now, it just keeps resarting, but comp won't recognize it 06.15.36 # it wount accept a wall charger either, doing the same thing 06.16.15 # can you boot into the OF and connect that way? 06.16.45 # not sure how to do that 06.17.36 # New commit by 03jdgordon (r28223): Add "resumeplayback" touchscreen button action which returns you to the previous music screen (WPS or FM) from most of the lists (browsers and menus) 06.18.12 # * S_a_i_n_t points Jeshikah to the manual 06.18.19 # http://download.rockbox.org/daily/manual/rockbox-sansafuzev2/rockbox-build.html 06.18.27 # http://download.rockbox.org/daily/manual/rockbox-sansafuzev2/rockbox-build.html 06.18.48 # Hmmm....fuze v1 and 2 are the same manual? 06.18.49 # odd. 06.19.28 # r28223 build result: All green 06.19.39 # they should be 06.19.50 # ...all firmwares are .sansa files aren't they? 06.19.57 # I thought there was some fundamental differences. 06.20.04 # Are there not two seperate builds? 06.20.20 # no user differences 06.20.25 # so no need for more than one manual 06.20.45 # I assume then, there's no way to (yet) have one build that runs for both models. 06.20.58 # or, it probably would make binsize way too big. 06.20.59 # any ideas how to add two buttons to the top of the sbs I linked above to make the menu buttons obvious without breaking the look? 06.21.25 # binsize isnt an issue really when the target has >8MB ram 06.21.40 # * S_a_i_n_t has a nosey... 06.21.53 # Ah, so...noones figured it out yet? 06.21.55 # cuz i think i have only the rockbox firmware on the player :| 06.22.01 # (re: fuse) 06.22.11 # I doubt anyone has looked into it 06.22.22 # Seems like a sensible thing to do, IMO 06.22.28 # it isnt like the ipod 5g build... actual drivers are different 06.22.59 # Yeah, I understand that...but, it would be nice to have one build for both...if possible 06.23.12 # Jeshikah, no, you have both. nearly all of the devices dual-boot by default 06.23.35 # Jeshikah: the manual I linked explains boot procedure for both RB and the OF 06.23.58 # the manual should be the first port of call for "Hmmm, wtf?" questions 06.24.00 # so which folder would it be in? i can only find the rockbox.sansa, but no other .sansa 06.24.21 # * JdGordon is slightly annoyed the app builds only allocate 8MB ram.. the playlist viewer sucks if only the next tracks info is loaded 06.24.50 # you just have to hold the correct button during boot, as the manual says 06.25.16 # there's no need to be confusing yourself looking for folders. 06.26.05 # hold left to boot OF 06.27.20 # JdGordon: Re: your .sbs question...short answer is "No" 06.27.26 # the look will change completely 06.27.34 # And yes, the backward fonts look like ass. 06.27.41 # yeah... 06.27.54 # do we have the font which was origionally used to make the wps banner? 06.28.02 # Nope. 06.28.05 # thanx. i was looking under "advanced topics" in the manual and it clearly mentions "playing .sansa files" and said nothing about left button, strangely, lol 06.28.26 # JdGordon: The closest is one of the Helveticas 06.28.52 # But it will always look different, as the original banner was aliased 06.28.59 # I'm using 18-Adobe-Helvetica-Bold.fnt for the title and 12-Adobe-Helvetica-Bold.fnt for the list 06.29.19 # Make the banner larger, and swap them around. 06.29.22 # solved ;) 06.29.37 # yay, now it works like a charm, lol. tyvm everyone ^^ 06.30.05 # oh no I'm not :) 18-bold for the title, 12-bold for the playlist viewer title.. 27-adobe-helvetica for the lists 06.30.10 # Jeshikah: No offence, but, as I said..reading the manual is something everyone that even looks at rockbox should do 06.30.24 # it's not really something you can just blunder your way through 06.30.56 # lol, none taken, and i was looking at the manual, just appearantly the wrong section 06.31.35 # JdGordon: Seriously? 06.31.51 # yeah 06.31.51 # list bigger than the header seems...yuck, to me..personally. 06.31.59 # http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch12.html#x15-31600012 i was looking at section 12.5 on there. which seems to be the wrong section to look at, lol 06.32.08 # also: Add an actual header! 06.32.15 # the path looks like ASSS! 06.32.28 # It does feel odd, but thats what I chose because it fit the banner image :) and because of the colour differens I dont tihnk it looks terrible 06.33.01 # I *could* make you a larger banner background... 06.33.14 # I wanted it to stay the ame as the wps 06.33.26 # and, make an actual "Playlist" header!!!! 06.33.42 # for down the bottom? 06.33.49 # up the top. 06.34.00 # the screenshot was from the file browser 06.34.01 # "/blah/blah/playlist.blah/" looks like ass to me. 06.34.15 # errr... "/media/data/music" 06.34.18 # rather 06.34.40 # * S_a_i_n_t has never been a fan of the full path in the title though personally. 06.35.34 # with that setting off the bar is empty which is a bit lame... 06.35.51 # I wasn't sure what I was looking at initially, so "Playlist" doesn't really make any sense there. 06.36.04 # does %cs not have a "database" thing? 06.36.13 # I'm not sure what I do in that case. 06.36.14 # I'm checking 06.36.41 # "Screens from 1-5, in that order: Menus, WPS, Recording screen, FM Radio screen, Current Playlist screen" 06.36.44 # If not, it should...as if I don;t use it that's probably why ;) 06.37.14 # thats been on my todo list for a while also :p 06.37.21 # more fine grained %cs control 06.37.34 # I guess it could be 1-6 with database added to the end without breakig anything. 06.37.52 # *breaking, even. 06.37.53 # it doesnt even have "browser" 06.38.31 # what happened with your bigger iconset? 06.38.39 # yeah, as I don;t use the "full path" setting, I have wanted more %cs's for a while...but it's never really been something that worked too well. 06.38.54 # as for the Iconset, I fell off the internets ;) 06.39.11 # tisk tisk :) 06.39.13 # Its still floating around, I need to finish the viewer icons though. 06.39.42 # after that, done. the 12x12 iconset looks plain odd on that screenshot. 06.39.54 # yes it dos 06.40.16 # I want to actually commit this sbs.. even if only to get other people interested in making it better 06.40.36 # It definitely looks good. 06.40.42 Quit Nausicaa (Ping timeout: 240 seconds) 06.40.53 # As good as a cabbie can look ;) 06.41.01 # well yeah :) 06.41.35 # ruddy hell the line selector looks like shit! 06.42.47 # also I'm pretty sure I need to come up with a way to allow button popups above the list 06.43.18 # *cough* magic colour for transparency in the line selector *cough*! 06.43.39 # that way, it's possible to just have the font change colour for selection, which looks awesome. 06.43.52 # now, it only works with solid colour backgrounds. 06.45.08 # s/which looks awesome/which looks awesome IMO/ 06.48.06 # * JdGordon decides to start kicking people who add IMO... 06.48.12 # no shit its your opinion! 06.54.26 Join Chronon_ [0] (~Chronon@c-67-171-217-43.hsd1.or.comcast.net) 06.54.57 Quit Chronon (Ping timeout: 265 seconds) 06.55.23 # * S_a_i_n_t likes the lack of detail in FS#11662 06.56.00 # short answer: "your theme is busted somehow, try the themeeditor, if it parses, RB is busted...if not, you fucked it up" 06.56.47 # not entirely 06.57.18 # still a theme should never be able to crash rockbox :/ 06.57.19 # Hmmm, the word of the themeeditor is no longer gospel? 06.57.37 # it is slightly out of sync with svn.. 06.57.46 # * JdGordon fails at it and c++ 06.58.00 # Aha...right, geee....I'm gone for 3 weeks and everything falls to shit! ;) 06.58.36 # We need to drag beiber out of school then. 06.59.13 # well yeah :) 06.59.15 # He doesn;t need any of that anyway, two weeks messing with perl is all the qualifications any budding nerd needs to get a foot in the door. 06.59.42 # you mean I wasted 5 years at uni for nothing? :'( 06.59.55 # Depends what you were doing ;) 07.00.19 # (and it was more than a little bit sarcastic) 07.03.43 Quit panni__ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 07.04.05 *** Saving seen data "./dancer.seen" 07.05.26 Quit Galois (Ping timeout: 240 seconds) 07.08.04 Quit S_a_i_n_t (Ping timeout: 264 seconds) 07.23.40 # New commit by 03jdgordon (r28224): Touchscreen %T() tag.. don't allow - for width/height params (shouldn't affect anyway because the current code would crash if you tried it) 07.23.58 Join Horscht [0] (~Horscht@xbmc/user/horscht) 07.25.27 # r28224 build result: All green 07.26.50 Quit Horschti (Ping timeout: 272 seconds) 07.30.43 # New commit by 03jdgordon (r28225): cabbie 320x480 WIP sbs: ... 07.32.21 # r28225 build result: All green 07.39.34 Join Llorean [0] (~DarkkOne@24.219.196.161) 07.39.39 Quit Llorean (Changing host) 07.39.39 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 07.44.06 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 07.58.37 Quit Judas_PhD (Quit: This is a quitting message) 07.59.52 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 08.00.55 Quit Judas_PhD (Client Quit) 08.21.00 Join simpleMan [0] (~combroasi@202.152.170.244) 08.21.15 Quit Jeshikah (Quit: CGI:IRC 0.5.9 (2006/06/06)) 08.23.35 Quit Llorean (Quit: Leaving.) 08.28.12 # \o/ /me thinks he fixed the %t() issues 08.31.37 Quit jfc (Ping timeout: 265 seconds) 08.37.19 Quit antil33t () 08.39.07 Join Evilnick__ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) 08.39.33 Quit daurnimator_ (Ping timeout: 265 seconds) 08.40.14 # anyone got a reasonably complex skin with animatios? 08.42.22 Quit Evilnick_ (Ping timeout: 260 seconds) 08.43.33 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.235) 08.44.51 Join jfc [0] (~john@dpc6682208002.direcpc.com) 08.47.57 # New commit by 03jdgordon (r28226): fix FS#11662 and FS#11629 - skin %t() issues. %t should now work properly inside and outside of conditionals. ... 08.49.43 # r28226 build result: All green 08.50.24 Quit asderix () 08.55.54 # smart people: does http://pastebin.com/HbK6Y8Km look correct? and will that actually reduce stack usage? 08.57.16 # why not use a do {} while (0); with a continue ? 08.57.22 # oh, nvm 08.57.34 # would need to be while 1 with a break at the end... no nicer, I guess 08.57.56 # or I could just copy those few lines before the start of the loop 08.58.02 # not sure which is actually nicer though 08.58.31 Join factor [0] (~factor@74.196.97.238) 08.59.15 # looks like gcc inlined that function with that change 08.59.20 # so presumably it be good? 09.01.40 # you're asking me? I thought you wanted smart people 09.02.11 # in the absense of anyone else... :D 09.02.48 # I must be too tired because I'm not seeing the equivalence exactly 09.03.10 # actually.... I wonder if this makes the stack usage worse, seen as now all that code has inlined into another recursive function, and that change is barely going to be used (nested conditionals only) 09.03.57 # if it isn't used why would the stack be grown? 09.04.06 *** Saving seen data "./dancer.seen" 09.04.25 # it is used, in a function which is called recursivly 09.04.56 # and it always buys the max frame it needs? 09.05.44 Quit simpleMan (Ping timeout: 276 seconds) 09.12.32 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 09.13.16 # sorry to be useless here, good night 09.13.30 Part hcs 09.18.43 Quit jfc (Ping timeout: 265 seconds) 09.21.56 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 09.24.22 # pixelma: ping 09.31.07 Join n1s [0] (~n1s@nl118-174-240.student.uu.se) 09.31.07 Quit n1s (Changing host) 09.31.07 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.32.43 Join jfc [0] (~john@dpc6682208002.direcpc.com) 09.39.12 Join Rob2223 [0] (~Miranda@pD9FE3DCC.dip.t-dialin.net) 09.42.40 Quit Rob2222 (Ping timeout: 265 seconds) 09.48.15 Quit JdGordon (Ping timeout: 252 seconds) 09.48.53 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 09.53.28 # I think the "Reported in" field in the tracker is pointless since everyone just picks Release 3.6 even if it's a current build, maybe we should just drop that field and ask them to type in the rev number since we have to ask for that anyway? 09.57.34 # is there any way to check if calling a function would overflow the stack? 09.58.09 Quit Topy44 (Ping timeout: 252 seconds) 09.58.19 # * JdGordon has got the rendering engine down to one recursing function, and no idea how to turn it into a loop 09.58.50 Join Topy44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 09.59.30 Join utanapischti [0] (~username@p4FF2DF59.dip.t-dialin.net) 10.00.29 Join stoffel [0] (~quassel@p57B4B9A2.dip.t-dialin.net) 10.03.52 Quit sasquatch (Ping timeout: 264 seconds) 10.08.21 Quit JdGordon (Quit: Leaving.) 10.09.25 # New commit by 03nls (r28227): Fix FS#11513, pictureflow keymap in the manual was wrong. 10.11.08 # r28227 build result: All green 10.12.20 # ah, pictureflow keymap *for fuze* was wrong 10.14.38 Join hebz0rl [0] (~hebz0rl@dslb-088-065-215-015.pools.arcor-ip.net) 10.14.44 Join JdGordon [0] (3a6d839a@gateway/web/freenode/ip.58.109.131.154) 10.15.47 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 10.19.58 Join T44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 10.20.44 Quit Topy44 (Read error: Connection reset by peer) 10.23.13 Quit T44 (Read error: No route to host) 10.23.17 Join Topy44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 10.25.46 # JdGordon: pong 10.26.07 Join JdGordon1 [0] (~jonno@111-220-210-207.wbroadband.net.au) 10.27.16 Join T44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 10.30.16 Quit Topy44 (Ping timeout: 264 seconds) 10.35.09 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 10.35.18 Quit T44 (Ping timeout: 240 seconds) 10.46.15 # %xl inside the viewport %xd is in would take away functionality (which is very handy) - if it's outside you can use the same bitmap (strip) in different viewports. I do so with a bitmap strip which reduces single bitmaps quite a lot 10.46.46 # gevaerts: will try the partial early USB fix later 10.50.08 Quit JdGordon1 (Ping timeout: 272 seconds) 10.54.20 Quit balintx_ (Read error: Operation timed out) 10.54.46 Join Topy44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 10.58.17 Quit JdGordon (Ping timeout: 265 seconds) 10.58.41 Join balintx [0] (~balintx@fibhost-67-58-201.fibernet.hu) 11.00.00 # n2 11.01.04 # err... n1s: IIRC there is no "current build" option in flyspray's "Reported in" field, at least I remember having trouble finding something suitable 11.02.16 Join JdGordon [0] (6fdce2e2@gateway/web/freenode/ip.111.220.226.226) 11.02.18 # pixelma: that's correct, maybe we should add that but people still choose "release" even if they use a current build so itäs more confusing than usefull imo 11.02.54 # i've seen references to "stable r28***" and "3.6 r 28***" or similar 11.04.08 *** Saving seen data "./dancer.seen" 11.04.12 # pixelma: grr, reply didnt go through... i've got a patch to hopefully make the probaly stack problems at least better 11.04.22 # but cant get to it right now.. so ill nag you to test a bit later 11.05.41 Join ender` [0] (krneki@foo.eternallybored.org) 11.06.57 # ok, I'll try once you have that up. It's really a stack problem - with the doubled stack on my Ondio I have 24% stack usage after booting, 50% after going to the WPS, so half the stack makes that 48% (which I saw) and the other is just above 100% and ends in a hang 11.10.22 Quit balintx (Read error: Operation timed out) 11.10.43 Join balintx [0] (~balintx@fibhost-67-58-201.fibernet.hu) 11.11.38 # * pixelma also needs to try the %t fix 11.11.58 # not having those inside the conditionals there was only one weirdness: the first "run" was default 2s and then it goes on as I set in the WPS (5 or 6 seconds 11.12.11 # ) 11.17.15 Join kugel [0] (~kugel@g231106116.adsl.alicedsl.de) 11.17.17 Quit kugel (Changing host) 11.17.17 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.21.06 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.21.09 Quit kugel (Read error: Connection reset by peer) 11.25.46 # Does anyone know why the track *title* of a .mod file is used as "artist" in the metadata? 11.25.59 # This seems to have been done on purpose, but I can't figure out why 11.26.19 Quit JdGordon (Ping timeout: 265 seconds) 11.27.44 Join kugel [0] (~kugel@g231106116.adsl.alicedsl.de) 11.27.46 Quit kugel (Changing host) 11.27.46 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.27.53 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 11.29.34 # IIRC .mod doesn't really have metadata, it's more or less an attached text file where there was a bit of convention what things on line # meant (I saw a lot of files not being correct there). I seem to remember some discussion about it though but no details 11.29.44 # S_a_i_n_t: did you stop working on the icons? 11.30.03 # maybe not a "file" in that sense 11.30.25 # pixelma, yes, there was some discussion about this, but nobody knew the answer back then, IIRC 11.31.20 # pixelma, AFAIK, there is one track title, plus some loose convention that other "metadata" is put in the instrument names 11.34.15 # What happens now is that the artist field of rockbox metadata is filled with the title of the MOD. The title field of the rockbox metadata is not filled by the metadata parser, so it somehow (how?) gets automagically filled with the file name in the WPS 11.35.15 # the how is probably due to the theme writer 11.35.54 # If I fix it such that the rockbox metadata title field is filled with the MOD title, the "artist" field in the WPS shows "(root)" 11.35.55 # if he coded the theme to fall back to the filename if artist information is not available 11.36.25 # is this with cabbiev2? 11.36.42 # ah, ok, so this is part of the theme, not some fallback in rockbox firmware :) 11.36.45 # pixelma, yes 11.39.51 # cabbiev2 (looking at the Clip's version) is coded to show filename if title tag is not present, and the directory name 2 level above if artist information is not present (and if the directory 2 levels above is the root directory, it'll show (root)) 11.40.34 # so, your artist field isn't populated then 11.41.24 # thanks, that explains a lot 11.44.41 Quit Judas_PhD (Quit: This is a quitting message) 11.48.40 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.14.42 Quit n1s (Quit: Lämnar) 12.22.09 Join pamaury [0] (~quassel@dhcp-128-203.residence.ens-lyon.fr) 12.22.09 Quit pamaury (Changing host) 12.22.09 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.22.20 Quit robin0800 (Remote host closed the connection) 12.23.54 Quit kugel (Ping timeout: 245 seconds) 12.24.53 # New commit by 03bertrik (r28228): Fix FS# 11414 : .mod files - metadata in incorrect fields 12.26.36 # r28228 build result: All green 12.29.33 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.41.38 # * TheSeven again asks ipod owners to please test http://www.rockbox.org/tracker/task/11663 12.44.18 Nick drizztbsd_ is now known as drizztbsd (~quassel@unaffiliated/drizztbsd) 12.48.33 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 12.49.44 Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) 12.50.20 # TheSeven: bootloader releases are generally made independently of main Rockbox releases. 12.52.32 Join MethoS- [0] (~clemens@134.102.106.250) 12.53.07 # kugel: Nope, but...being offline for several weeks hasn't helped maters any. 12.53.26 # All I need to do are the viewer icons, shouldn't take long. 12.53.33 # linuxstb: this one also affects the main build 12.59.10 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 13.00.17 Quit Judas_PhD (Quit: This is a quitting message) 13.01.10 # pixelma: http://pastebin.com/kY9Cettk 13.01.19 # anyone else getting screen corruption also 13.02.54 Join Evilnick_ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) 13.04.11 *** Saving seen data "./dancer.seen" 13.05.09 Quit Evilnick__ (Ping timeout: 245 seconds) 13.06.54 Join DerPapst [0] (~Alexander@p5797C9E6.dip.t-dialin.net) 13.07.09 Quit Topy44 (Read error: No route to host) 13.07.48 Join Topy44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 13.11.22 Quit JdGordon (Quit: Leaving.) 13.11.31 # JdGordon: patch doesn't apply here - I get quite a few failed hunks with r28227 13.11.35 Join JdGord [0] (~jd@pa58-109-131-154.pa.nsw.optusnet.com.au) 13.11.46 # JdGord: : patch doesn't apply here - I get quite a few failed hunks with r28227 13.12.25 # JdGord: did you try the apks yet? 13.12.39 # Svn up? 13.13.06 # Not yet. Was waiting till I can dl over wifi.. might just do it noe though 13.13.43 # Can you try the 320x480 cabbie sbs on your phone? 13.13.47 # it's almost the last revision, the only commit was bertrik's metadata thing 13.13.52 # since 13.14.04 # Ok hand in 13.14.05 # On 13.14.41 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 13.15.52 # what hunk failures? 13.15.58 # use -p1 13.16.05 # I can, but I didn't like the playlist viewer on the screen shot 13.16.06 # -p1 doesn't help 13.16.25 Quit JdGord (Client Quit) 13.16.43 # it's weird. It *looks* ok... 13.16.44 # JdGordon: skin_render.c, hunk #3 and on 13.17.05 # #3-#13 13.17.26 # hmm... "patch unexpectedly ends in middle of line 13.17.49 # I think pastebin is mangling it 13.18.19 # possibly 13.18.32 # http://jdgordon.info/rockbox/changes.diff 13.18.58 Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) 13.19.13 # kugel: well it needs an area for the buttons popup, so the playlist viewer might stop people wondering why the whole screen isnt used 13.19.16 # also.. I like it :D 13.19.31 # we cant popup anything over the list 13.19.33 # it could show the buttons all the time 13.19.43 # it could 13.19.56 # just like the aa image could be the menu button 13.20.01 # JdGordon: yes, that one applies 13.20.27 # that change has some really pathitically crappy stack protection, if it panics at least the cause will be 100% certain 13.20.32 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 13.20.52 # having the fonts in the apk le suck! 13.22.35 # kinetic scrolling works nice :) 13.27.27 Join Zarggg_ [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 13.28.33 # JdGordon: compiles, just want to let you know that I get a warning: /apps/gui/skin_engine/skin_render.c:440: warning: implicit declaration of function ‘panicf’ . Going to try now 13.28.48 # yep, fine, perfectly ignorable 13.29.51 # JdGordon: thank you to fix FS#11662. my theme works fine now. 13.30.17 # no worries :) you do know that conditionals dont require the false branch right? 13.30.37 # e.g %?bc works just as well as %?bc 13.30.47 Quit Zarggg (Ping timeout: 252 seconds) 13.31.01 # the empty false was actually what the problem was (so actually a good thing you were doing that :p ) 13.32.03 # pixelma: assuming it works, can you add a bunch of nested conditionals untill it break please? 13.33.11 # yes, i know that. 13.33.52 # * kugel thought kinetic scrolling would be practically impossible to do with rockbox a month ago but it was a lot easier in the end 13.34.20 # does it work if the list isnt using the whole display? 13.34.24 # and.. how did oyu do it? 13.34.57 # JdGordon: *PANIC* skin engine: rendering stack overflow 13.35.09 # woo \o/ 13.35.11 # with my usual WPS 13.35.31 # the one with screen corruption? 13.35.36 # no additional nested conditionals, the one that once worked 13.35.49 # no, the one with the hang 13.35.59 # ok, now we know why then 13.36.20 # that panic is when the main stack is > 90% before doing a recursive call 13.36.24 # JdGordon: should work, maybe it'll be a bit tricky if you swipe outside the list area, but in theory it should work fine 13.36.27 # i.e stackusage+++ 13.37.08 # JdGordon: well the stack usage with the double stack build is 50% after going to the WPS, so half the stack - 100% is not unexpected 13.37.24 # sure 13.38.04 # ok, well now I'm slightly out of my depth.... 13.41.53 # JdGordon: http://pastie.org/1209791 is the patch, it has a few comments about how I did it 13.43.57 # anyone want to untangle this mess? I've got it down to one recursion call which should be able to be changed to a loop... but I suck at that... any volanteers? 13.44.54 # http://pastebin.com/3CVGKW1w or ideas how to minimise its stack usage? 13.51.40 Join sanb [0] (~6daa103b@giant.haxx.se) 13.52.24 # Looks like abour 28 bytes of stack usage 13.52.30 # Not *too* horrible 13.52.30 # hi all 13.52.48 # sorry for my english 13.53.14 Join krabador [0] (~krabador@host107-179-dynamic.3-87-r.retail.telecomitalia.it) 13.53.14 # can i install rockbox to iriver s100? 13.53.19 # no 13.53.50 # Only the players that are explicitely mentioned on the rockbox home page will work 13.54.01 # gevaerts: (stupid question) why did I keep thinking it copies the whole funciton onto the stack? 13.54.05 # :( 13.54.14 # why is 28 bytes killing it then? is it that full already? 13.54.21 Quit sanb (Client Quit) 13.54.37 # JdGordon: sorry, I'm not a psychologist :) 13.55.13 # pixelma: pastebin your wps please? and can you check your stack usage with a wps which is just "%we" 13.56.15 # There's some overhead like return addresses too of course, but it's still not anywhere near those things that add a sector buffer or similar 13.56.20 # sure, and sure. Only the WPS or a complete zip? 13.57.18 # only the wps and sbs if it has one 13.57.42 # * JdGordon is going to make these gotos work anyway! :) 13.58.02 # ntill I give up :p 14.00.18 # stack usage with an %we WPS is 48% just like without going to the WPS 14.01.24 # wow...that seems, ...wrong. 14.01.33 # ok, comment out line 660 in skin_render.c and run it again and check usage 14.01.51 # with your normal wps 14.02.32 # JdGordon: 660 with or without your test patch? 14.02.35 # no SBS, .wps is here: http://pastebin.com/DE90v0dg 14.02.53 # umm... the line "needs_update = skin_render_line(line, &info);" 14.03.06 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.03.43 # you have 5 nested conditionals... that really shouldnt add 50% to the stack usage 14.03.51 # how big is the ondio stack anyway? 14.04.42 # and dont both with that change.. stupid idea 14.04.42 # where is the main stack defined? 14.04.47 # I changed I line that usually is 0x2000 to 0x4000 and been told that it doubled stack size 14.05.03 # JdGordon: app.lds 14.05.04 # go figure ;) 14.05.48 # my test.wps with only the nested conditional line worked last I tried 14.06.31 # ok, well an 8k stack isnt magically going to use 4k in ~30byte increments 14.06.39 # ok, I'm a bit confused as to what I should change and test now, can you explain again= 14.06.41 # ? 14.08.04 # JdGordon: I'm not sure if thread_stack_usage() at that point really tells you what you want to know. It returns the maximum stack usage, not the current usage 14.08.31 # arg 14.09.01 # unless I seriously misunderstand things 14.10.26 # pixelma: try "%?mh" and check useage (with hold on) , then "%?mh<%?mh>" 14.10.37 # or some other conditional which you can force to true 14.11.37 # gevaerts, JdGordon: early USB is not crashing on my Ondio with the partial fix, statusbar is still missing as mentioned 14.12.28 # hmm, got a double stack build flashed now though, have to bring the normal one back 14.12.41 # at least RoLo#ing one 14.12.42 # that will be ok 14.13.17 # if it goes 50% -> 51% its atleast tells us something 14.16.43 # there is a single 1k buffer which ends up on the stack, but isnt called recursively so it should be fine, no other functions have more than a hadful of pointers 14.16.47 # with one %?mh, no change in stack usage, stays at 24% just like after boot (maybe rounding hides a small difference) 14.16.51 # s/pointers/pointer sized vars 14.22.12 # stripwax is consistently top posting... 14.22.58 # yeah, annoyed me too already and I always wanted to tell him when he comes here but he doesn't 14.23.22 # * JdGordon plays a tiny little fiddle 14.23.43 # pixelma: how does it go with nested conditionals? 14.24.52 # second level "%?mh<%?mh> : stack usage 24% > 29% 14.25.22 # 5%? thats rather high... whats that in bytes :p 14.25.51 # 820 bytes?! 14.27.27 Join fml2 [0] (~5df3d039@giant.haxx.se) 14.28.06 # one level more: > 36% 14.28.15 # JdGordon: maybe gcc is going crazy with inlining or something? 14.28.32 # JdGordon: maybe you don't notice some recursive calls? 14.28.52 # looks like it's increasing exponentially or something? 14.28.56 # Like a call in the middle of an expression 14.28.57 # but only the local variables get put on the stack right? I cant see any function with more than maybe 100 bytes of vars 14.29.00 # which function ins the prime suspect? 14.29.26 # JdGordon: maybe run the sim in a debugger so you can see backtraces? 14.29.41 # apps/gui/skin__engine/skin_render.c skin_render_line() although these numbers are with a patch 14.29.50 # JdGordon: yes, local vars are on stack but the compiler can use more stack 14.30.22 # JdGordon: it's only the increased stack, I reverted your patch - shall I apply again? 14.30.30 # do_tags_in_hidden_conditional() has lots of recursion but should be tiny stack usage 14.30.34 # n1s: but hundreds of bytes? 14.31.05 # pixelma: yeah, reaaply that patch, but comment out the panic line and the if before it 14.31.43 # gevaerts: lear has made some commits to mark functions as "noinline" because gcc would inline them causing stkovs, seems to only have happened for coldfire/gcc3.4 though 14.31.48 # He-he, I once saw a banner "Iteration to human, recursion to god" 14.32.41 # n1s: the inlining as such won't cause stkovs. It's a tiny bit more complicated I think 14.33.48 # gevaerts: true, but if the compiler inlines agressively and at the same time isn't clever enough to only alloc the stack vars as they are needed thisngs might explode 14.34.36 # even still, I dont see any arrays which could get even close to 800 bytes 14.34.54 Quit fml2 (Quit: CGI:IRC) 14.35.13 # static char tempbuf[128]; probably wont end up on the stack right? 14.35.29 # it shouldn't 14.35.58 # "static" things cannot live on the stack 14.36.14 # just making sure :) yeah, I'm baffled :p 14.37.20 # are there tools that can analyze stack usage from the asm code produced? 14.39.38 # * JdGordon grumbles 14.41.36 Join _s1gma [0] (~d.d.derp@77.107.164.131) 14.43.01 Quit JdGordon (Quit: Leaving.) 14.44.05 # JdGordon: no change in stack usage with your patch - at 36% now with the doubled stack at 36% with the 3 level nested conditional 14.44.52 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 14.45.15 # JdGordon: no change with your patch 14.45.52 # numbers are the same? 14.47.04 # yes - with the 3 level nested conditional and the double stack build it's at 36% which is the same as without your patch 14.47.04 # hm, maybe someone should check these numbers on non-sh 14.47.11 # * gevaerts gets his Clip 14.48.44 # my M5 goes from 52% to 90% stack usage with a similar WPS that crashes the Ondio - it has some more viewport things though 14.49.22 # but the nested conditional line should be the same 14.51.39 Join Acorn [0] (bcdf785d@gateway/web/freenode/ip.188.223.120.93) 14.52.30 # Is it possible to stop the Clip+ OF from generating files and folders every time it gets a chance to boot? 14.52.32 # kugel: What CPU does your phone have that it only reaches 40% realtime with ape -c5000? 14.53.06 # Or is that plain C? 14.54.12 # 600MHz armv6, and yes 14.54.24 # let me make another run with asm enabled 14.55.01 # Acorn, no, not that I know of 14.55.14 # JdGordon: skin_render_playlistviewer uses a 1k stackbuffer, is static and called in one place so will likely get inlined into do_non_text_tags which is also called from one place and static so likely inlined into skin_render_line, add to that less than clever stack allocation and each recursive call to skin_render_line eats more than a k of stack 14.55.25 # Hmm, v7 would be better, as it could then make use of neon 14.55.31 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 14.55.47 # bertrik: I have a vague recollection of seeing a solution somewhere.. possibly a hacked firmware.. can't find it anymore though 14.55.54 # My n900 gets ~210% realtime (600MHz ARMv7), tested with the standalone tool only though 14.55.57 # but we build for armv5 currently 14.56.07 # oh 14.57.02 # v6 code should be almost twice as fast as the v5 version 14.57.36 # But I guess it would need dynamic selection on android... if there are androids with a v5 cpu 14.57.50 # n1s: oh, good catche 14.57.52 # -e 14.58.03 # I don't know if there are any real armv5 androids 14.58.10 # I doubt it but the ndk defaults to armv5 14.58.27 # A few noinlines in that file may be useful then 14.59.29 # even the very first android phone has armv5 IIRC 15.00.27 # ? 15.00.48 # armv6* 15.00.57 # ah ok 15.01.02 # 51.5% with asm 15.01.02 # The G1? 15.01.15 # yes 15.02.35 # pixelma: could you try http://pastebin.com/GaNv8Bmq ? 15.02.46 # If n1s is correct, that should really fix things 15.03.28 # oh bloody hell :p 15.03.29 # I'm probably a bit overgenerous with the noinlines though. They're probably not all needed 15.03.36 # they arnt :) 15.03.56 # JdGordon: it's a test patch :) 15.04.03 # How does noinline affect stack usage? 15.04.15 *** Saving seen data "./dancer.seen" 15.04.40 # 1k local var 15.04.58 # amiconn: if a stack-heavy leaf function gets inlined in its caller which is recursive, you're in trouble 15.05.22 # Doesn't it allocate the stack in the respective block only? 15.05.27 # (it == gcc) 15.05.50 # * JdGordon thought that untill recently also 15.05.50 # gcc == stupid :D 15.06.01 # gevaerts: on top or revert the other patch first? 15.06.16 # It should, but I've seen gcc allocate stacks for all blocks at the start of the function 15.06.19 # Hmm, that's ondeed silly 15.06.25 # pixelma: this one is to svn 15.06.27 # Otoh, gcc being silly really isn't new :\ 15.06.50 Join kazaik [0] (~kazaik@pool-71-166-29-66.bltmmd.east.verizon.net) 15.06.51 # imo that's a sensible optimization 15.06.55 # gevaerts: ok, will take a moment 15.07.24 # skin_render_line allocates 1156 bytes of stack inits first instr on Coldfire at least, i can't read sh asm so i don't know how it behaves there 15.07.38 # It's sensible if one assumes huge stacks 15.08.13 # 99% of the stacks are huge, and even dynamically growing :) 15.08.46 # kugel: maybe on PCs, but I'm not sure if that's still true on sh :) 15.09.14 # these optimization mechanisms are generally independant of the backend architecture 15.10.49 # JdGordon, pixelma: should I commit my partial early USB fix? I suspect the lack of status bar is really a separate issue which will need an independent fix 15.11.03 # gcc 4.4 got a -fconserve-stack switch but that won't help here as sh and cf are still on older gcc 15.11.35 # hmm 15.11.52 # Maybe it's time for migrating gcc for them? 15.12.01 # s/migrating/upgrading/ 15.12.14 # awesome idea 15.12.20 # (needs testing, of course) 15.12.40 # That still leaves mips, which uses 4.1.x iirc 15.12.44 # amiconn: yes i think so, coldfire testing with 4.4 went quite well when i did it last time, i'll try to pick that up after the release 15.14.14 # 4.4.5 was released recently too, but maybe we should just stick to one version 15.15.08 # we could change arm to gcc 4.4.5 too 15.15.17 Join Kitr88 [0] (~Kitarist@BSN-182-143-151.dial-up.dsl.siol.net) 15.15.17 # gevaerts: go for it :) also, add the noinline to skin_render_playlistviewer which shuold be the only one that actually needs it 15.15.30 # if everyone needs to re-run rockboxdev.sh because of arch A we can change arch B too for free :) 15.15.50 Quit user890104 () 15.16.15 # is there a pragma or something to avoid inlining for the whole file? I think it makes sense because there's a lot of recursion there 15.16.48 # well, with the patch I gave before there isnt much 15.17.07 # yeah, success - with the usual stack build and the 3 level nested test.wps the stack usage difference was small enough to go unseen (48%), with my WPS it now goes to 54% :) 15.17.17 # is there any real benefit with that patch now that it fixes the problem? 15.17.20 # no hang or crash 15.17.30 # all glory to n1s 15.17.40 # and hypnotoad 15.17.42 # New commit by 03gevaerts (r28229): Add a "early_usb" argument to gui_usb_screen_run(), and don't do skin unloading/reloading in gui_usb_screen_run() in the early usb case. Fixes the ... 15.18.14 # gevaerts: yeah, justed wanted to say that no crash is worth it 15.19.11 Quit stoffel (Ping timeout: 250 seconds) 15.19.18 # JdGordon: if you have a player with hardware USB, early USB is actually reasonably easy to test. Just put a sleep() in main.c just after shiw_logo() 15.19.21 # *show 15.19.24 # r28229 build result: All green 15.19.31 # I dont 15.19.32 Quit Kitar|st (Ping timeout: 260 seconds) 15.19.42 # my h300 is broken 15.19.51 Quit Kitr88 (Ping timeout: 264 seconds) 15.20.23 # oops 15.20.32 # I committed too much... 15.20.48 # hehe snuck that in :p 15.21.51 # New commit by 03gevaerts (r28230): Revert accidental commit of skin_render.c 15.22.15 # If we only want one inline, we should do it properly :) 15.23.32 # r28230 build result: All green 15.24.32 # hm, after doing a fresh ubuntu 10.10 install and running rockboxdev.sh, ld and gcc point now to /usr/local/mipsel-elf/bin 15.25.01 Join Kitar|st [0] (Kitarist@BSN-182-83-120.dial-up.dsl.siol.net) 15.25.03 # bertrik: your path shouldn't contain /usr/local/mipsel-elf/bin anymore these days 15.25.14 # OK, so is http://pastebin.com/hf5gmAKh worth doing? I'm not sure if the code ends up being cleaner or not 15.25.27 # also, I would like some testing to make sure sublines still work orrectly with it 15.26.56 # New commit by 03gevaerts (r28231): Make skin_render_playlistviewer() noinline. This function uses lots of stack (around 1 kilobyte), and is called from a recursive function. gcc's stack ... 15.27.26 # amiconn: yea, a lot faster with armv6 build and asm 15.28.29 # r28231 build result: All green 15.29.35 # pixelma: re-testing r28231 at some point may be useful, since it now only has one noinline, so it's not exactly the same as the patch you tested 15.29.46 # It should be fine, but... 15.30.08 # amiconn: 115% rt now 15.30.46 # gevaerts: will do 15.31.58 Join earcar [0] (~carmine@93-39-245-25.ip78.fastwebnet.it) 15.33.05 Quit GodEater (Read error: Operation timed out) 15.34.30 # please test the above paste... 15.37.48 # what do I have to keep an eye on? 15.40.01 Join domonoky1 [0] (~Domonoky@agsb-4d04af5a.pool.mediaWays.net) 15.40.33 # sublines 15.40.37 # * JdGordon -> zzz 15.41.09 Quit domonoky (Ping timeout: 252 seconds) 15.45.18 Quit JdGordon (Ping timeout: 264 seconds) 15.47.04 Join kugel_ [0] (~kugel@g231233104.adsl.alicedsl.de) 15.47.24 Quit kugel (Disconnected by services) 15.47.28 Nick kugel_ is now known as kugel (~kugel@g231233104.adsl.alicedsl.de) 15.47.34 Quit kugel (Changing host) 15.47.34 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.48.20 # gevaerts, JdGordon (logs): SVN sees no stack usage in percent difference between WPS or not with my "heavy" WPS... it stays at 48% 15.48.49 Quit Acorn (Quit: Page closed) 15.48.59 # perfect :) 15.49.47 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 15.49.50 # indeed and with the early USB crash also fixed that is quite a relief :) 15.51.12 Join kugel_ [0] (~kugel@g231111206.adsl.alicedsl.de) 15.51.34 Quit kugel (Disconnected by services) 15.51.38 Nick kugel_ is now known as kugel (~kugel@g231111206.adsl.alicedsl.de) 15.51.42 Quit kugel (Changing host) 15.51.42 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.52.06 # is there a way to compile without frame pointer? we pass -fomit-frame-pointer but gcc still seems to use it 15.53.52 # kugel: -fomit-frame-pointer should work and has in my experience worked 15.54.21 # are you looking at disassembly? 15.54.22 # * pixelma wonders if the "Ipod freezes after a track skip" reports in the forums will now also go away - remembering that I got STKOVs on the M5 sometimes recently 15.54.28 # n1s: yes 15.55.12 # kugel: objdump has %fp as an alias for the real register i think so even if a framepointer isn't used the register is used 15.55.27 # at least it does so on coldfire 15.55.30 # should I dump the asm instead? 15.56.52 # we're building for shared libraries which also implies fpic (apparently), I don't actually know which options are on and which aren't 15.59.31 Join kugel_ [0] (~kugel@g231226069.adsl.alicedsl.de) 16.01.07 Join kugel__ [0] (~kugel@g231226143.adsl.alicedsl.de) 16.01.27 Quit kugel (Disconnected by services) 16.01.33 Nick kugel__ is now known as kugel (~kugel@g231226143.adsl.alicedsl.de) 16.01.37 Quit kugel (Changing host) 16.01.37 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.01.59 # n1s: going by the asm it uses fp (but I may be wrong) 16.02.14 # ff_imdct_half: 16.02.14 # @ args = 0, pretend = 0, frame = 64 @ frame_needed = 0, uses_anonymous_args = 0 16.02.17 # below it stacks fp 16.03.55 Quit kugel_ (Ping timeout: 245 seconds) 16.06.22 # some functions have frame_needed = 1 16.07.58 # New commit by 03bertrik (r28232): Fix for FS #10097 - Sometimes keys do work after exiting plugins. ... 16.08.19 # * bertrik missed a "not"... 16.08.43 # bertrik: doesn't that possible introduce other bugs? 16.08.51 # possibly* 16.09.13 # kugel, possibly, but I didn't notice any 16.09.40 # r28232 build result: All green 16.11.20 # bertrik: can't you just close it? one can always reopen or open a new task 16.12.14 # hm, yeah, might as well just close it. 16.12.20 # * kugel thinks keeping tasks open makes little sense if a fix is commit, it just keeps the ticket count high because people tend to forget about it 16.13.30 # It's also confusing if a similar bug appears later 16.13.52 # I think this bug already has a number of duplicates 16.14.06 # On a similar not, I seriously dislike multi-issue tasks 16.14.20 # this particular one was especially about problems when exiting *plugins* 16.14.45 # I bet the others are fixed as well 16.14.46 # ok closed 16.18.50 # * gevaerts wonders about that mpegplayer on greyscale ipod bug 16.19.05 # what mpegplayer on greyscale ipod bug? 16.19.20 # bertrik: it exists! :) 16.19.35 Quit fxb__ (Remote host closed the connection) 16.19.37 # FS#11653 16.22.01 Quit Topy44 (Ping timeout: 272 seconds) 16.22.33 Join helmut [0] (helmut@subdivi.de) 16.24.14 # New commit by 03teru (r28233): use different function to resize bitmap for greylib. ... 16.24.16 # not sure how r27902 could cause it 16.24.19 # hi. thanks for all the effort put into rockbox (and the manuals!). just one question: how to reboot the original firmware (back into rockbox)? 16.24.34 # uhm. I should have said that I use an ipod video 30G. 16.25.27 Quit Highlander (Quit: Quitte) 16.25.30 # helmut: I know of three ways: hard reset (menu-select IIRC), wait a few weeks, or write to the firmware partition. That last one is not recommended :) 16.25.51 # dang this is actually a faq entry. I only looked at the wrong place. 16.25.58 # sorry. the documentation is simply better than me. 16.26.07 # r28233 build result: All green 16.27.56 Quit Evilnick_ (Quit: TTFN) 16.30.15 Join kugel_ [0] (~kugel@e178054172.adsl.alicedsl.de) 16.30.37 Quit kugel (Disconnected by services) 16.30.41 Nick kugel_ is now known as kugel (~kugel@e178054172.adsl.alicedsl.de) 16.31.25 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.31.38 Join kugel_ [0] (~kugel@e178117190.adsl.alicedsl.de) 16.31.58 Quit kugel (Disconnected by services) 16.32.04 Nick kugel_ is now known as kugel (~kugel@e178117190.adsl.alicedsl.de) 16.32.08 Quit kugel (Changing host) 16.32.08 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.33.17 # yeah. it can play my ogg vorbis files now! :-) 16.34.09 # New commit by 03teru (r28234): correct comment in configfile.h, FS#11292 by Chris Savery. 16.35.42 # r28234 build result: All green 16.39.47 # I want to enable a subset of plugins for android, any idea how to do it best? 16.40.27 # without making SOURCES/SUBDIRS a complete mess I mean 16.40.42 Join Keith93 [0] (~520e3408@giant.haxx.se) 16.42.28 Quit Keith93 (Client Quit) 16.43.43 # New commit by 03kugel (r28235): Fix a few div0 cases forgotten in r27684 to enable enabling asm optimizations for android builds. 16.45.22 # r28235 build result: All green 16.50.15 Quit krabador (Quit: Sto andando via) 16.50.32 Quit AndyI (Ping timeout: 272 seconds) 16.52.17 Quit DerPapst (Read error: Connection reset by peer) 16.52.44 Join kugel_ [0] (~kugel@e179042131.adsl.alicedsl.de) 16.53.01 Join stoffel [0] (~quassel@p57B4B9A2.dip.t-dialin.net) 16.53.10 Quit kugel (Disconnected by services) 16.53.14 Nick kugel_ is now known as kugel (~kugel@e179042131.adsl.alicedsl.de) 16.53.18 Quit kugel (Changing host) 16.53.18 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.53.51 Join DerPapst [0] (~Alexander@p5797C9E6.dip.t-dialin.net) 16.55.53 Join Topy44 [0] (~Topy44@LRouen-151-71-27-149.w80-11.abo.wanadoo.fr) 16.57.17 Join kugel_ [0] (~kugel@e179041239.adsl.alicedsl.de) 16.57.39 Quit kugel (Disconnected by services) 16.57.43 Nick kugel_ is now known as kugel (~kugel@e179041239.adsl.alicedsl.de) 16.57.47 Quit kugel (Changing host) 16.57.47 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.59.02 Quit teru (Quit: Quit) 17.02.15 Quit kugel (Ping timeout: 245 seconds) 17.04.18 *** Saving seen data "./dancer.seen" 17.07.18 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.11.52 # is it correct that mpegplayer does not support playing mp4 files? 17.17.18 # yes 17.19.50 Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 17.21.58 # thanks. well ogg is better than nothing. 17.24.01 Join kugel_ [0] (~kugel@g231109203.adsl.alicedsl.de) 17.24.23 Quit kugel (Disconnected by services) 17.24.27 Nick kugel_ is now known as kugel (~kugel@g231109203.adsl.alicedsl.de) 17.24.31 Quit kugel (Changing host) 17.24.31 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.25.18 Join fxb__ [0] (~felixbrun@h1252615.stratoserver.net) 17.27.53 Join kugel_ [0] (~kugel@e178116061.adsl.alicedsl.de) 17.28.15 Quit kugel (Disconnected by services) 17.28.17 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 17.28.19 Nick kugel_ is now known as kugel (~kugel@e178116061.adsl.alicedsl.de) 17.28.23 Quit kugel (Changing host) 17.28.23 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.29.00 # Unhelpful: ping 17.29.14 Join Staphylo [0] (~Bullet@AMontsouris-159-1-66-116.w92-128.abo.wanadoo.fr) 17.30.03 # pictureflow is nice as well 17.33.55 Join kugel_ [0] (~kugel@e179040185.adsl.alicedsl.de) 17.34.17 Quit kugel (Disconnected by services) 17.34.21 Nick kugel_ is now known as kugel (~kugel@e179040185.adsl.alicedsl.de) 17.34.25 Quit kugel (Changing host) 17.34.25 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.40.19 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 17.42.22 Quit fxb__ (Remote host closed the connection) 17.43.55 Join s1gma_ [0] (~d.d.derp@77.107.164.131) 17.44.38 Quit factor (Quit: Leaving) 17.47.15 Quit _s1gma (Ping timeout: 245 seconds) 18.00.29 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 18.01.59 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 18.02.30 Quit anewuser () 18.04.14 Join kugel_ [0] (~kugel@g231110128.adsl.alicedsl.de) 18.05.49 Quit robin0800 (Remote host closed the connection) 18.05.57 Join kugel__ [0] (~kugel@g231110006.adsl.alicedsl.de) 18.06.00 Quit kugel (Ping timeout: 245 seconds) 18.06.07 Nick kugel__ is now known as kugel (~kugel@g231110006.adsl.alicedsl.de) 18.06.21 Quit kugel (Changing host) 18.06.21 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.09.06 Quit kugel_ (Ping timeout: 252 seconds) 18.10.21 Join krabador [0] (~krabador@host107-179-dynamic.3-87-r.retail.telecomitalia.it) 18.10.35 Quit kazaik (Ping timeout: 245 seconds) 18.11.19 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 18.25.24 Join fxb__ [0] (~felixbrun@h1252615.stratoserver.net) 18.32.33 Quit markun (Read error: Connection reset by peer) 18.33.27 Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) 18.35.28 Quit fxb__ (Remote host closed the connection) 18.39.29 Quit Zambezi (Changing host) 18.39.29 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 18.40.01 # does anyone object kinetic scrolling, should I put it on fs before committing? 18.43.55 # does it affect non touch targets? 18.44.06 Join markun [0] (~markun@5ED33C2C.cm-7-4a.dynamic.ziggo.nl) 18.44.12 Quit markun (Changing host) 18.44.12 Join markun [0] (~markun@rockbox/developer/markun) 18.50.29 # kugel: on which devices is it enable by default ? Does it change something in other modes ? 18.51.25 Quit kugel (Ping timeout: 245 seconds) 18.51.27 Join kugel_ [0] (~kugel@e178118082.adsl.alicedsl.de) 18.51.38 Nick kugel_ is now known as kugel (~kugel@e178118082.adsl.alicedsl.de) 18.51.52 Quit kugel (Changing host) 18.51.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.52.26 # nobody else is working on touchscreen so I'm not sure if there's a point in putting it on fs before 18.52.39 # pamaury: it's enabled when the absolute point mode is used 18.54.03 # On which targets did you test it ? Did someone else tested it ? 18.54.03 Quit kugel (Read error: Connection reset by peer) 18.54.31 # he didn't want to answer :) 18.56.45 # he has ISP problems today 18.57.32 # yeah I know, I will wait for him appearing again 18.58.56 # I wonder if it might make sense to include is as an option for touch-scroll targets like iPods and H10 (and maybe Gigabeat F?) 19.00.00 Join kugel_ [0] (~kugel@e178116174.adsl.alicedsl.de) 19.00.17 Nick kugel_ is now known as kugel (~kugel@e178116174.adsl.alicedsl.de) 19.00.22 Quit kugel (Changing host) 19.00.22 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.00.58 # kugel: Was kinetic tested by you or others and on which targets ? 19.01.01 # pamaury: I'm testing on my phone and the sdl app 19.01.20 # JdGordon likes it, [sko] tested it as well 19.01.40 # Llorean: quite possibly. but IIRC the touchpad on the h10 doesn't work? 19.01.49 # kugel: What do you mean "doesn't work"? 19.02.07 # IIRC only the top edges work, not the area between (for wiping) 19.02.20 # top & bottom edges 19.02.34 # I think the whole pad works, it's just the way current scrolling is implemented 19.02.44 # Rather than wiping repeatedly, you just need to touch the edges and hold. 19.02.49 # I may be wrong 19.03.50 # Well, I don't know for certain either. But I don't remember it being "unable to be used" just "unused" 19.03.55 # * Llorean has to go now. 19.03.58 Quit Llorean (Quit: Leaving.) 19.04.12 # * pamaury just sent a mail to the ml and calls for clip+/fuzev2 testers ! 19.04.20 *** Saving seen data "./dancer.seen" 19.07.43 Quit Topy44 (Ping timeout: 265 seconds) 19.17.39 # does the nano2g shutdown gracefully on low battery? 19.25.22 Join fxb__ [0] (~felixbrun@h1252615.stratoserver.net) 19.33.35 Quit s1gma_ (Quit: Leaving) 19.38.05 # if it does, i think FS#10876 can be closed 19.40.15 # I think the touch pad on the H10 is "not working" in the same way as the cross on the gigabeat F is "not working". I.e. we know exactly how to use all its sensors, we just don't bother because previously our scrolling method has not required them. 19.55.15 Join leavittx_ [0] (~lev@89.221.199.187) 19.58.24 Join stripwax__ [0] (~Miranda@87-194-34-169.bethere.co.uk) 19.59.45 Quit stripwax (Ping timeout: 245 seconds) 20.02.33 # kugel: apparently mpegplayer broke on ipod mini 2G (and probably ipod 4G, possibly others) around r27900 20.03.19 # This is the "small api for loading code" series of commits 20.05.07 # gevaerts: as I already said, I have no idea how that could happen (considering it only hits a few targets) 20.05.27 Join [sko] [0] (~sko]@p57A98704.dip0.t-ipconnect.de) 20.05.37 # maybe a dual core thing but I copy&pasted from plugin loading so I didn't actually change anything 20.05.37 # OK, so you don't have hints on how to fix it 20.06.15 # you could look if a cpucache_commit/_discard call got lost somewhere 20.07.00 # ah, I get an undefined instruction now... 20.07.40 Quit stripwax__ (Ping timeout: 245 seconds) 20.08.11 # kugel: where do you hide your apks? 20.08.51 # I don't hide them 20.08.54 # they're on the wiki 20.11.12 # * rasher considers anything that's not "announced regularly on IRC so I can grep for them" as hidden 20.11.15 Quit stoffel (Remote host closed the connection) 20.12.46 # I mentioned it more than often 20.12.59 # they're linked AndroidPort 20.13.33 Quit Dreamxtreme (Ping timeout: 240 seconds) 20.14.29 # Yeah, found them :) 20.15.18 # kugel: scrolling is nice now! 20.16.06 # thanks 20.16.37 Join Dreamxtreme [0] (~Dreamxtre@92.30.99.91) 20.16.44 # Maybe the list code could introduce padding? I'd like that, to give me a larger target for selecting 20.17.03 # that's not a bad idea 20.18.45 # Probably shouldn't be set by default. People would probably think it looks weird, or wastes space. Maybe 20.18.54 # Well it does waste space, obviously 20.20.47 # but that's what they all do so it's expected 20.21.40 # kugel: What svn revision are those apks linked from the wiki? Or are they updated frequently/automatically? 20.22.04 # I build them ~22h ago 20.22.27 # But I really like the kinetic scrolling 20.23.41 # kugel: What I really meant to say was that the wiki page doesn't mention what svn revision they are, or how frequently they are updated, or even if they are compiles from plain svn or have uncommitted patches. 20.23.56 # is that a problem? 20.24.23 # Well it'd be nice to have some idea what you're getting, I'd say 20.24.26 # I just suggesting that information would be useful. There's also the GPL issue. 20.24.32 # s/I/I'm/ 20.25.23 # so I could add "They're updated infrequently from arbitary svn revisions and may or may not have WIP patches applied" 20.25.53 # the source is usually available in one of the branches on my git repo 20.26.30 # That's not that helpful if someone wants the source to a build they download from you. They don't even know it's you providing them... 20.26.47 Quit [sko] (Read error: Connection reset by peer) 20.29.20 # that's boring. I take them off if you don't feel comfortable with how I handle it right now 20.30.10 # they're not there because they are a custom build or for my pleasure. they're there because I'm frequently asked for preview apks since the build system doesn't provide them 20.32.17 # kugel: do you have some idea about which targets have broken IRAM-using plugins? 20.32.44 # uhm, no 20.33.06 # I tried the changes on my e200 and it worked fine 20.33.17 # ok 20.34.29 # Apparently mini1g, mini2g and ipod4g are definitely broken 20.35.03 # Looks like greylib+dualcore at first sight 20.40.18 # my e200 and clip work fine 20.40.48 # -DFORCE_SINGLE_CORE doesn't help 20.44.37 # hm, maybe FORCE_SINGLE_CORE itself just doesn't work... 20.50.02 # kugel: Eh, really? You're just as bound by the gpl as any random joe posting custom builds somewhere. At least add a bit more text explaining what they are.. 20.51.40 Join [sko] [0] (~sko]@p57A98704.dip0.t-ipconnect.de) 20.52.52 # a little text is fine 20.55.41 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 21.02.05 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.02.21 # stripwax: hey :) 21.04.21 *** Saving seen data "./dancer.seen" 21.08.58 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 21.09.22 Quit GeekShadow (Quit: The cake is a lie !) 21.11.24 Quit bmbl (Quit: Bye!) 21.19.55 Quit Horscht (Quit: Verlassend) 21.19.55 Quit Llorean (Quit: Leaving.) 21.30.34 Join _s1gma [0] (~d.d.derp@77.107.164.131) 21.32.30 Join bertrik_ [0] (~bertrik@rockbox/developer/bertrik) 21.32.30 Quit bertrik (Read error: Connection reset by peer) 21.36.53 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 21.40.29 Quit Chronon_ (Ping timeout: 265 seconds) 21.40.29 Quit _s1gma (Quit: Leaving) 21.42.38 # kugel: mp3 is probably slower with ASM because it spends most of its time in the hand written filterbanks, all of which are carefully scheduled for arm7 21.42.38 # i bet newer ARM flavors are tremendously more efficient then armv4 21.42.38 # saratoga: did you see my mail on the ml? 21.42.38 # regarding the mdct? 21.42.38 DBUG Enqueued KICK saratoga 21.42.38 # above i meant scheduled for arm7tdmi, not armv7 :) 21.42.38 # yes 21.43.58 # unfortunately while i have a pretty good idea how the MDCT works, i don't understand anything about fpic or arm registers 21.44.14 # other then "arm has too few registers" 21.44.36 # well, the problem seems to be that the asm uses register that are used for by the host systme 21.45.01 # yeah stripwax said those loops probably needed to be rewritten in pure asm i think? 21.45.42 # for android those asm operations (beyond the fft8/fft16 blocks) probably don't help much anyway 21.45.52 # but it would be really nice to fix them so we could get that patch into tremor 21.46.14 # the mdctlib is very arm7/arm9 optimized 21.46.31 # well, the flac and ape are accelerated vastly by the asm optimizations 21.47.05 Quit froggyman (Read error: Connection reset by peer) 21.47.08 # ape has optimizations for arm11 and higher though which makes a huge difference 21.47.27 # i think most our arm asm is scheduled for arm7 so i't far from optimal on newer cores 21.47.40 # i have no idea what flac does, it was optimized by preglow (i think) right around when i started on this project 21.48.06 # eventually we'll probbaly want to go through and redo both the mp3 filterbank and mdctlib in neon 21.48.11 # yeah, almost all the time in flac is spent in asm code afair 21.48.20 # the fft loops in the mdctlib could be made much, much faster in neon 21.48.34 # neon is cool 21.48.57 # armv5/v6 have no neon 21.48.59 # since they're all "load a half dozen values, do a half dozen independent adds, store a half dozen values 21.49.21 # and IIUC neon isn't a strict requirement for v7+ too (not sure with this one) 21.49.28 # yeah but from now on DAPs are probably going to stay arm9e, and phones are always going to be Neon 21.49.34 # its not 21.49.42 # but so far no one has ever made a phone chipset with out it 21.50.02 # the only cortex line i've seen with neon is the Tegra 2 from nvidia, and its not used in phones 21.50.14 # "without neon" i mean 21.50.28 Join froggyman [0] (~seth@unaffiliated/froggyman) 21.50.34 # i guess someday there could be tablets running rockbox without it though 21.50.53 # not sure its worth caring about battery life on a tablet 21.51.04 # IIRC most of those use 1-2 WATTS on the screen alone 21.51.18 # saving 2-3 mW on audio decode is unlikely to make a difference 21.51.19 # we could even switch between versions for different arm ISA's runtime where it makes sense, like on android 21.52.07 # in the long run we should probably go towards a system like ffmpeg where we have a few generic DSP functions implemented in the codeclib, and then at runtime we select which version we want to use 21.52.32 # kugel: http://pastebin.com/LjRZn9Xj makes mpegplayer work again on my mini 21.52.37 # from a quick look that flac code has some stalls on arm11 at least, i don't remember whre arm9 stalls 21.52.39 # e.g. mdct_window_neon 21.52.58 # arm9 is a 5 stage pipe so it doesn't stall much 21.53.18 # branches and multiplies on arm9e are 1 cycle stalls IIRC 21.53.21 # also the test flac track decodes in about 3 seconds on the beast so optimizing thst for arm11 doesn't feel very important :) 21.53.36 # gevaerts: strange 21.53.52 # maybe the memory barrier doesn't work? 21.53.58 # neon could massively accelerate mp3 decodeing too 21.54.13 # probably like a factor of 2-3 faster then armv6 21.54.18 # saratoga: does it stall when using the result of a ldr in the following instr? 21.54.32 # i don't think so, assuming its a cache hit 21.54.35 # but i'm not certain 21.54.37 # gevaerts: or does it have sections that's not included in the bss? 21.54.53 Quit domonoky1 (Read error: Connection reset by peer) 21.54.55 # sharedbss maybe? 21.55.03 # kugel: I'm now looking at addresses to see if that memset uses the correct values 21.55.24 # the memset values are a bit different to before IIRC 21.55.31 # hmm let me look into that i can't remember the arm9e pipe that well 21.55.41 # well, I thought they're equivalent but maybe they're not 21.56.17 # n1s: IIRC yes 21.56.44 # IIRC a load takes 1c on it unless the next instr uses the result 21.56.45 # The code used to assume that everything outside the area loaded from the plugin file was bss or unused 21.57.03 # Now it tries to clear just the bss bit 21.57.20 # "On an ARM926 you should always try leave one cycle, preferably two cycles after a load before you use the register. Leaving more than this can always help if you have enough registers to let you do it of course." 21.57.30 # not sure about arm9E though 21.57.39 # yea but I looked at plugin.lds if there's anything after plugin_end_addr and IIRC there wasn't 21.58.35 # saratoga: arm926 is arm9e 21.58.45 # oh wait 21.58.53 # no iirc its arm9tdmi 21.58.58 # but yes arm names are stupid 21.59.30 # arm9e is armv5 right? I recall it's about the same as arm9 in that regard 22.02.57 # yeah, according to the System Developer's Guide, the result of ldr is unavailable for 1 cycle on arm9E and arm9tdmi and 2 cycles on arm11 22.03.49 # n1s: where did you find this, i just skimmed the whol emanual and can't find stall info for anything but the cache and tcm? 22.04.27 # appendix D in arm system developer's guide 22.05.09 # the actual ldr instruction can take one or 2 c on the arm11 too 22.05.20 # n1s: got a link? 22.05.28 # so stupid this isn't in the arm9e manual 22.06.30 # i did find a free download on some site but i can't remember which 22.07.31 # saratoga: ape is also a lot slower in a armv5 built (40% -> 52%) 22.07.40 # that was for c5000 22.07.56 # saratoga: this one maybe http://avaxhome.ws/ebooks/programming_development/1558608745ARMSystem.html 22.08.31 Quit [sko] (Read error: Connection reset by peer) 22.11.25 # gevaerts: plugin_end_addr is indeed the last thing in plugin.lds but there's some NOCACHE magic above 22.12.05 # kugel: there are two things I'm unsure about. The NOCACHE magic, and iram_copy being re-used for bss later on 22.12.19 # anyway, it the nc* stuff should be between plugin_bss_start and plugin_end_addr if I read that correctly 22.12.45 # it is, with a different alias 22.13.03 # the iram stuff is in the binary where the bss is later, only linked to a different address 22.13.19 # yes, it *should* be fine, it's copied to IRAM first 22.13.54 # if you don't do this you have a wasted gap between data section and bss after the code loaded 22.15.45 # I'm not seeing what's wrong 22.16.25 # Codecs don't seem to have issues either 22.21.54 # gevaerts: does the map file show anything after plugin_end_addr? 22.23.21 # kugel: yes and no. .ncbss is after that, but at addresses that alias to addresses before plugin_end_addr 22.24.15 # The problem isn't that that memset() doesn't clear enough. Otherwise removing it wouldn't help 22.24.23 # gevaerts: I think the alias counts. it looks like the PP hardware has uncached ram at a fixed offset after the cached ram 22.24.37 # it does, yes 22.25.58 # so, clearing the entire plugin buffer before loading helps even though it doesn't clear the parts of the bss where iramcopy stuff was 22.26.01 # strange 22.26.38 Quit fxb__ (Remote host closed the connection) 22.27.22 # maybe it needs another cache discard after the memset? 22.27.57 # Maybe 22.28.35 # cpucache_invalidate() or cpucache_flush()? 22.28.47 # cpucache_discard() :) 22.28.52 Quit earcar (Quit: earcar) 22.29.07 # hm that alias is not in the plugin api? 22.29.10 # no 22.29.50 # I'd try cpucache_invalidate() before the memset 22.30.15 # (because it commits the cache, possibly making bss dirty again) 22.30.29 # That's there already, with the asm barrier in between 22.30.44 # I suspect the problem is that the cop doesn't see that the cpu zeroes the bss 22.31.19 # that one isn't always executed but I suspect mpegplayer uses iram? 22.31.30 # I doubt it actually. I tried a single-core build, and it also crashed 22.31.41 # ah right 22.31.52 # I'd give it a try anyway 22.31.52 # mpegplayer uses iram, yes 22.32.29 # what exactly? Another invalidate? 22.32.37 # yes 22.33.42 # maybe also one before the iram copying, perhaps the cop's cache trashes iram after it's been copied 22.34.21 # hm, otoh the load_code code explicitely clears the cache of the other core so it shouldn't be much of a problem 22.34.26 # S_a_i_n_t: did you find time to test my patch? 22.34.32 # i.e. no idea what's wrong 22.37.25 # TheSeven: do you think FS#10876 can be closed? 22.38.19 # kugel: http://pastebin.com/EDmvunki seems to fix it 22.38.51 # n1s: hopefully yes 22.39.03 # that'd only make sense if a single core build worked though 22.39.22 # There's always the possibility that I did something wrong there 22.39.31 # this apparently was a combination of it shutting down at a too low voltage triggering usual wsod problem 22.40.05 # i mean a lot of these issues have been fixed and it's an old report so maybe we should just close it or we could just stick in the ususal "Does this still happen to you?" and wait a couple of weeks first 22.40.09 # gevaerts: directly before doesn't work? 22.40.09 # the charge curve and shutoff levels have been calibrated and according to several people the wsods generally have gone away 22.40.47 # invalidate() might also commit the cache, potentially discarding the memset partially before 22.40.49 # also, this report is about 10 months old 22.40.53 # kugel: actually, the memset tries to clear nocache RAM by writing to cached addresses... 22.40.59 # whatever it was, it has been fixed for sure 22.41.06 # My guess is that that's what was going wrong 22.41.44 # that sounds like a good guess 22.41.51 # TheSeven: ok, will you close or should i? 22.41.54 # And I really don't think rb->cpucache_invalidate(); 22.42.13 # And I really don't think rb->cpucache_invalidate(); asm volatile ("" ::: "memory"); rb->cpucache_invalidate(); makes much sense 22.42.23 # n1s: i just killed it 22.42.44 # yea, I thought about moving the other invalidate out of the if() 22.42.58 # TheSeven: great 22.43.01 # no point anymore now :) 22.43.10 # kugel: I think I'll commit this and ask the FS#11653 people to verify. Are there other FS tasks about this? 22.43.36 # I didn't even know about fs#11653 :) 22.43.58 # It's not very old :) 22.44.12 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 22.44.12 # * TheSeven threatens to just commit FS#11663 if nobody wants to test it 22.44.39 # that's the problem, I had subscribed to the new tasks rss feed until some weeks ago ; 22.44.40 # ;) 22.45.13 # the clickwheel driver isn't used in the ipod bootloader, is it? 22.45.36 # if you think this hunk might break something, please speak up: 22.45.36 # +#ifndef BOOTLOADER 22.45.37 # backlight_hold_changed(hold_button); 22.45.37 DBUG Enqueued KICK TheSeven 22.45.37 # +#endif 22.45.41 # kugel: should we do the same in codec_crt0? 22.45.47 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 22.45.47 # * pixelma is testing a lot but doesn't have a 2nd gen Nano 22.46.14 # pixelma: I also want to make sure that it doesn't break the other generations as it's common ipod code 22.46.31 # i have tested the nano2g myself, but i can't test the other ones 22.46.34 # gevaerts: I think so, this once-at-load cache clears don't hurt IMO 22.46.34 # I don't have an Ipod at all, the closest would be my c200 :) 22.46.48 # however, that hunk is the only one that isn't inside a nano2g-specific ifdef 22.47.06 # and the fact that it even compiled before tells me that it can't affect anything in theory 22.47.56 # TheSeven: the PP ipod bootloader doesn't use the real wheel driver, no 22.49.28 # New commit by 03gevaerts (r28236): Invalidate the CPU cache after clearing bss, to make sure that bss variables that are used via non-cached aliases don't read garbage. ... 22.50.09 Quit n1s (Quit: Lämnar) 22.51.07 # r28236 build result: 14 errors, 0 warnings (gevaerts committed) 22.52.50 # New commit by 03theseven (r28237): Commit FS#11663 by me - Patch: iPod Nano 2G Bootloader: Boot OF if MENU button is held 22.53.49 # New commit by 03gevaerts (r28238): Guard the cpucache_invalidate() with proper #ifdefs 22.54.26 # r28237 build result: 14 errors, 0 warnings (theseven committed) 22.54.54 # I'd just removed ifdefs from the APIs, the cache functions have stubs in the core 22.55.01 Quit froggyman (Quit: Bye) 22.55.12 # kugel: you know these things, I don't :) 22.56.11 # r28238 build result: All green 22.58.24 Join froggyman [0] (~seth@unaffiliated/froggyman) 23.01.27 # looks like a nice bug fixing day. Thanks all involved 23.02.51 Quit froggyman (Client Quit) 23.03.33 # * pamaury makes a new call for testers and redirect them to FS#11664 (amsv2 usb !) 23.04.24 *** Saving seen data "./dancer.seen" 23.05.19 Join froggyman [0] (~seth@unaffiliated/froggyman) 23.05.58 Quit krabador (Quit: Sto andando via) 23.10.50 # pamaury: do I have to replace the bootloader to test it? 23.10.57 # no 23.11.28 # just the firmware, should be dead simple 23.11.49 # ok, will try 23.11.56 # thanks 23.12.53 Join drizztbsd_ [0] (~quassel@unaffiliated/drizztbsd) 23.13.13 Quit drizztbsd (Ping timeout: 260 seconds) 23.19.40 Quit bertrik_ (Quit: :tiuQ) 23.25.01 Join krabaodr [0] (~krabador@host107-179-dynamic.3-87-r.retail.telecomitalia.it) 23.26.04 Nick krabaodr is now known as krabador (~krabador@host107-179-dynamic.3-87-r.retail.telecomitalia.it) 23.27.14 Quit panni_ (Read error: Connection reset by peer) 23.27.37 Join wodz [0] (~wodz@chello087206240131.chello.pl) 23.27.38 Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 23.28.10 # gevaerts: does your commit fix greylib on dualcore PP or something else? 23.29.17 Join Luca_S [0] (~5707487c@giant.haxx.se) 23.30.12 # pamaury: I will be able to test your usb patch tomorrow (9 hours from now), or right now if you can provide me a build somewhere 23.30.20 # (forgot to say: on fuzev2) 23.30.39 Quit drizztbsd_ (Remote host closed the connection) 23.30.51 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 23.32.07 # Luca_S: I prefer that build it by yourself if it's not a problem, 9 hours will not change much anyway :) 23.32.25 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 23.32.27 Join drizztbsd [0] (~quassel@unaffiliated/drizztbsd) 23.33.50 # don't know if you're interested, however when using plugging usb with cpu frequency switching it always fails with PANIC Wrong Architecture (0) 23.35.16 # with frequency switching ? It is a patch from flyspray ? It probbaly means a wrong clock frequency and thus the usb controller doesn't start 23.36.01 # yes, it's on FS. let me find the FS number 23.36.47 # FS#11297 23.36.51 # I never tested it, I think funman is more likely to know why, I don't really understand the way the usb clock is setup, it's reverse-engineered anyway 23.37.30 Quit drizztbsd (Remote host closed the connection) 23.38.48 # usb is clearly more important, especially since frequency switching doesn't seem to have dramatic effects 23.39.29 Join drizztbsd [0] (~quassel@unaffiliated/drizztbsd) 23.41.10 # a possible explaination is that with the current setting, the usb clock is linked to the clock of which the frequency changes, thus changing the usb core frequency 23.41.53 # the strange this is that I'm pretty sure the usb code boosts on init, so the frequency should be stable over a usb connection 23.41.57 Quit drizztbsd (Remote host closed the connection) 23.49.17 Join drizztbsd [0] (~quassel@unaffiliated/drizztbsd) 23.49.40 Join kugel2 [0] (~kugel@e178116174.adsl.alicedsl.de) 23.49.41 Quit kugel (Disconnected by services) 23.49.42 Quit kugel2 (Client Quit) 23.49.48 Quit drizztbsd (Remote host closed the connection) 23.49.57 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.50.48 # pamaury: hm, tried it. mixed results on my clip+. with the first patch it fails sometimes as expected. with the second, doesn't fail as much but two times it "froze", as in it's stuck in main menu (which is weird) or the "usb cable screen". the menu cannot be navigated and kernel says "device not accepting address 19, error -32". Cannot reproduce it now :/ 23.51.35 # strange, it never happened to me 23.51.48 Join drizztbsd [0] (~quassel@unaffiliated/drizztbsd) 23.52.09 # wodz: is it possible that your MAS cleanup patch breaks hwcodec sims? 23.53.00 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 23.55.38 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 23.56.17 Quit krabador (Ping timeout: 276 seconds) 23.58.13 # hondza: can you report your experiment in FS ? 23.58.35 # sure 23.58.47 # thanks