--- Log for 01.01.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 19 hours ago 00.04.33 Quit feisar- (Ping timeout: 240 seconds) 00.17.08 Quit preglow (Changing host) 00.17.08 Join preglow [0] (thomj@rockbox/developer/preglow) 00.19.03 Quit froggyman (Quit: Ex-Chat) 00.23.06 *** Saving seen data "./dancer.seen" 00.24.29 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 00.29.26 Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) 00.43.35 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 00.46.11 Quit BHSPitMonkey (Remote host closed the connection) 00.47.59 # what's the maximum chunk size a PCM driver needs to be able to handle? 00.57.43 Quit Battousai_ (Changing host) 00.57.43 Join Battousai_ [0] (~bryan@gentoo/developer/battousai) 00.57.46 Nick Battousai_ is now known as Battousai (~bryan@gentoo/developer/battousai) 00.59.01 # can i safely assume that we'll only ever do 16bit stereo PCM transfers? 00.59.08 # some other drivers seem to rely on that as well 00.59.46 # hm, "16 bit samples, and an even sample count" fits it better 01.00.53 Quit kadoban (Ping timeout: 240 seconds) 01.04.43 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 01.13.19 Join anewuser [0] (anewuser@unaffiliated/anewuser) 01.18.39 Quit robin0800 (Remote host closed the connection) 01.20.50 Join evilnick_ [0] (~evilnick@cpe-24-193-43-185.nyc.res.rr.com) 01.23.58 Quit evilnick (Ping timeout: 260 seconds) 01.25.08 Nick evilnick_ is now known as evilnick (~evilnick@cpe-24-193-43-185.nyc.res.rr.com) 01.25.17 Quit evilnick (Changing host) 01.25.17 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 01.37.43 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 01.40.56 Quit Keripo (Ping timeout: 276 seconds) 01.43.51 Quit JesusFreak316_ (Ping timeout: 240 seconds) 01.52.13 # seems like there are only two drivers left before we can start testing: LCD and ATA 01.52.53 # linuxstb: would you like to have an updated patch? or are you sure you won't have time anyway? 01.53.55 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 02.10.13 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 02.12.41 Quit factor (Remote host closed the connection) 02.13.36 Join factor [0] (~factor@75.108.68.114) 02.16.18 Quit kadoban (Ping timeout: 240 seconds) 02.23.07 *** Saving seen data "./dancer.seen" 02.27.48 Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 02.57.30 Part toffe82 03.03.35 Quit DerPapst (Quit: Leaving.) 03.06.33 Join feisar- [0] (jljhook@irkki.fi) 03.26.32 Quit GuySoft (Ping timeout: 265 seconds) 03.27.06 Join merbanan [0] (~banan@c-94-255-218-107.cust.bredband2.com) 03.28.42 # Buschel, I'll be up and awake in about 9 hours and should be ready to test then. Sorry for the 24 hour delay. 03.30.31 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 03.32.53 Quit Keripo1 (Ping timeout: 276 seconds) 03.39.07 Join GuySoft [0] (guy@bzq-79-181-14-229.red.bezeqint.net) 03.44.19 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 03.45.00 Quit designate72 (Read error: Connection reset by peer) 03.56.18 Quit GuySoft (Ping timeout: 240 seconds) 03.59.42 Quit Keripo (Ping timeout: 255 seconds) 03.59.45 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 04.06.08 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 04.09.32 Join GuySoft [0] (guy@bzq-109-64-3-227.red.bezeqint.net) 04.19.49 Quit GuySoft (Ping timeout: 240 seconds) 04.20.16 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 04.21.09 Join Barahir [0] (~jonathan@frnk-590fde3e.pool.mediaWays.net) 04.22.31 Quit Keripo1 (Ping timeout: 265 seconds) 04.23.09 *** Saving seen data "./dancer.seen" 04.24.39 Quit Barahir_ (Ping timeout: 276 seconds) 04.26.36 Join PurlingNayuki [0] (~PurlingNa@113.97.120.123) 04.35.04 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 04.35.22 Quit Keripo (Ping timeout: 240 seconds) 04.44.12 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 04.52.12 Quit amiconn (Disconnected by services) 04.52.14 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.52.19 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.53.19 Quit pixelma (Disconnected by services) 04.53.21 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.53.23 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.54.03 Join GuySoft [0] (guy@bzq-79-176-24-241.red.bezeqint.net) 04.55.03 Quit TheSeven (Ping timeout: 260 seconds) 04.58.39 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.59.27 Quit bmbl (Quit: Verlassend) 05.04.34 Quit [Saint] (Ping timeout: 265 seconds) 05.04.38 Join [Saint] [0] (S_a_i_n_t@203.184.1.94) 05.07.27 Quit GuySoft (Ping timeout: 248 seconds) 05.10.47 Part PurlingNayuki 05.17.47 Quit Rob2222 (Ping timeout: 240 seconds) 05.17.57 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 05.19.23 Quit Keripo1 (Ping timeout: 240 seconds) 05.26.26 Join GuySoft [0] (guy@bzq-79-182-8-155.red.bezeqint.net) 05.35.02 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 05.36.28 Quit Keripo (Ping timeout: 260 seconds) 05.47.28 Quit GuySoft (Ping timeout: 264 seconds) 05.49.57 Join GuySoft [0] (guy@bzq-79-182-8-155.red.bezeqint.net) 05.59.56 # Happy New Year! 06.13.05 Quit parafin (Ping timeout: 276 seconds) 06.14.07 Join parafin [0] (parafin@paraf.in) 06.16.38 Quit GuySoft (Ping timeout: 250 seconds) 06.23.12 *** Saving seen data "./dancer.seen" 06.23.42 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 06.24.31 Quit Keripo1 (Ping timeout: 255 seconds) 06.27.48 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 06.29.20 Quit dfkt_ (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 06.30.09 Quit Keripo (Ping timeout: 240 seconds) 06.31.57 Join GuySoft [0] (guy@bzq-79-182-25-133.red.bezeqint.net) 06.32.50 Quit parafin (Remote host closed the connection) 06.35.03 Join parafin [0] (parafin@paraf.in) 06.38.20 Join dfkt [0] (dfkt@unaffiliated/dfkt) 06.39.15 Quit mortalscan (Ping timeout: 246 seconds) 06.42.31 Join mortalscan [0] (~mortalsca@109.169.55.155) 06.44.17 # <[Saint]> soap: ping? 06.45.09 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) 06.45.22 # <[Saint]> Is FS#11830 v7 the ATA patch in the iPod Colour build you built for me? 06.45.50 # <[Saint]> I'm compiling my own builds, and I'd like to keep testing it for testings sake. 06.49.38 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 06.51.04 Quit Keripo1 (Ping timeout: 276 seconds) 06.53.15 Quit GuySoft (Ping timeout: 246 seconds) 06.53.51 Join GuySoft [0] (guy@bzq-79-182-25-133.red.bezeqint.net) 06.55.53 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 07.15.54 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 07.16.14 Quit balintx (Remote host closed the connection) 07.16.32 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 07.20.09 Quit fyrestorm (Client Quit) 07.21.29 Quit mortalscan (Ping timeout: 240 seconds) 07.27.59 # <[Saint]> TheSeven: Ping? 07.29.16 Quit GuySoft (Ping timeout: 276 seconds) 07.30.49 Quit balintx (Remote host closed the connection) 07.32.24 Quit parafin (Ping timeout: 276 seconds) 07.34.33 Join parafin [0] (parafin@2001:470:1f0b:81::1) 07.40.50 Join GuySoft [0] (~guysoft@bzq-79-177-17-243.red.bezeqint.net) 07.43.35 Join dfkt [0] (dfkt@unaffiliated/dfkt) 07.46.26 Quit CaptainKewl (Ping timeout: 255 seconds) 07.46.37 Quit [Saint] (Read error: Connection reset by peer) 07.47.17 Join [Saint] [0] (S_a_i_n_t@203.184.2.91) 07.49.46 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 07.51.49 Quit Keripo (Ping timeout: 260 seconds) 07.53.48 Join Horscht [0] (~Horschti@p5DD57A5A.dip.t-dialin.net) 07.53.48 Quit Horscht (Changing host) 07.53.48 Join Horscht [0] (~Horschti@xbmc/user/horscht) 07.54.47 Quit dfkt (Read error: Connection reset by peer) 07.56.29 Quit Horschti (Ping timeout: 260 seconds) 08.01.52 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 08.03.23 Quit Keripo1 (Ping timeout: 240 seconds) 08.10.51 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 08.12.46 Quit Keripo (Ping timeout: 250 seconds) 08.18.50 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 08.23.13 *** Saving seen data "./dancer.seen" 08.41.15 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 08.44.01 Quit Keripo1 (Ping timeout: 276 seconds) 08.47.42 Quit GuySoft (Ping timeout: 246 seconds) 09.01.20 Quit shai (Read error: Connection reset by peer) 09.03.30 Quit Keripo (Ping timeout: 240 seconds) 09.04.55 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 09.08.24 Join GuySoft [0] (guy@bzq-79-182-41-135.red.bezeqint.net) 09.16.03 Join Keripo1 [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 09.17.20 Quit Keripo (Ping timeout: 255 seconds) 09.31.45 Quit kadoban (Read error: Operation timed out) 10.23.17 *** Saving seen data "./dancer.seen" 10.35.29 Quit BHSPitMonkey (Remote host closed the connection) 10.40.03 Quit evilnick (Ping timeout: 255 seconds) 10.57.54 Join Buschel [0] (~chatzilla@p54A3AE62.dip.t-dialin.net) 10.59.12 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 11.03.03 Join stoffel [0] (~quassel@p57B4B9E7.dip.t-dialin.net) 11.05.22 # [Saint]: you had the chance to test FS11843 v11 on one of your ipod color's ? or are the devices still in the locker ;) 11.06.54 # [Saint]: gnip 11.17.30 Quit Buschel (Ping timeout: 264 seconds) 11.21.11 # <[Saint]> TheSeven: I noticed a change to enable USB interrupts snuck into the piezo patch, was that intentional? 11.21.35 # probably not 11.21.41 # <[Saint]> I'm rebuilding my tree, and I couldn't figure out why I was getting HID enabled Nano2G builds. ;) 11.23.23 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 11.28.31 Join robin0800 [0] (~robin0800@genld-218-239.t-mobile.co.uk) 11.45.09 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 11.45.48 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 11.47.24 Quit Keripo1 (Ping timeout: 240 seconds) 11.48.00 # * TheSeven decides to do some ATA driver rework 11.55.51 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 11.56.07 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.56.09 Quit robin0800 (Read error: Connection reset by peer) 11.59.41 Quit bluebroth3r (Ping timeout: 276 seconds) 12.02.25 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.14.07 # New commit by 03mt (r28937): Fix FS#11845 by rejecting unknown header signatures in the audio stream info block. RALF uses a different header signature than ('.', 'r', 'a', 0xfd). ... 12.14.58 # * TheSeven throws http://pastie.org/1421150 into the room 12.15.14 # do we want such a change in general? 12.15.25 # did i get all the endianness logic right? 12.15.47 # who wants to test it? 12.16.28 # r28937 build result: All green 12.21.14 Quit DerPapst (Read error: Connection reset by peer) 12.21.42 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 12.23.23 *** Saving seen data "./dancer.seen" 12.32.33 # * TheSeven will probably just commit it if nobody bothers to even reply :) 12.48.11 # It is new year's day, I suspect there are a few sore heads around (including mine) 12.50.59 Join Buschel [0] (~chatzilla@p54A3A80E.dip.t-dialin.net) 13.02.08 Join MethoS- [0] (~clemens@134.102.106.250) 13.24.38 Join thomasjfox [0] (~thomasjfo@dslb-088-066-093-071.pools.arcor-ip.net) 13.25.04 # happy new year to everyone 13.36.26 # same to you and all the others :) 13.42.40 # anyone get a change to look at the bug i said about ? 13.42.48 # * TheSeven wonders if Torne or some other ATA guru is awake :) 13.45.39 Join Topy [0] (~Topy44@f048144099.adsl.alicedsl.de) 13.49.24 Quit T44 (Ping timeout: 240 seconds) 14.04.16 # 1/1/11 14.10.36 # kugel: As you usually read the IRC logs, happy new year to you and I've fixed the database duplication issue for the application. 14.10.45 # soap: does FS#11843 v11 work for you? 14.11.14 # I'm about to test 14.12.50 # 94.0 and 376.0 were the numbers for v10 with FORCE FIFO WAIT commented out IIRC. 14.13.33 Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info) 14.16.19 # 83.5 / 335.0 at 80Mhz, Buschel 14.16.44 # and I caught a brief glimpse of screen corruption of a splash when launching the plugin. 14.17.15 # yes, corruption of all in test_viewports 14.17.57 # hmm, is this also happening with v09? 14.18.14 # was about to build 10, let be roll back again and check 14.21.43 # test-viewports looks fine, splashes look fine with v09 14.22.38 # ok, will take a look at this after lunch 14.23.27 *** Saving seen data "./dancer.seen" 14.33.10 Quit JdGordon| (Ping timeout: 255 seconds) 14.38.04 # soap: this takes back the change I think is the cause -> http://pastie.org/1421298 14.38.12 # can you verify? 14.38.21 # yes 14.46.09 # 83.5 / 335.0 fps boosted (YUV) with this one (v11), hmm, a minor issue with test_viewports. Might be something i missed previously with stock 14.47.12 # ok, now just change the following manually in target\arm\ipod\lcd-color_nano.c 14.47.23 # line 316, change to "#if 1" 14.47.52 # line 320, change to "addr += (LCD_WIDTH)/2; 14.47.59 # in a sec, rebuilding v09 to verify the test_viewports odd hang isn't somehow related to v11 14.48.04 # ok 14.48.52 # just those two changes? 14.48.55 # yes 14.50.24 Join dantje [0] (~dvg@HSI-KBW-091-089-103-221.hsi2.kabelbw.de) 14.51.22 Quit feisar- (Ping timeout: 246 seconds) 14.55.03 # ok the slight viewport glitch verified as having existed with v09, so ignore that as it isn't new. V12 = 83.5 and 335.0 again. 14.55.58 # did you already compile and test with local manual changes? 14.56.17 # that's what I'm calling v12 14.56.27 # so yes. 14.57.08 # ok, then this issue was dumb error :) 14.57.24 # (which is good as this can be easily fixed) 15.01.14 # so, this should work properly now -> http://pastie.org/1421328 15.08.17 # v13 = 83.5 / 335.0 fps again, no text corruption. 15.16.30 # good, updates FS#11843. now I only need a verification for iPod color (by [Saint]?) 15.18.06 Join feisar- [0] (jljhook@irkki.fi) 15.22.31 Quit feisar- (Ping timeout: 240 seconds) 15.22.33 Quit DerPapst (Quit: Leaving.) 15.23.04 Quit parafin (Quit: So long and thanks for all the fish) 15.23.14 Join parafin [0] (parafin@paraf.in) 15.33.30 Join domonoky [0] (~Domonoky@agsb-5d87f087.pool.mediaWays.net) 15.33.34 Quit domonoky (Changing host) 15.33.34 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.40.16 Quit kevku (Ping timeout: 260 seconds) 15.43.07 Join CaptainKewl [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 15.56.25 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 16.04.41 # soap: another refactoring (simplify loops for YUV updates) -> http://pastie.org/1421416 16.04.52 # soap: do you still have got some time for this? 16.05.20 # just a few more minutes, I need to go to the gym 16.05.47 # then let's hope there is no issue ;) 16.09.23 # v14 result: 84.0, 335.5 16.10.08 # I forget which one now was "too fast for [Saint]'s ipod screen", but it was still significantly faster. 16.10.08 # movies play fine? 16.10.49 # I believe so. We need a new test file. 16.10.52 # soap: v10 was too fast 16.11.12 # you have the sample videos (elephants dream)? 16.11.14 # the current encodes of elephant's dream have too many artifacts. 16.11.33 # fine for legacy testing of fps, but worthless for looking for flaws. 16.11.45 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 16.12.05 # well, if the code is not working properly the artifacts would be obvious and distracting 16.12.30 # like the screen shots you've sent me in the past days 16.12.53 # I hear you and know what you mean, but I consider the current state "obvious and distracting"! ;) 16.18.13 # you're talking of elephants dream in general and not of the last patch? 16.18.25 Join CaptainKwel [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 16.20.31 Quit CaptainKewl (Ping timeout: 260 seconds) 16.22.33 Quit CaptainKwel (Ping timeout: 240 seconds) 16.23.31 *** Saving seen data "./dancer.seen" 16.27.18 Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) 16.27.25 Join mortalscan [0] (~mortalsca@109.169.55.155) 16.29.34 # yes, sorry, did not intent to confuse. I find the Nano screen irritating to watch because of its poor off-axis response and I find (at least the) Rockbox Nano encodes of Elephant's Dream very distracting to watch carefully because of the significant artifacting. 16.29.44 # s/intent/intend/ 16.30.09 # understood 16.53.13 Join evilnick [0] (~evilnick@cpe-24-193-43-185.nyc.res.rr.com) 16.59.13 Join robin0800 [0] (~robin0800@genld-219-241.t-mobile.co.uk) 16.59.25 Quit mortalscan (Ping timeout: 240 seconds) 17.00.58 Quit robin0800 (Remote host closed the connection) 17.01.27 Join robin0800 [0] (~robin0800@genld-217-241.t-mobile.co.uk) 17.19.27 Quit dantje (Quit: Ex-Chat) 17.19.49 # Saint: (for the logs) can you please check what lcd_type your iPod color has? this can be seen in the debug menu under "View HW info" 17.21.34 Quit factor (Ping timeout: 255 seconds) 17.24.00 Join mortalscan [0] (~mortalsca@109.169.55.155) 17.25.24 Join factor [0] (~factor@75.108.68.114) 17.26.26 Quit Buschel (Ping timeout: 260 seconds) 17.29.40 Quit robin0800 (Remote host closed the connection) 17.30.05 Join feisar- [0] (jljhook@irkki.fi) 17.34.11 Quit feisar- (Ping timeout: 240 seconds) 17.35.10 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 17.41.02 Quit GuySoft (Ping timeout: 265 seconds) 17.45.40 Quit t0rc (Remote host closed the connection) 17.53.27 Join GuySoft [0] (~guysoft@109.64.46.137) 18.02.14 Quit DerPapst (Quit: Leaving.) 18.02.38 # * TheSeven starts playing around with an iPod Classic Rockbox build! \o/ 18.03.04 # it's still locking up before I see anything on the LCD 18.03.15 # but I'm pretty sure I'll figure out the cause soon 18.03.25 Quit krazykit (Ping timeout: 255 seconds) 18.04.33 Quit evilnick (Quit: Leaving) 18.05.44 # hm, it reaches main() 18.05.49 Join Buschel [0] (~chatzilla@p54A3BE96.dip.t-dialin.net) 18.10.37 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 18.23.34 *** Saving seen data "./dancer.seen" 18.24.36 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.29.39 # * TheSeven swears at Buschel's code 18.44.22 Quit Keripo (Quit: Leaving.) 19.06.08 # TheSeven: what is so bad with it? 19.06.54 # if i knew that 19.07.12 # something in your LCD asm locks up on the ipod classic, and i have absolutely no idea why 19.07.36 # i bet the root cause isn't in your code though :) 19.07.46 # which function in detail? and copied from which driver? 19.07.54 # best update the status on the home page then :D 19.08.02 # lcd_write_line from nano2g 19.08.37 # the C code is comparable for both targets? 19.10.05 # the LCD controller core seems to be identical, just at a different AHB address 19.10.11 # something wrong with the alignment? 19.10.16 Quit Slasheri (Ping timeout: 260 seconds) 19.10.17 # no idea 19.10.38 # is there working c code available? 19.10.40 # with caches enabled, it seems to lock up at "ldr lr, [r2, #0x1C]", with caches disabled it doesn't lock up but doesn't influence the lcd contents either 19.10.57 # yes, but that C code works in a totally different way 19.11.19 # http://websvn.freemyipod.org/filedetails.php?repname=freemyipod&path=%2Fembios%2Ftrunk%2Ftarget%2Fipodnano3g%2Flcd.c 19.11.40 # (that's using DMA) 19.12.45 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 19.14.29 # ok, totally different approach... 19.14.43 # yep, i just offload it all to the hardware 19.15.45 # why not keep using DMA for the classic port? 19.16.07 # because we would need to block for DMA completion anyway 19.16.34 # rockbox can't handle double buffering right now, neither for audio nor video 19.16.43 # for audio i used some hack, but for video it isn't that easy 19.17.09 # you're right 19.18.57 # are you sure the lock up is in "ldr lr, [r2, ...]" and not in the command before? 19.22.36 # i branched out of the code immediately before and after that instruction, and if the branch was before it, it worked (and resetted the SoC), if it was after the instruction it didn't seem to be reached 19.27.37 # strange 19.28.23 # well, as the caches had an impact, I'd expect something with my MMU setup to be wrong 19.28.36 # but even with a disabled MMU it still doesn't show anything on the LCD 19.47.20 Quit mortalscan (Quit: Leaving) 19.52.19 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 19.59.16 Join bertrik [0] (~545056ba@giant.haxx.se) 20.00.47 Quit xavieran (Ping timeout: 255 seconds) 20.05.01 Quit stoffel (Ping timeout: 240 seconds) 20.10.39 Join leavittx [0] (~lev@MS-10-112.dyn-ip.SPb.SkyLink.RU) 20.11.23 Quit liar (Quit: Leaving) 20.14.25 Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) 20.23.37 *** Saving seen data "./dancer.seen" 20.25.11 # New commit by 03Buschel (r28938): Save some binsize in LCD driver of iPod nano 2G. No impact to speed. 20.28.30 Quit factor (Quit: Leaving) 20.28.51 Join factor [0] (~factor@75.108.68.114) 20.28.54 Quit factor (Read error: Connection reset by peer) 20.31.16 Quit leavittx (Ping timeout: 276 seconds) 20.35.29 Quit bug2000 (Read error: Operation timed out) 20.37.01 Join bug2000 [0] (~bug@DSL212-235-89-173.bb.netvision.net.il) 20.37.01 Quit bug2000 (Changing host) 20.37.01 Join bug2000 [0] (~bug@unaffiliated/bug2000) 20.39.32 Join leavittx [0] (~lev@MS-10-112.dyn-ip.SPb.SkyLink.RU) 20.54.02 # New commit by 03Buschel (r28939): Higher precision for test_mem plugin. 20.56.01 # r28939 build result: All green 20.58.04 Quit leavittx (Ping timeout: 276 seconds) 21.00.09 Join leavittx [0] (~lev@MS-10-112.dyn-ip.SPb.SkyLink.RU) 21.01.58 # YEEEEEAAAAAHHH!!!! 21.02.20 # * Buschel wonders if this a good or bad sign 21.02.20 # rockbox logo on the screen, followed by "ATA error: -22\n\nPress ON to debug" 21.02.29 # good sign :) 21.03.09 # what was the trick? 21.03.12 # however only if i replace your ASM code with something more stupid 21.03.30 # for (y = y0; y <= y1; y++) 21.03.30 # for (x = x0; x <= x1; x++) 21.03.30 # s5l_lcd_write_data(lcd_framebuffer[y][x]); 21.03.33 # this does the trick 21.03.51 # the old code 21.04.07 # isn't it? 21.04.12 # basically yes 21.04.21 # i can't see any obvious difference though 21.04.57 # well, the alignment is critical. x must be even and width must be a multiple of 4 to use my asm code 21.05.08 # but i'll probably go after the ATA error first, no that i have a working lcd driver to print debug info 21.05.29 # Buschel: if that doesn't hold true, it should at least do *something* 21.05.36 # the LCD didn't show any reaction at all 21.05.44 # but this should not lead to a crash like you described... 21.08.55 # hmm, and s5l_lcd_write_data polls for (STATUS & 0x10) each pixel and not for (STATUS & 0x08) each 4 pixels. 21.09.25 # * Buschel spots an error in a comment 21.10.20 # New commit by 03Buschel (r28940): Fix comment. 21.11.32 # however, you're able to proceed with other stuff now 21.12.15 # r28940 build result: All green 21.14.16 # Buschel: but even if that fifo check doesn't work right, i would at least expect some garbage on the screen 21.14.33 # the CPU is running with caches disabled, so at a ridiculously slow speed 21.14.41 # you could remove the fifo checks altogether and it wouldn't matter 21.15.03 # if the FIFO registers work the same... 21.19.10 # what does the S5L8702 do, if you access a 2-byte aligned address with a 4-byte read? 21.27.42 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 21.32.07 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 21.33.31 Join telliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com) 21.33.37 # Buschel: IIRC unaligned loads with ldr generate an error, while unaligned loads with ldm just return the lower aligned word on armv5 21.34.55 # ok, would also not explain TheSeven's experiences (as your 2nd case is relevant)... 21.35.44 # depends on some cp15 setting IIRC 21.36.29 # if you have alignment faults on it faults, otherwise it returns the wrong data rotated 21.37.10 # you get the wrong data whether you se ldr or ldm 21.37.31 # Torne: what do you think about the ATA changes btw? 21.37.36 # http://pastie.org/1421150 21.38.25 # seems sensible.. 21.38.57 # i might have broken it in some places wrt. endianness 21.39.42 # especially line 365 of the paste 21.40.23 # er, i can't really have a thorough look atm, just passing throgh :) 21.44.03 # hey 21.44.24 # could any of the devs have a quick look at a patch I'd like to upstream? 21.45.30 # It's really small 21.45.34 # http://repo.or.cz/w/maemo-rb.git/commitdiff/eeb6d692b209f2a6f74de05e863f5d8af999c218 21.50.11 # thomasjfox: I'm not sure if I like the general idea 21.50.52 # gevaerts: What do you prefer? 21.51.11 # gevaerts: Right now we have non-working menus in the app build 21.51.16 # I know 21.51.35 # Or non-working picture flow menu entries 21.51.42 # But I think that technically a rockbox build with non-working credits is a license violation 21.52.24 # As long as this is a temporary issue, I don't think people will have a problem with that, but this patch seems to make that a permanent "feature 21.52.27 # " 21.52.50 # so maybe credits should be a core function instead of a plugin? 21.52.56 # there are other targets without plugins, too 21.53.44 # i thought we wanted at least some plugins on app builds (e.g. fft, etc) 21.54.08 # Well, as long as it's "plugins don't work yet", I think that's fine. And not having games is also fine 21.54.23 # But "no plugins" as an end goal isn't 21.54.39 # "No plugins" is not the desired end goal, that's for sure 21.54.49 # I already got them working somewhat, it's still very broken 21.55.09 # hm. our arm-elf-eabi-gcc isn't exactly clever 21.55.31 # So the question is "Do we want in-progress ports to be able to look complete?"? 21.55.37 # Buschel, latest YUV = 84.0 / 335.5 / no corruption 21.55.42 # My personal answer would be "Why? 21.55.44 # " 21.56.07 # The more it looks working, the better? 21.56.16 # Is it? 21.56.28 # I don't want to show features to the user which just crash. Users will click on it 21.56.30 # If it *looks* finished, why would anyone try to fix the remaining bits? 21.56.53 # Does it crash? 21.56.53 # soap: v16 ? 21.57.08 # The picture flow menu outputs a very ugly error message 21.57.15 # Same for the credits screen 21.57.41 # What does it say? A "plugin error" splash? 21.57.56 # Let me just re-enable plugins ;) 21.59.32 # Buschel, yes, v16 21.59.42 # "failed to load /opt/rockbox/lib/rockbox/rocks/demos/pictureflow.rock" 22.00.04 # right 22.00.30 Quit xavieran (Ping timeout: 255 seconds) 22.00.37 # hmm 22.00.48 # soap: thanks! I now _really_ need Saint for further testing on iPod Color/Photo... I would like to submit this stuff :) 22.01.53 # I can see your point for the pictureflow thing, but I'd say a "DISABLE_PICTUREFLOW_INTEGRATION" define in config/application.h (possibly #ifdeffed) is cleaner 22.02.19 # I don't think having the Credits menu item go away is a good idea though 22.02.29 # (even if it gives an error) 22.02.59 # Ok. Almost the same idea: Keep the patch like it is except for the credits part? 22.04.51 # Idea for the future: Provide a minimal non-plugin credits screen 22.05.32 # Why? What's wrong with having it as a plugin? 22.05.57 # So we have a credits screen if for whatever reason the plugins are disabled? 22.06.10 # Just as an alternative 22.07.06 # Disabled plugins should really be a temporary state while developing, just like e.g. having no LCD driver yet 22.07.49 # (note: "enabled plugins" is not the same as "we build all games") 22.08.38 # That is true, see this one (which is hopefully temporary): http://repo.or.cz/w/maemo-rb.git/commitdiff/67edd22cca548e677e24f0b8237717e7a21d3e2f 22.09.16 # You're allowed to reorder entries if that makes things more readable :) 22.10.43 Quit thomasjfox (Remote host closed the connection) 22.11.05 Join Ogham [0] (~Ogham@unaffiliated/ogham) 22.11.19 # Hi all, I don't suppose anyone here owns a Sansa Clip+ ? 22.11.53 # just ask any questions 22.13.11 # Just a random query, my Clip+ makes a loud creaking noise when I hold/press the right hand corner lightly.. I was just wondering if other people have noticed this on theirs, or if mine may have been damaged in transit? 22.13.33 # AlexP: did you see http://www.rockbox.org/irc/log-20101230#23:12:42 ? 22.13.35 Join xavieran [0] (~xavieran@ppp118-209-79-106.lns20.mel4.internode.on.net) 22.14.33 # gevaerts: no 22.14.57 # gevaerts: But I'd say if it works, get it in, do a 3.7.2 and then that is probably the last before 3.8 22.15.04 # unless anything massive comes up 22.15.20 # bertrik: ping 22.15.20 # Ogham: I don't know what you mean by "right hand corner" since there's two corners on the right side, but neither of them make any loud noises when I squeeze lightly. 22.15.36 Join thomasjfox [0] (~thomasjfo@dslb-088-066-093-071.pools.arcor-ip.net) 22.16.16 Join Tim_Elliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com) 22.16.31 # Llorean: Oops, yes I meant to add 'bottom' to that, thanks for checking.. I'm not sure if I should return it or not, it works without any issue, rockbox is great on it :) 22.17.26 # I'm a little concerned about having my IE-8's plugged in if the unit has taken a beating! 22.18.46 # Ogham: just to clarify, does the case (i.e. the plastic) make this noise, or is it on the headphones? 22.19.33 Quit telliott (Ping timeout: 250 seconds) 22.19.36 # If it's in anything electrical, and you can return it, I think that's the best option. This is the sort of thing that may easily get worse over time 22.19.59 # gevaerts: Its the casing of the Clip+, just holding it there in normal use causes a nasty creaking sound and there is some movement.. 22.21.24 # another candidate for a 3.7.2 is FS#11830. it can be submitted with some proper nano1g-ifdefing to not touch other targets. 22.21.32 # other than that there does not seem to be anything wrong, but if Llorean does not notice the same thing.. I think I'll see if I can return it :( 22.22.19 # Buschel: that's not in trunk yet I think? 22.22.30 # gevaerts: http://repo.or.cz/w/maemo-rb.git/commitdiff/6fef275a8c20882ae3f10bc76f241ff84a2425b5 22.22.40 # Ogham: There's not really any movement in mine either. 22.22.43 # not yet. might submit this next week, if there are no side effects reported 22.23.41 *** Saving seen data "./dancer.seen" 22.23.45 # Llorean: So the whole thing feels pretty solid to you? 22.24.09 # Ogham: Yeah, no real give anywhere. 22.24.34 # Llorean: ah well, better see if I can get this one exchanged :( Thanks for checking for me! 22.24.35 # I mean the plastic flexes a little if I press down on the word "sansa" but that's not what you're talking about, I'm sure 22.24.43 # gevaerts: when would 3.8 most likely be branched off? 22.24.48 # anyone notice that none of the gigabeat players can be "ejected" in windows, but the sansa players can (when using rockbox USB)? 22.24.49 # why is that 22.25.19 # Buschel: See the Rockbox calendar! 22.25.37 Join wah_wah_69 [0] (~io@212.225.156.123) 22.25.46 # Buschel: https://www.google.com/calendar/embed?src=rockbox.calendar@gmail.com 22.26.10 # saratoga: the last few lines of firmware/usbstack/usb_storage.c 22.26.48 # AlexP: cool, didn't knwo about this 22.26.58 # Personally I think any drive that's not hotswap in rockbox itself shouldn't be marked as removable, but I seem to be the only one in the world to think that way 22.26.58 # Buschel, gevaerts: And yeah, I think FS#11830 should be OK, but it should go in trunk for a while first to check it all out :) 22.27.08 # Llorean: nope, just the bottom right corner, I'm guessing a clip inside is broken.. 22.27.10 # Buschel: I sent two emails to -dev about it! :P 22.27.15 # Hi everyone! I've just found that my player (packard bell vibe 300) uses 22.27.26 # Thanks again, have a good new year all :) 22.27.26 # crap this irc client 22.27.32 # gevaerts: well its nice to be able to unmount the disk easily in windows 22.27.40 # gevaerts: That makes sense to me. If you can't re-insert it without replugging the cable, don't mark it as "removable" basically? 22.27.46 Part Ogham 22.28.08 # saratoga: I can still safely remove hardware on my gigabeat, I just don't have an "eject" option in the right click menu. 22.28.20 # I mean my packard bell player seems to use portal player 5020, or at least has mi4 file with the name pp5020.mi4 on the system directory 22.28.20 # Well, that "removable" bit really is about the media, not the SCSI device 22.28.42 # Llorean: yes thats what i'm refering to 22.28.49 # I've open it as text 22.28.56 # SCSI hotswap (which USB basically provides) is really distinct for removable media drives 22.30.11 # It seems to use PP5020AF, the thing is I'd like to post about this in the forum, and I'm not sure where to post 22.30.27 # also, does the GBS charge off USB? 22.30.34 # yes 22.30.34 # Yes. 22.30.39 # but not if it's flat 22.30.46 # It has to be "on" to charge. 22.30.46 # it has to boot up successfully first 22.30.53 # Unlike the F. =/ 22.31.20 # wah_wah_69: a new thread in New Ports I'd say (unless there is an existing one, but I don't think so) 22.32.20 # gevaerts, I must be blind or something, I didn't notice that subforum 22.33.09 # I'm tempted to try the mi4 from iriver h10, there's no risk as long as I have a backup of the original mi4, right? 22.33.38 # Unless it is identical hardware it won't work 22.35.02 # it uses the same chip from portal player, 5020, maybe a different revision hence the AF ending in the text from the firmware 22.35.10 # and all the other hardware? 22.35.23 # And is everything connected up the same? 22.35.52 # And ... 22.36.10 # I'm not sure, haven't even tried to open it. 22.36.44 # it will only work if the player is literally identical apart from the plastics 22.37.04 # being similar makes it less work to do a port, but you still need to do a port 22.37.05 # thomasjfox: that (well, I'm looking at 229da89f31cbe13bf5b32e9ce559e9c27563105f..3fae73d38325395cb4a3512d37f0ffd72c676d71 now) looks reasonable. I'm still not sure about it (the entire HAVE_PLUGINS thing) though, but maybe I'm alone there... 22.37.05 # I'll make a post in the forum with as many details as I can about this player (vibe 300), i'll try to open it later 22.37.09 # wah_wah_69: do you have any experience with programming hardware devices? 22.37.19 # Yeah 22.37.38 # I'm finishing my degree in computer engineering 22.37.50 # then this should be a fun project 22.38.02 # but you've picked a really obscure device so you're probably on your own 22.38.44 # If you're lucky, it might be similar to the vibe 500? 22.39.49 # lets suppouse the vibe 300 bootloader is similar to the vibe 500, so its already known, and the portal player chip is well understood, apart from that what's left to figure out? all the remaning glue logic? 22.39.52 # gevaerts: Don't keep your mind occupied with HAVE_PLUGINS. In the end that patch is going to die, atleast for maemo 22.40.20 # thomasjfox: I hope so :) 22.40.20 # gevaerts: I'm just doing another binary .deb build with plugins enabled. If all goes well (doesn't crash/hang), I'll push it out soon. 22.40.26 # Nice 22.40.40 # People are really happy with rockbox on the n900 22.41.05 # Stuff like "Where should I send my firstborn?" is mentioned ;) 22.42.56 # gevaerts: Maybe I asked this before, do you own a n8xx device? 22.43.01 # I don't 22.43.11 # I'm wonderin how high the CPU usage might be 22.43.17 # I know petur has one though, and IIRC soap as well 22.50.45 # correct 22.51.20 # people on maemo.org are happy whenever the benevolent gods drop crumbs in their direction. ;) 22.52.24 # Well, only if you keep dropping crumbs 22.52.42 # As soon as you don't drop a crumb one week, you'll know what they *really* think :) 22.53.45 # soap: Would you have time to play around with the maemo port on a n8xx? 22.53.55 # I'll have a new build up in about 20min 22.54.05 # sure, If I can recall how to install apps on it! 22.54.10 # dpkg -i ;) 22.54.28 # I need to run an errand, I'll be back in about 90 minutes, I'll highlight you then. 22.54.58 # ok 22.58.13 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.14.40 # kugel: Seen my message in the irc log? ;) 23.14.53 # yep 23.15.41 Quit thomasjfox (Remote host closed the connection) 23.16.13 Join thomasjfox [0] (~thomasjfo@dslb-088-066-093-071.pools.arcor-ip.net) 23.17.36 # kugel: The app_* and sim_* wrapper layer leave room for improvement. The plugins have again trouble saving their config as they want to write to the "rocks" dir... 23.17.55 # kugel: Maybe we can unify the file functions? 23.21.54 # unify how? 23.23.09 # maybe have just one open function which does the /.rockbox/ path expansion? 23.23.24 # are there more than one? 23.23.43 # app_open calls sim_open which also does some kind of path transformation IIRC 23.23.56 # only on the sim though 23.24.40 # and android doesn't call sim_open() 23.24.45 Join tuxifier [0] (~ha@stgt-4d02de89.pool.mediaWays.net) 23.24.51 # kugel: Have a look at firmware/common/rbpaths.c 23.25.18 # For PLATFORM_SDL it also calls sim_open 23.25.34 # i mean sim_open() only transforms paths on the sim 23.26.50 # so get_sim_pathname() is not used if APPLICATION is defined 23.28.37 # right 23.29.14 # hmm. Anyhow, I manage to get the plugins running and they also need path translations as I could determine via strace 23.30.04 Join mortalscan [0] (~mortalsca@173-166-0-166-newengland.hfc.comcastbusiness.net) 23.30.30 # i know 23.31.13 # we thought some PLUGIN_DATA_DIR where plugins need write access could work 23.32.30 # so that would map to $(HOME)/.config/rockbox.org/rocks.data? 23.34.12 # soap: the n8xx build can be found here: http://simonv.com/rockbox/n8xx-rockbox_3.7.2maemo2_armel.deb 23.35.03 # New commit by 03jethead71 (r28941): Gigeabeat S: Reset DMA size info when stopping audio playback and recording transfers so that size remaing/peak buffer calls return 0/NULL when ... 23.36.58 # r28941 build result: All green 23.41.00 # thomasjfox: it's wrong to call it 3.7.2 imo 23.41.15 # kugel: I know. 3.7.1 wasn't right either 23.41.34 # kugel: Dunno how I can set svn version numbers with debian packaging 23.41.57 # So many things to fix, so little time :) 23.42.36 # can you run version.sh? 23.42.57 # I need to enter the version number manually into debian/changelog 23.43.19 # So I would need another script that automates debian packaging 23.43.33 Quit pamaury (Remote host closed the connection) 23.44.32 # 3.7.2 and 3.7.1 are equally wrong I think :) 23.45.06 Join leavittx_ [0] (~lev@MS-55-111.dyn-ip.SPb.SkyLink.RU) 23.45.32 # I'll see what I can do about version.sh for the next build 23.46.44 # btw: Would be nice to run "make veryclean" without a full build setup 23.47.12 # Took me a while to find out there are tools which don't get removed by "make clean" 23.47.15 # there are debhelper scripts to do svn/cvs/etc version numbering, i'm pretty sure 23.47.57 Quit leavittx (Ping timeout: 246 seconds) 23.48.59 # Though the svn # is wrong also as the maemo port contains code that is not yet in subversion :o) 23.49.11 # give it your own random one for now 23.49.40 # Implying it is either an existing release or a release that hasn't yet happened that it won't be in is not quite right :) 23.49.41 # A date-based one may be best 23.49.54 # yes, good idea 23.49.58 # Indeed 23.50.07 # Simple as that 23.51.46 Quit mystica555_ (Ping timeout: 265 seconds) 23.53.56 Join feisar- [0] (jljhook@irkki.fi) 23.56.52 # hmm 23.58.47 # I don't get it - got 2 identical sansa clip+ with rockbox r28932-101229 and two identical 16GB microSD cards