--- Log for 19.06.110 Server: hubbard.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 5 hours ago 00.00.23 # the home button bounces between main menu and file list... that's not too bad 00.01.15 # amiconn: home+select 00.01.27 # (i only found about it by reading the keymap file) 00.01.41 # Someone pls disable jakorasia-cg 00.01.49 # I don't really mind changes to the keymap, except I really do like volume in lists and have PLAY as up, and MENU as down 00.01.56 # It obviously claims to support sdl but doesn't 00.01.57 # done already, amiconn check the backlog 00.02.35 # * dfkt deleted all white markings on the clip+ with acetone, so there's no play or menu... all democratic :) 00.02.39 # bertrik: you mean UP as UP and DOWN as DOWN ;) 00.03.03 # yes, of course :) 00.03.59 # hum radio.c defines specific features for the keymap 00.04.36 # funman: you tried several times to get the synopsys datasheet for the usb controller right ? Who did you contact ? (I can always have a try) 00.04.54 # pamaury: iirc i just filled their web form 00.06.05 *** Saving seen data "./dancer.seen" 00.06.21 # * funman slaps JdGordon 00.06.26 # how do you scrobble the songs you listen to? 00.06.41 # i have it enabled, but i'm not sure how to submit to my last.fm account 00.06.47 # togetic: check the manual 00.07.33 Quit CGL (Remote host closed the connection) 00.08.18 # amiconn: that would vary between arm7 and arm9? ?? (you read my other remark that compiling it with arm9tdmicc actually gets rid of it?) 00.08.32 # Ever heard of gcc bugs? 00.08.55 # of course, you made it sound like a feature in your comment above. :) 00.09.01 Quit advcomp2019 (Ping timeout: 245 seconds) 00.09.02 # iiuc gcc is the thing hackers blame when they can't see bugs in their code :) 00.10.10 # maybe we're relying on some specific gcc behaviour that is really undefined 00.10.32 # togetic - http://scrob.paulstead.com/ 00.10.41 # Hrm, 'make clean' doesn't work properly 00.10.45 # arm9tdmicc actually makes a smaller bin though (~1700 bytes smaller) 00.10.46 # ...anymore 00.11.15 # This libs/skin_parser/ stuff stays 00.11.27 # eabi also triggers a bug in text_viewer, so far only on sansa ams ? 00.12.19 Quit Highlander (Quit: Quitte) 00.12.50 # funam: btw, who does gcc blame when they can't see bugs in their code? 00.12.51 Quit einhirn (Read error: Connection reset by peer) 00.13.25 # Then they have a meta-bug 00.13.57 # jhMikeS: binutils guys 00.14.08 # * jhMikeS thought they blamed hackers :\ (and the circle is complete) 00.14.13 # and binutils people blame gcc in return 00.14.35 # there is a circle but we're not part of it, so nothing is our fault :P 00.14.48 # New commit by 03funman (r26941): radio keymap: enable fuze/clip buttons ... 00.15.08 # dfkt: now center shows the list of presets so i think we can keep it that way (and home alternates between presets/scanning) 00.16.33 # r26941 build result: All green 00.17.03 # awesome, funman - now it's in line with the audio screen 00.17.22 # definitely more cohesive/coherent than before 00.20.25 # are we already beating OF battery life on AMSv2 ? 00.20.40 # SansaRuntime has no OF benches 00.23.16 # thanks funman and dfkt 00.24.07 # too bad the log wasn't present though 00.24.42 # togetic, once you enable scrobbling in rockbox, the log should be in your player's root 00.26.39 Join karlw [0] (cfd65326@gateway/web/freenode/ip.207.214.83.38) 00.27.26 # dfkt: that's what i read, but it wasn't there, so i'm guessing it was never enabled :\ 00.27.39 # though i recall enabling it, i went wrong somewhere 00.27.44 # * togetic shrugs 00.27.56 # Has anyone gotten Nano 5th gen to work? I know about the encrypted firmware. 00.28.17 # it's in settings > playback, and it's a simple on/off switch 00.28.59 # your files need to be tagged to work, it won't read file names 00.32.37 # ranma: *PANIC* ep1 OUT 0x80 (BNA) 00.32.59 Quit kugel (Read error: No route to host) 00.33.34 Join kugel [0] (~kugel@rockbox/developer/kugel) 00.33.35 # after writing rockbox.sansa and running 'sync' (sync never returned but the file was modified since i got a checksum error) 00.37.22 Part karlw 00.38.10 Quit GeekShadow (Quit: The cake is a lie !) 00.38.13 # New commit by 03amiconn (r26942): Build iPod 1st/2nd Gen with EABI (main build and bootloader verified working). 00.39.52 # r26942 build result: All green 00.42.34 Quit rob (Ping timeout: 276 seconds) 00.42.37 # New commit by 03funman (r26943): clip recording keymap changes, thanks to dfkt 00.42.42 # New commit by 03funman (r26944): ACTION_FM_QUICKSCREEN is unused 00.43.06 # S_a_i_n_t: you tested nano1g with eabi, didn't you ? 00.43.10 Quit ender` (Quit: Women and Cats will do as they please. Men and dogs had better get used to it. -- Robert Heinlein) 00.44.06 # r26943 build result: All green 00.45.56 # r26944 build result: All green 00.46.03 # New commit by 03amiconn (r26945): Tell the build system that iPod 1st/2nd Gen needs arm-eabi-gcc 4.4.4. Fix this for a bunch of bootloaders as well. 00.47.05 # scorche: Could you test EABI on your Nano 1st Gen? 00.47.43 # There are only 3 ipods still on old ABI: Nano 1st, Mini 1st and iPod 4th Gen 00.48.46 # * amiconn summons domonoky 01.00.09 Quit kugel (Ping timeout: 240 seconds) 01.05.47 # small write transfers work fine on clipv1 01.09.10 Quit bertrik (Ping timeout: 248 seconds) 01.12.22 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.13.08 Join bluebrother [0] (~dom@f053154000.adsl.alicedsl.de) 01.13.08 Quit bluebrother (Changing host) 01.13.08 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 01.14.00 # reading is fine: a full album at 2.14MBps, vs 0.78MBps for the OF 01.16.18 Quit bluebroth3r (Ping timeout: 240 seconds) 01.17.03 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 01.27.31 Quit kugel (Ping timeout: 240 seconds) 01.41.39 # amiconn: do you happen to have a build ready for me to load? 01.55.02 Quit stripwax (Quit: http://miranda-im.org) 02.04.24 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.06.06 *** Saving seen data "./dancer.seen" 02.10.16 Quit DataGhost (Ping timeout: 264 seconds) 02.16.56 Quit efyx (Remote host closed the connection) 02.20.42 # ranma: have you seen the comment in otgdev_ops.c:1186 about RDE ? 02.21.18 Quit kugel (Remote host closed the connection) 02.26.39 # New commit by 03funman (r26946): usb-drv-as3525: set bulk max packet size according to speed ... 02.28.55 # r26946 build result: All green 02.37.50 Join CaptainKwel [0] (~jason@207-237-113-115.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.38.31 Quit funman (Quit: free(random());) 02.48.41 Quit DerPapst (Quit: Leaving.) 03.06.04 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 03.09.10 Join powell14ski_ [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 03.12.02 Quit 50UAAFOUW (Ping timeout: 272 seconds) 03.15.06 Join CGL [0] (~CGL@190.207.202.226) 03.17.56 Quit powell14ski_ (Ping timeout: 265 seconds) 03.27.00 # I got an error on the wiki: 03.27.01 # Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information. 03.27.01 # exec failed: Mass Storage only 03.28.54 Join powell14ski [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 03.30.29 Join powell14ski__ [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 03.31.06 Join powell14ski____ [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 03.31.48 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 03.33.08 Quit powell14ski (Ping timeout: 252 seconds) 03.35.06 Quit powell14ski__ (Ping timeout: 265 seconds) 03.43.52 Nick powell14ski____ is now known as powell14ski_ (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 03.46.06 Quit steve|m (Ping timeout: 276 seconds) 03.49.19 Quit pamaury (Remote host closed the connection) 03.58.24 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 04.00.48 Join steve|m [0] (~steve@p4FD46122.dip.t-dialin.net) 04.06.10 *** Saving seen data "./dancer.seen" 04.09.24 Join Zigtown [0] (~Zigtown@CPE00259ce0fdb2-CM0014f8cc807a.cpe.net.cable.rogers.com) 04.15.36 Join Barahir [0] (~jonathan@frnk-590fd465.pool.mediaWays.net) 04.18.35 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 04.19.37 Quit Barahir_ (Ping timeout: 276 seconds) 04.28.47 Join Guest14828 [0] (~biteme@ashentech.broker.freenet6.net) 04.29.08 # * Guest14828 waves at room 04.29.26 # New commit by 03ranma (r26947): Comment on mps sizes 04.29.58 Nick Guest14828 is now known as AzureSky (~biteme@ashentech.broker.freenet6.net) 04.30.57 # was wondering if anybody has reported that the current build for fuze v2 isnt detecting microsd cards 04.31.26 # r26947 build result: All green 04.32.40 # testing now 04.34.58 # New commit by 03ranma (r26948): Add mdelay 04.35.47 Quit amiconn (Disconnected by services) 04.35.50 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.35.50 Quit pixelma (Disconnected by services) 04.35.51 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.36.06 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.36.07 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.36.11 # New commit by 03ranma (r26949): Use mdelay 04.36.39 # r26948 build result: All green 04.38.26 # r26949 build result: 16 errors, 2 warnings (ranma committed) 04.39.14 # neat, it even tells you who to blame 04.39.20 # lol 04.39.37 # 47 still dosnt work with msd cards :/ 04.40.07 # trying the archive build 04.41.41 # if only i didnt have to wait for the OF to refresh the db to test the new builds :P 04.44.12 # no joy, have to use the build i have from a few days ago :( 04.52.14 # New commit by 03ranma (r26950): Include system-target.h for mdelay 04.53.51 # r26950 build result: 16 errors, 2 warnings (ranma committed) 04.55.45 # Huh? Now that looks like a build system hicup? C200v2 bootloader builds fine without warnings here now. 04.56.16 # duno, i still cant get the fuzev2 to see microsd cards on any current build 04.57.28 Quit Topy44 (Ping timeout: 260 seconds) 04.57.35 # thankfully i have a backup of an old build (first one i installed) that works....... 04.58.33 Quit TheSeven (Ping timeout: 245 seconds) 04.58.50 Join Topy44 [0] (~topy@my.fastsh.it) 05.02.19 # Ah, no, I'm stupid 05.02.40 # why? 05.02.47 # and did you break msd card support :P 05.04.00 Join TheSeven [0] (~TheSeven@stgt-5f709c5d.pool.mediaWays.net) 05.04.00 Quit TheSeven (Changing host) 05.04.00 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.04.23 # New commit by 03ranma (r26951): Of course there's no mdelay on c200(v1), so just use udelay 05.05.25 Part AzureSky 05.05.59 # r26951 build result: All green 05.06.20 Join Guest14828 [0] (~biteme@ashentech.broker.freenet6.net) 05.06.30 Nick Guest14828 is now known as AzureSky (~biteme@ashentech.broker.freenet6.net) 05.06.54 # AzureSky: No, I don't think I broke msd card support ;) 05.07.27 Join saratoga_ [0] (9803c20d@gateway/web/freenode/ip.152.3.194.13) 05.08.48 # if i hotload the latist builds i can still see cards, but if u upgrade to latist builds fully it dosnt work :( 05.09.22 # a few people have mentioned that 05.10.24 # if i had any programing skill i would try and fix it myself, but best i can do is edit text based config and script files :( 05.11.22 # you could figure out which build broke it 05.11.25 # no older builds are in the archive, and i didnt even think to test and backup each build that worked :( 05.12.08 # if u got a link to prebuilts i got zero issue testing, Im pretty sure it was a build from today that did it :/ 05.12.28 # you'd have to build them yourself 05.13.01 # again, no skills or tools to do that :( 05.13.17 # then just wait for someone else to fix it 05.15.00 # somebody should make a note for people who are trying to rockbox their fuzes not to use a current build, If i check my flashdrive I have the older working version on there 05.17.54 # if its not fixed someone will make a note 05.21.13 # ok, i have a weird one for you 05.21.25 # it seems if you reload from a .sansa file the msd card appears 05.22.15 # could it be some kind of either display issue or an issue with load order or the like? 05.24.00 Quit saratoga_ (Quit: Page closed) 05.29.14 # ok well, if anybody heres working on this, i have r26951 installed and have reloaded from its .sansa file and IT WORKS, but having to reload from a file every time i turn the player on is a bit of a pain :( 05.36.16 Quit Zigtown (Remote host closed the connection) 05.39.38 Join saratoga_ [0] (9803c20d@gateway/web/freenode/ip.152.3.194.13) 05.41.40 Join funman [0] (~fun@rockbox/developer/funman) 05.48.13 Quit Topy44 (Ping timeout: 260 seconds) 05.49.47 Join Topy44 [0] (~topy@my.fastsh.it) 05.51.58 # New commit by 03funman (r26952): FS#11417 by Joe Balough: fix audio/tuner on philips hdd6330 05.53.31 # r26952 build result: All green 05.59.00 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 06.00.13 # ranma: any chance you could test last patch of fs#11297 and get a backtrace if/when it crashes ? 06.00.18 # (on clip+) 06.00.57 # hey funman :) 06.01.17 # i suppose there could be something wrong with memory when we are switching pclk and some bits are lost - no other idea atm 06.01.20 # hi 06.01.52 # if nobody has told you, there is a bug with fuzev2 and sd cards in newer builds 06.02.12 # did you post about it on the forum? i just tested last build and it works fine here 06.03.02 # yeah, i did, and for some reasion the last build i tested only shows the sd card after you reload from the sansa file after the player boots 06.03.11 # which sansa file ? 06.03.24 # r26951 06.03.45 # the rockbox.sansa 06.04.00 # ah, it doesn't detect the card if i boot with it inserted 06.04.04 # but insertion works as intended 06.04.06 # dropped it in root of player, and if i "play" it after boot the cards accessable 06.04.29 # it dosnt detect if i remove and reincert the card here,not sure why 06.04.40 # apparently 906 still worked (aib forums post) 06.04.48 # hmm no it works fine when booting with the card inserted 06.05.45 # now i see the card is present (in disk info) but not mounted 06.05.57 # check debug -> disk info -> microSD 1, is it present? 06.06.06 # if i downgrade to r26865 it works here and somebody on abi forums had it work for them with r26906,but if i go with a build from today, it just dosnt list it in files 06.06.13 *** Saving seen data "./dancer.seen" 06.06.24 # let me reboot to see what it says 06.07.13 # mine shows 0-sd 06.07.27 # with an 8gb ridata microsd card 06.07.58 # it shows either 'Not Found!' either 10 lines or so of details on the card 06.09.29 # duno, in view disk info it just shows m-03, 0=sd 06.10.30 # that's microSD '0' = internal storage; press right button 06.11.06 # on 1 sec 06.12.00 # what value did you want, it shows it there but cant access it via file browser 06.12.12 # Blocks 06.12.40 # 0x00ed8000 06.13.02 Join hebz0rl [0] (~hebz0rl@dslb-088-067-205-154.pools.arcor-ip.net) 06.14.30 # 8gb card, right? 06.14.35 # yeah 06.14.45 # class6 06.14.47 # then the card works but it's not mounted 06.15.19 # http://forums.rockbox.org/index.php?topic=25099.0 <- perhaps the same problem 06.15.21 # and if i load that rockbox.sansa from files list it appears and is accessable 06.16.23 Quit CaptainKwel (Quit: Ex-Chat) 06.16.28 # you say r26906 works for sure? 06.17.15 # for somebody else, ican tell you that for me it probbly worked(till i updated to a build from today it worked for me) for me build r26865 works if i downgrade to taht 06.17.39 # can't spot anything obvious in the log 06.19.01 # r26926 im pretty sure worked as well (im almost serten i loaded that one and it worked) 06.20.26 # hm perhaps r26933 or r26937 06.22.12 # if you have a copy of earlier builds i can test them, i would build my own but 1. no tools to do it, 2. no skills to do it 06.22.56 # http://www.rockbox.org/wiki/SimpleGuideToCompiling 06.26.08 Quit Topy44 (Ping timeout: 260 seconds) 06.29.21 # installing cygwin 06.36.21 Join Topy44 [0] (~topy@my.fastsh.it) 06.38.39 # storage is much faster on fuzev2 than on fuzev1 despite the lower pclk 06.39.06 # duno, never had a v1, all the fuzes i have had and gotten people have been v2 06.39.15 # hm however i'm measuring speed with µSD on fuzev1 - but iiuc it should be faster than internal 06.40.00 # so, once this finely gets setup what files should i download to start with? 06.40.10 # AzureSky: the wiki has all the info 06.40.43 Quit Topy44 (Ping timeout: 260 seconds) 06.42.10 # so you have a couple fuzes i take it 06.43.04 Join Topy44 [0] (~topy@my.fastsh.it) 06.55.12 # New commit by 03funman (r26953): sd-as3525*: handle aligned transfers without memcpy() ... 06.56.38 Part AzureSky 06.57.06 # r26953 build result: All green 07.02.49 Join Guest14828 [0] (~biteme@ashentech.broker.freenet6.net) 07.10.06 Quit binaryhermit (Quit: Leaving) 07.13.24 Quit Topy44 (Ping timeout: 260 seconds) 07.14.10 # 906 works lestatar sent me a backup of his working install and it works fine 07.15.14 # if r26906 works and not r26951 there's not much commits to test : and i pointed 2 which affect this player particularly 07.16.01 # grr.. i only tested storage diff on fuzes, and it seems to fail on clipv1 07.16.26 # yeah, accdently closed my irc window, and im still waiting on cygwin to fully install 07.16.49 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 07.17.42 Join Topy44 [0] (~topy@my.fastsh.it) 07.19.47 Quit Horscht (Ping timeout: 265 seconds) 07.22.27 # playing music crashes on all clips 07.23.48 Nick Guest14828 is now known as AzureSky (~biteme@ashentech.broker.freenet6.net) 07.24.24 # hm and on fuzev2 too .. ? 07.24.25 # ouch, well im letting cgywin download the 33 build 07.24.49 # no, havent tested on fuze, all the files are slowly downloading now tho 07.25.01 # despite my net being pretty fast :P 07.36.41 # gcc4.5 -flto seems not to like -mthumb 07.37.27 # that folder type ../tools/configure which will bring up a list of all possible devices 07.37.39 # just gives me an error 07.37.45 # nu such file or directory 07.37.50 # no* 07.38.37 # you built the cross compiler already? 07.39.34 # just did what the steps to compile said to do, downloaded form the svn already...... 07.40.12 # ok i see, will work on that now 07.40.49 Quit Dark_Rak3r (Ping timeout: 264 seconds) 07.41.42 Join dfdf [0] (~dfdf@bb119-74-164-27.singnet.com.sg) 07.43.26 # Hi i got a problem detecting a particular micro sd card after updating rockbox 07.43.30 # anyone knows what to do? 07.43.31 # r26945 WorksForMe 07.43.37 # funman: ^^ 07.44.06 # the microsd card works in OF though and other micro sd cards work with rockbox 07.44.12 # plays, sees the microsd, etc. 07.44.23 # hmm? 07.44.28 # dfdf, same problem here working on a fix 07.44.30 # maybe it needs to be fscked dfdf ? 07.44.38 # well tracking down where problem came from 07.44.42 # it took me some boots to notice the problem: card is present in disk_info but not mounted 07.44.58 # i did a disk check but still the same 07.45.13 # dfdf: if you go in debug -> disk info -> microSD 1 the card info is listed? 07.45.13 # so the problem lies with the recent release? 07.45.23 # hmm. that rev, 26945, it did for me. 07.45.26 # debug in the player? 07.45.31 # dfdf: you didn't tell which player you have btw 07.45.36 # oh sorry 07.45.37 # clip+ 07.45.45 # yes in the player (debug menu) 07.45.50 # ver 26946 07.46.03 # hmm 07.46.20 # i don't see any microsd in diskinfo 07.46.29 # oh wait 07.46.42 # the title is microSD 0 07.46.45 # bootloader i have on it is r26845 07.50.48 Quit robin0800 (Remote host closed the connection) 07.51.18 # the working microsd gives abt the same thing in debug>diskinfo 07.51.33 # press right to see microSD 1 07.53.04 Quit Topy44 (Ping timeout: 260 seconds) 07.54.29 # oh right 07.54.32 # yeah its there 07.55.21 # New commit by 03funman (r26954): fix r26953: use physical address for DMA buffer, also for IRAM ... 07.55.43 Join Topy44 [0] (~topy@my.fastsh.it) 07.56.58 # r26954 build result: All green 08.01.34 # gcc 4.5 -flto reduces ram usage by 18.2kB on clipv2, but i cheated a bit : the compiler adds something in ARM.exidx/ARM.extab sections, which is apparently exception tables (for C++?) 08.03.18 # hmm 08.05.10 Join Buschel [0] (~~andree@p54A3E330.dip.t-dialin.net) 08.06.16 *** Saving seen data "./dancer.seen" 08.09.59 Quit Buschel (Ping timeout: 260 seconds) 08.11.23 # New commit by 03funman (r26955): make clean: delete lib/ directory 08.12.51 # r26955 build result: All green 08.16.12 # no one has figured out the dock pins on the Fuzev2, correct? 08.16.19 # err dock detect pin that is 08.17.16 # saratoga: i'm not aware if anyone did it 08.17.55 # /media/bordel/rockbox/apps/codecs/mpa.c:422:30: warning: comparison between ‘enum mad_error’ and ‘enum ’ 08.18.10 # the good thing with using different gcc versions is they show you new warnings ;) 08.23.07 # since both of those enums have the values explicitly set as unsigned integers, its a little silly 08.24.19 # funman, after following all the directions i new got a bunch of command not found errors......think i need a copy of a working ect/profile file 08.24.42 # is the command gcc? 08.24.43 # AzureSky: just set your PATH to include the path to cross compilers 08.28.13 # PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/sh/bin:/opt/m68k/bin:/opt/arm/bin:$PATH 08.28.13 # export 08.28.25 # thats what is in there as the guide says.... 08.34.59 Quit xavieran (Read error: Operation timed out) 08.41.50 # ah we patch gcc for no exceptions & multilib support 08.42.04 Join stoffel [0] (~quassel@p57B4C7C4.dip.t-dialin.net) 08.48.34 Join xavieran [0] (~xavieran@ppp118-209-156-98.lns20.mel6.internode.on.net) 08.49.33 Join petur [0] (~petur@rockbox/developer/petur) 08.56.24 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.59.30 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.59.47 # 24kB down on clipv2 with gcc 4.5 flto + binutils cvs 09.00.15 # apparently flto generates buggy thumb asm 09.00.52 # links fine without the option 09.01.14 # but clipv2 doesn't boot ;) 09.03.38 # funman: my clip+ refuses to play mp3's from internal memory using r26953-100619 09.03.50 # data abort at 3000AEE8 09.03.52 # clipv1 neither: black screen, and clipv2 stuck at logo 09.03.56 # topik: svn up 09.04.09 # r26954 fixes it ? 09.04.20 # yes, the log even tells so ;) 09.04.40 # how unlucky for me to pick the one build before then :) 09.05.22 # out of 5 targets, i only had one which didn't show this bug, and i tested playback only on that one 09.05.52 # murphy chuckles no doubt 09.09.20 Quit dfdf () 09.10.17 # playback restored. lovely 09.16.46 Join Dark_Rak3r [0] (~DarkRak3r@cpe-67-244-88-91.nyc.res.rr.com) 09.20.08 Join bimbel [0] (~Miranda@unaffiliated/bmbl) 09.20.37 Quit bmbl (Ping timeout: 258 seconds) 09.37.46 Join Kitr88 [0] (~Kitar_st@BSN-182-93-71.dial-up.dsl.siol.net) 09.39.46 Quit Kitar|st (Ping timeout: 240 seconds) 09.42.16 Quit Topy44 (Remote host closed the connection) 09.42.41 Quit Kitr88 (Ping timeout: 276 seconds) 09.47.46 Join Kitar|st [0] (Kitar_st@BSN-142-70-88.dial-up.dsl.siol.net) 09.52.53 # funman: why the slappage? 09.53.40 # JdGordon: you removed SANSA_FUZE_PAD from radio code in a recent-ish commit 09.53.59 # oops? 09.55.21 # too late, i slapped you already :) 09.58.39 Join Rob2222 [0] (~Miranda@p4FDCA641.dip.t-dialin.net) 10.00.27 Quit kramer3d_ (Ping timeout: 276 seconds) 10.02.16 Quit Rob2223 (Ping timeout: 240 seconds) 10.04.44 # bieber: I havnt checked tag_table recently but it should be 5 compulsary ints... x,y,width,height,font... colours are in a seperate tag now 10.05.58 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 10.06.20 *** Saving seen data "./dancer.seen" 10.06.30 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 10.06.33 # New commit by 03funman (r26956): minesweeper: bugfixes / code improvements ... 10.08.11 # http://forums.rockbox.org/index.php?topic=25107.0 <- new port request, but with money promised 10.08.11 # r26956 build result: All green 10.09.17 # whats with people and their addiciton to apple products then bitching about the restrictions apple products have? 10.15.48 # AzureSky: i don't know but this is probably off-topic here, better go to #rockbox-community 10.16.24 # ok funman, did a compile with help of a friend 10.16.56 # but not seeing a folder that has same contents as the .rockbox folder that comes from the download pages 10.17.23 # you can run 'make zip' and unzip the created rockbox.zip on your player 10.21.34 # got it, testing 33 now 10.23.38 # 33 works fine!!! 10.23.43 # you can try also make PREFIX=F: install but i'm not sure if that works on cygwin 10.24.07 # AzureSky: ok, next possible commit is r26937$ 10.24.08 # -$ 10.24.18 # yeah gotta svn that 10.25.25 # is it ok to break bookmark file format ? 10.26.21 # bugger, themeeditor doesnt compile in svn :( 10.28.04 # it errors out 10.28.55 # S_a_i_n_t: can you check FS#11404 on nano2g ? 10.29.01 # funman: Hmm, since when does 'make PREFIX=... ' exist? 10.29.31 # funman: probably not that nice, especially without warning (re. bookmark format) 10.29.35 # Btw, on cygwin the equvalent would be (if the target is drive F:) make PREFIX=/cygdrive/f 10.30.03 # funman: also, what for? 10.30.11 # pixelma: the format is broken : FS#11388 10.32.05 Join ender` [0] (krneki@foo.eternallybored.org) 10.32.35 # afaik ; is not forbidden in FAT32, otherwise he couldn't have a folder name that way. The others you mentioned are and you can't have these on Rockbox targets anyway 10.32.59 # sorry, misread 10.33.45 # i took the list of forbidden chars from VLC, i suppose it's valid 10.34.10 # funman: but even if you fix this, a warning for a few days would be appropriate IMO. 10.35.08 # which folder how? 10.35.12 # not sure if i'll do anything else about this problem 10.35.32 # i'll let someone else make the decision 10.36.27 # amiconn: now we just need a make bininstall so i don't copy rockbox.XXX in the player's root instead of .rockbox/ and wonder why my changes have no effect 10.36.52 # That doesn't answer my question 10.37.19 # well, that's right. 10.37.52 # If make PREFIX= just means it will use the target as a build root, it won't do any good 10.43.50 # New commit by 03funman (r26957): don't parse features.txt when not needed 10.43.55 # New commit by 03funman (r26958): new bininstall rule to install rockbox binary only 10.45.23 # r26957 build result: All green 10.46.19 # New commit by 03funman (r26959): make bininstall rule depend on the binary 10.46.59 # r26958 build result: All green 10.48.29 Join DerPapst [0] (~Alexander@p4FE8FF72.dip.t-dialin.net) 10.48.36 # r26959 build result: All green 10.52.13 # i wonder about this forum post : our rules say 'no requests' but they don't talk about paid offers 10.52.15 Quit GeekShadow (Quit: The cake is a lie !) 10.53.14 # perhaps kugel can make some extra $ from this 10.55.27 Join Jaykay [0] (~chatzilla@p5DC57AA7.dip.t-dialin.net) 10.59.48 Join Luca_S [0] (www-data@giant.haxx.se) 11.05.29 Join piggz [0] (~piggz@89.243.102.220) 11.07.21 Join mitk [0] (~mitk@chello089078013092.chello.pl) 11.07.23 # uhm... the as3525v2 set_cpu_frequency patch does no longer apply cleanly 11.08.01 # Luca_S: you're still using it for all this time and without crashes? 11.08.07 # yes 11.11.45 # i just synced the patch, don't hesitate to add your experience on the task 11.12.10 Quit Horschti (Quit: Verlassend) 11.12.11 # thank you, i'll test it over the weekend 11.15.28 # bluebrother: ping 11.16.18 # hav you already tried to compile the arm-eabi-compiler for darwin? 11.16.20 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 11.19.12 # Stummi: it works on 10.5.8 but not on 10.6 apparently 11.19.21 Quit funman (Quit: free(random());) 11.19.59 # hm 11.22.49 # just to check: the debug > view hw info menu is not updated to reflect the changes in PLL setup? 11.23.15 Join flydutch [0] (~flydutch@host110-154-dynamic.14-87-r.retail.telecomitalia.it) 11.24.28 # uhm.... jewels crashes on startup 11.24.41 # latest svn + cpu frequency 11.25.04 # i'll try with plain svn 11.26.25 # funman, confirmed its 37 that kills it 11.27.47 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 11.30.17 # mmm jewels works fine with plain svn 11.31.05 Join thefirstM [0] (~quassel@cpe-174-098-240-006.triad.res.rr.com) 11.31.55 # Luca_S, we did increase the default CPU speed a bit last night, from 240 MHz to 248 MHz (now it's exactly the same as as3525v1 and gives better playback rate error) 11.31.59 # microsd dosnt work with 26937 and up without a live reload of the firmware(rockbox.sansa) 11.32.56 # and thats with each boot 11.33.48 # bertrik, it crashed yesterday too, i filed a bug on fs but since it wasn't the only patch applied it wasn't very useful - today's svn works fine, but with FS 11297 it panics (data abort) every time I start jewels. Also pictureflow just freezes. 11.33.50 # im dropping back to 33 now 11.34.24 # maybe this could shed some light on what's wrong with the cpu freq patch? 11.35.36 # just so you know, (funman and the rest of you), had to get a buddy to remote in to get cygwin working properly but It seems its the changes in 26927 that are causing the microsdhc cards to not auto mount/detect :( 11.40.36 # SHDC still works fine for me on my clip+ with svn 26959. SVN 26927 was a change in USB, I don't know how this would affect microsdhc 11.41.27 # 37* 11.41.54 # the card dosnt auto mount and wont mount after boot on the fuzev2 11.42.35 # u can reload firmware by "playing" the rockbox.sansa after boot and the microsdhc card works after that but thats a bit of a pain..... 11.42.53 # http://svn.rockbox.org/viewvc.cgi?view=rev;revision=26937 11.43.29 # uhm funman, I think I spotted an error in the cpu freq patch 11.44.17 # that could be the problem with my fuze and its microsdhc card detection couldnt it? 11.44.20 # FCLK_FREQ is set to DRAM_FREQ / 1 in clock_target.h, i.e. 41333334, but in the patch it's tested against 40000000 11.45.15 # AzureSky: I'm not a RB developer, I just happen to be able to read C and I'm trying to solve a crash with my player - not uSD related, sorry 11.45.23 Join chrissavery [0] (~chris@ppp-61-90-109-99.revip.asianet.co.th) 11.45.39 # i never tested the games with later builds :/ 11.46.20 # 26933 works fine, 26937 dosnt :( 11.46.43 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 11.48.45 # hi. just checked out r26959 and it won't build. it spits out some msg about "arm-elf-eabi-gcc: not found". I guess this is some compiler switch over but there is nothing about it in the dev docs. I tried to rebuild using rockboxdev.sh but it spits out a msg about needing "makeinfo". So what to do to convert working old dev environment to new one that works? 11.49.55 # install the texinfo package for makeinfo (at least that what it's called on ubuntu), run rockboxdev.sh again and select 'e' (for eabi) 11.50.05 # u need to re-run the setup for cygwin and get the arm-elf-eabi-gcc off the rockbox server(we had to) 11.50.36 # will try texinfo then. thanks. I did try makeinfo package but one doesn't exist. 11.52.01 # appears to be working so far. thanks again. 11.52.21 # JdGordon, how hard would it be to add a radio signal strength indicator to the fms? 11.53.08 # Something similar to the volume icon in the wps, but showing something like an antenna with a couple of bars next to it 11.55.40 # not hard at all 11.57.48 # There is already a patch that adds a radio property for the signal strength for nearly all tuner chips. I guess we would just need a tag for it to retrieve this property and display a number or select a bitmap from a strip. 12.00.12 # chrissavery: also, please remove the old toolchains before re-running rockboxdev.sh 12.00.41 Quit mitk (Quit: Leaving) 12.00.45 # having those in the PATH during compilation of the new toolchains will make things go crazy afterwards 12.01.14 # ah, didn't do that. which directories need deleting for that? 12.02.13 # find /usr/local|grep arm-elf 12.03.57 # (and also for the other architectures of course, in case you have those toolchains installed) 12.04.06 Quit piggz (Remote host closed the connection) 12.04.08 # is there a list of which targets have moved to eabi so far ? 12.04.20 Join mitk [0] (~mitk@chello089078013092.chello.pl) 12.04.25 # topik: have a look at /www/buildserver/builds 12.04.56 # chrissavery: that's arm-elf, arm-elf-eabi (will be caugt anyways), sh-elf, m68k-elf, mipsel-elf 12.05.49 # caught* 12.06.03 # bertrik: as ling as there is a nice way to get a percrntage value (or some min/max) it is about 5 lines for the skin code 12.06.21 *** Saving seen data "./dancer.seen" 12.06.24 # im a bit hesitant to add skin stuff now though 12.06.51 # TheSeven: ok. cleared that stuff out. not sure i got it in time as it had already started compiling the new stuff. will soon see. thanks. 12.07.04 # thanks TheSeven 12.07.20 # * TheSeven suggests killing and re-starting rockboxdev.sh just to make sure 12.07.55 Join Buschel [0] (~~andree@p54A3D824.dip.t-dialin.net) 12.08.18 # we don't exactly know what's going on, but I'd suspect it already happens during ./configure of the new gcc/binutils 12.08.59 # righto. will do. 12.12.42 Quit stoffel (Ping timeout: 265 seconds) 12.14.39 # JdGordon, the patch for RSSI (received signal strength indication) in the tuner drivers currently return dBuV (logaritmic scale based on microvolts), not a percentage, and there's no hard defined min or max either 12.16.45 # we could change that of course, or maybe just assume a fixed range that works with most tuners 12.22.06 # A little late...but yes, I can report that Nano1g is fine with eabi 12.22.14 # (funman asked about this earlier) 12.23.59 # JdGordon, where are the fms tags handled? 12.26.02 # oh I see, in skin_tokens.c 12.26.17 Join dfkt [0] (dfkt@unaffiliated/dfkt) 12.26.49 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 12.28.09 Join halmi [0] (~netbook@80-123-47-14.adsl.highway.telekom.at) 12.29.48 # bertrik: yeah. to make it work in a bar you meed to look at draw_progressbar in skin display.c 12.30.08 # ypu nees a secind tag type for thw bar 12.31.30 # Errrmmm...if someone pointed me to what I needed to change, or was nice enough to make up a diff, I'd be happy to confirm/deny FS#11404 12.31.46 # * S_a_i_n_t apologises for being awol all day. 12.32.30 # clip+ has no AA in features but has PictureFlow plugin enabled. Is it bug or by intention? PictureFlow flickers and freezes occasionally on clip+. 12.33.14 # That is intention IIUC 12.34.30 # I think AA would look terrible on the clips if it was small enough to keep the rest of the WPS info oncreen also. 12.34.49 # It doesn't look great in pictureflow as is. 12.35.03 # yeah, but PictureFlow looks terrible also 12.35.09 # *on-screen 12.35.35 Quit hebz0rl (Ping timeout: 260 seconds) 12.35.36 # yeah, but pictureflow is a plugin, not one of the main screens ;) 12.35.47 # choosing to use it is one thing, forcing it another. 12.36.02 # pixelma: I've found Ondio build I made for you. gcc: sh-elf-gcc (GCC) 4.0.3 (rockbox patch #1) 12.39.26 # S_a_i_n_t: Using PFlow on a clip* is some kind of desperacy I think. 12.40.18 # there are a couple of patches that make it vastly better IMO, which should possibly be considered for inclucion into SVN 12.40.28 # * S_a_i_n_t looks. 12.40.39 # FS#11380 12.40.51 # aha...there's the man himself. ;) 12.41.06 # S_a_i_n_t, the PCM driver has support for 11, 22, 44, 88 kHz. I don't know what exactly is meant with "do not work" in FS#11404 12.41.35 # that was off the top of my head so hope it's right - patch for Clip+ PF improvements. 12.42.24 # bertrik: Near as I can tell, apparently sound is vastly improved by forcing 44kHz, but I have no idea what to modify to confirm this. 12.42.39 # I can confirm however, that rockboy/doom sound awful. 12.43.02 # chrissavery: No. It's FS#11380 - Keys not mapped properly in Recording Screen (Sansa Clip+) 12.43.35 # * chrissavery goes to look 12.44.10 # funman changed the recording keymap: http://svn.rockbox.org/viewvc.cgi?view=rev;revision=26943 12.44.44 # ah, yes, it's FS#11300 12.45.11 # has combined patch for reflection and mono. 12.48.10 # can someone tell me if funman's commit regarding parsing of features.txt coul break the automatic generation of UseOptions for the manuals from it? 12.48.36 # that'd be a big bonus for the clips IMO, can you put up a screenshot somewhere chrissavery? 12.48.43 # (or do you not have the target?) 12.48.43 # I'n only able to find out by testing 12.52.55 # S_a_i_n_t: I don't have any Clip variants. I just tested in USim and it doesn't even show the same as real. The person who has screen grabs from real clip is VagueRant. He has posted on FS about it and could probably provide a good screen shot. He did post one but just to show a problem. 12.53.27 # I see. 12.53.43 Join pixelma_ [0] (~pixelma@rockbox/staff/pixelma) 12.55.10 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 12.56.49 # ok, seems to be working still 13.00.42 # chrissavery: for what it's worth - pictureflow was and is still not able to start playback from itself on the hwcodec players. Since no-one worked on this, the integration doesn't make much sense there. (Not blaming you but the change could have been discussed a bit before committing, I direct that at the committer mainly) 13.00.52 # TheSeven: looks like my build with new toolchain finished. Thanks again. 13.02.42 # pixelma: sorry, I didn't know about that. What players are hwcodec? I suppose it should exclude the integration chgs for those targets. I only own a Fuzev2. 13.03.17 # all the supported bitmap Archoses 13.10.30 Join stoffel [0] (~quassel@p57B4C7C4.dip.t-dialin.net) 13.11.15 Join hebz0rl [0] (~hebz0rl@dslb-088-067-205-154.pools.arcor-ip.net) 13.15.41 Quit chrissavery (Remote host closed the connection) 13.16.33 Join chrissavery [0] (~chris@ppp-58-9-188-34.revip2.asianet.co.th) 13.20.17 Quit xavieran (Ping timeout: 240 seconds) 13.25.58 # PictureFlow on clip+: r26959 -> http://www.datafilehost.com/download-d59e9fa4.html and r26959 + FS#11300 pictureflow-reflection-mono-3.patch -> http://www.datafilehost.com/download-c96168a4.html. Both are terrible or I'm doing sth wrong. 13.27.53 Join mischasworld [0] (~quassel@p5B2131F3.dip.t-dialin.net) 13.28.45 # mitk: that's not a general picturflow problem (and the ability to run it) but the greylib just doesn't work nicely on the Clips' OLED display - looks ok-ish on other monochrome screens 13.31.49 # the feature is about being able to show album art in the WPS which doesn't use the greylib and hence doesn't work on monochrome targets at all (has been mentioned somewhat already but maybe this info is a bit more in detail) 13.33.18 Quit liar (Quit: ...) 13.33.55 # mitk: I found your info about the Ondio build now (needed to read the logs a bit as I have some trouble with my IRC client currently). Can you give me the exact size of the ajbrec.ajz too? I wonder if I misremembered or if there is more to it 13.35.19 # pixelma: thanks for explanation. I'll then wait for greylib improvements. Your Ondio build -> http://www.datafilehost.com/download-62197c0e.html 13.36.35 Join MethoS- [0] (~clemens@134.102.106.250) 13.36.44 # thanks 13.37.38 # * S_a_i_n_t suggests screendump for pictureflow screenshots... 13.37.57 # (assuming the Clips have this feature of course...) 13.39.10 # errr... greylib screenshots off target won't give you any helpful results 13.39.37 # clip's oled screen has too fast refresh rate for greylib to work? 13.39.59 # * S_a_i_n_t facepalms. 13.40.03 # It is hard to show flickering on jpg 13.40.05 # Yes, thanks for the reminder. 13.40.06 # yeah, well it works but doesn't look good 13.40.33 # it doesn't work well with cheating the eye ;) 13.40.34 # (and the screen update rate isn't fast enough?) 13.41.39 # btw, why does clip's screen always look like it's blinking (even with maximum contrast enabled)? 13.42.29 Join fml [0] (~chatzilla@p5DD2E08A.dip.t-dialin.net) 13.42.43 Quit amiconn (Remote host closed the connection) 13.42.43 Quit pixelma (Remote host closed the connection) 13.42.47 # Hello. Why aren't manuals built? Are they broken? 13.42.48 Join ubuntu-nathan [0] (~eeepc904@200.142.160.182) 13.42.52 # Hi all! 13.42.55 # The refresh rate isn't too fast (or too slow), it's just that the pixels turn on and off instantaneously, while on LCD they tend to fade in and out 13.42.58 Join pixelma [0] (quassel@rockbox/staff/pixelma) 13.43.02 # * ubuntu-nathan is back 13.43.02 Join amiconn [0] (quassel@rockbox/developer/amiconn) 13.49.06 # * fml pokes the build masters and asks them to look at the manual builds (which don't happen) 13.51.59 Join kugek [0] (~kugel@g231105037.adsl.alicedsl.de) 13.53.20 Part chrissavery 13.55.21 Quit kugek (Client Quit) 13.55.21 Quit stripwax (Quit: http://miranda-im.org) 13.58.15 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.59.42 Quit flydutch (Quit: /* empty */) 14.04.45 Quit MethoS- (Remote host closed the connection) 14.06.23 *** Saving seen data "./dancer.seen" 14.06.42 Join pamaury [0] (~quassel@p5DDEE84B.dip.t-dialin.net) 14.06.42 Quit pamaury (Changing host) 14.06.42 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 14.06.43 Join LionCub [0] (www-data@giant.haxx.se) 14.09.25 Quit Buschel (Ping timeout: 272 seconds) 14.10.17 Quit fml (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 14.12.48 Quit kugel (Read error: Connection reset by peer) 14.14.15 # just wanted to point fml to the mailing list where a similar thing about the voices was mentioned... of course he's gone already 14.16.04 # Funny how we have player-specific i2c addresses for some i2c devices. It's actually the i2c controller in the player that is different, not the i2c device. 14.21.14 Quit LionCub (Quit: CGI:IRC (EOF)) 14.25.53 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.40.21 # I know this is unsupported, but I am trying to compile the EABI toolchain with GCC 4.5 instead of 4.4. But I get this error: "checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES." Does anyone know why that happens? I have checked the config.log, but there isn't anything useful in there. 14.51.41 # AlexP: S_a_i_n_t: pixelma: kugel: anyone else who cares: From what I remember from IRC conversations, and the code, and such.... if viewports are used then the default viewport should only work to enable viewports, images and text should not be drawn 14.52.10 # fwiw, they are. 14.52.16 # (drawn) 14.52.48 # they being what? images or text? 14.53.41 # I cant remember that 14.53.51 # bertrik: did you figure it out? I'm free now if you want help 14.54.26 # JdGordon: Both IIRC, images definitely. 14.54.47 # It should be allowewd to draw in the default vp, except in sbs 14.54.48 # JdGordon, I'm watching soccer now and after that will do some shopping, so no :( 14.55.05 # kugel: I'm of that opinion also. 14.55.37 Join chrissavery [0] (~chris@ppp-58-9-188-34.revip2.asianet.co.th) 14.55.39 # * JdGordon bases this alot on code comments like "/* don't draw anything into this one */" and skin_display.c linmes 1339-1343 14.55.55 # But, it didn;t bother me that I "couldn't" draw in the default viewport, as whatever was supposed to stop it didn't work. 14.56.10 # But, now I understand it...I have re-coded all my themes. 14.56.31 # (to stop breaking in future) 14.57.16 Quit Jaykay (Remote host closed the connection) 14.57.37 # JdGordon: Have you managed to figure out why drawing in the default viewport with other viewports defined *is* possible? 14.57.40 # just updated to r26959 and now it won't recognize SD card slot. it doesn't show up in Files browser even after several restarts, unplugs etc. 14.57.52 # S_a_i_n_t: broken code most likely 14.58.06 # I too recall conversations about viewports which support your belief that it indeed shouldn;t work. 14.58.25 # Only, I thought the change never happened. 14.58.49 # JdGordon: what you just said was what I remember being said in the beginning and I *think* I remember update problems or so if someone used the default vp this way. If you asked me I would always have told that but there are lot of working examples it seems and somehow my impression was that things changed back and forth so I'm not sure anymore (can't pinpoint any commits though) 14.58.55 # in fact I remember being told off by kugel for nearly changing behaviour to outright never go into these always hidden viewports (whihc the default is one) because it will break everything 14.59.23 # chrissavery: known bug 14.59.41 # * S_a_i_n_t seems to remember that discussion also. 14.59.50 # ok. just browsing irc log now. 14.59.53 # (re: breaking stuff with default viewports) 15.01.12 # $ svn log -r17759 15.01.22 # that is the initial conditional viewports change 15.01.53 # there are also examples with pverlapping viewports which still seem to work somehow 15.02.04 # overlapping too 15.02.29 # yeppers, I actually abuse that behaviour in several themes. 15.02.35 # Drawing into the default vp always worked, thats why i needed to add a special case for the sbs. Drawing into the sbs default vp means drawing over the lists 15.03.09 # was overlapping viewports not supposed to work also? 15.03.21 Quit hebz0rl (Ping timeout: 252 seconds) 15.05.16 # z-order is ignored, and viewports arnt cleared except on full redraws or when becoming enabled 15.05.20 # it wasn't supposed to work. it just did :) we never explicitely disallowed it in the code IIUC 15.05.24 # so overlapping can work if you do it correctly 15.05.37 # overlapping viewports (shown at the same time) is not supposed to work or at least said to cause update problems too, that's what I remember 15.05.51 # quite often my viewports only partially overlap...and that seems to work fine. 15.06.15 # Also, I often just draw one on top of the other to simulate "clearing" the viewport. 15.06.20 # which works fine also. 15.07.20 # my view is that the default viewport should work the same in all screens, so they should do nothing but enable other viewports 15.07.39 # pixelma: That may have been the case at one point, but I know I have at least one WPS with overlapping viewports, and each viewport contains scrolling/dynamic content...and display is fine. 15.07.50 # which is probably how I'll make the new displayer work 15.07.54 # I do seem to remember update issues a long while ago though. 15.08.29 # JdGordon: That will break a lot of themes though... 15.08.35 # meh :) 15.08.43 # (but if it has to happen, it has to happen :/) 15.09.02 # that complicates making themes unecessarily imo 15.09.03 # sorry, but I don;t really share the "meh" sentiment :P 15.09.21 # I dont see how 15.10.25 # you can't make themes without vps 15.10.45 # yes you can 15.11.26 Quit simabeis (Quit: Lost terminal) 15.11.26 # as I understand it, it will be "don't draw in any vp", or "draw in any vp except the default" 15.11.33 Join simabeis [0] (~simabeis@lobmenschen.de) 15.11.51 # all this is only relevant when any viewports are used 15.12.02 # if none are then the default acts like normal 15.12.50 # what I don;t understand though, is why you *can't* draw in the default viewport if another viewport is enabled. 15.13.13 # I'm not saying it shouldn;t be that way, I just don;t get why it is/ 15.13.18 # s/is/should be/ 15.13.40 # IIRC the reason was because %xl, %x, %V, %vd etc all didnt eat the \n so the text wouldnt be on the right lines 15.14.08 # all "didn't", ...but now they do? 15.14.14 # also the comment... "conditionals clear the line which means if the %Vd is put into the default viewport there will be a blank line. To get around this we dont allow any actual drawing to happen in the deault vp if other vp's are defined" 15.15.02 # but, that isn't the case apparently. 15.15.33 # which means the code fell out of sync with comments... 15.15.58 # who added the comments, and when? 15.16.00 # indeed. so, I still don;t really get why we couldn;t draw in the default viewport. 15.16.10 # (if its only based on outdated comments) 15.16.17 # kugel: that comment was added in the initial conditional viewports commit 15.16.25 # by me 15.17.24 # * JdGordon thinks he sees what happened 15.17.29 # that comment was wrong in the first place then 15.17.44 # no it isnt 15.17.51 # or wasnt at that time 15.18.17 # iirc drawing into the default always worked 15.18.35 # I don't ever remember my code not acting right, and until yesterday it always drew in the default viewport. 15.18.52 # S_a_i_n_t: waay before you showed up :) 15.18.53 # I only changed it now out of fear of the new parser suddenly not accepting it. 15.18.59 # Aha. 15.19.51 # * JdGordon trolls through 25000 commit messages 15.20.50 # i know that at the time sbs was worked on, drawing into the default vp worked 15.20.53 # well, based on a theme I have lying around, I've been able to draw in the default viewport for at least 8 months. 15.21.02 # (a piss in the wind though probably) 15.22.01 # kugel: It is very likely a commit changed the conditional behaviour to not blank out those lines which means yes the comment is outdated 15.22.05 # I'm looking for that now 15.22.33 # I dont espeically like special handling for the default viewport in the sbs which will cause slight mess in the new renderer... 15.22.48 # but if I'm really outvoted and yelled down I'll see how cleanly it can be done 15.23.57 # i wouldn't object changing behavior iff it makes the code *a lot* cleaner 15.24.17 Quit petur (Quit: stairway to heaven) 15.24.18 # I'm not into yelling, and it isn't a democracy...but if it was based on a limitation that is no longer present I don't see any reason to not allow drawing in the default viewport. 15.24.47 # kugel: have a look at utils/newparser/skin_render.c .... so damn nice to walk the new skin tree :) 15.25.10 # actually, I guess it will need a "never drawn" flag there also so it wont be terrible 15.25.20 # but the default viewport in the sbs IS scanned for conditionals... 15.26.10 # that's how it's done currently I think, only few loc for the extra handling 15.26.28 # the default and ui viewports are not the same in the sbs... the default really should have the same behaviour everywhere 15.26.56 # in svn there is a hack to make sure the default is always hidden in the sbs but not in others which i dont like 15.27.32 Join piggz [0] (~piggz@89.243.102.220) 15.28.59 # it was working earlier, but now my ipod feels sluggish, and wont play anything 15.29.16 # well, it could be made so that it's not a hack (e.g. a parameter for the parser) 15.30.30 # kugel: also you'll be pleased to know that the skin buffer is going back to a much simpler allocation scheme :) 15.30.33 # * pamaury wonders if rockbox really powers off the clip+. 15.30.40 # pixelma: there doesn't appear to be a bug posted for Fuze not seeing SD cards. I'm reverting to r26906 reported to work but I'm just wondering if this will get attention without a bug posted? 15.32.08 Join efyx [0] (~efyx@82.225.185.146) 15.33.37 # JdGordon: cool! 15.34.36 # pamaury, what makes you think that? 15.34.39 # because of the way it parses now, we should be able to know before loading anything (except the .wps) if there is enough room for the skin 15.35.30 # bertrik: I don't know. It has been several times where I leave my clip+ at night, powered off and when I wake up, the battery is nearly empty :( Perhaps the battery is dead but that would be strange 15.36.24 # Oh weird, I have not noticed anything like that. Didn't a wakeup timer get implemented recently? Maybe that is causing trouble 15.37.53 # OK, I tihnk I might see how drawing in the defalut vp breaks things... it needs a conditional which changes frequently... the comment still seems to be valid 15.46.11 # * S_a_i_n_t was almost in bed ;) 15.46.16 # ...what does it break? 15.48.21 # the line will get cleared 15.48.27 # which may be visible or may not be 15.48.34 # depending on how the rest of the skin is done 15.49.10 # %?pv<||||||||||||||||> *might* show the effect 15.49.57 # this is for text I assume? 15.50.37 # umm 15.50.39 # Most if not all of the themes I've seen which draw in the default vp draw images in the default vp, and text in other vps. 15.51.09 # I've even come across people in here that thought that viewports were *only* for text :P 15.51.17 # the point is that the above would tell the renderer that it wants to update the line, which will mean that line will be cleared 15.52.09 # ahhhh. I honestly can't say I have seen any ill effect from drawing in the default viewport. 15.52.31 # even from other peoples code which (as you may have seen in your time) can be pretty ugly. 15.52.53 Part chrissavery 15.53.05 # ok, so... hmm... 15.53.19 # I'm not saying that there *isn't* any ill effect, but I certainly haven't seen any. 15.54.37 Quit M3DLG (Ping timeout: 260 seconds) 15.56.59 Quit mischasworld (Remote host closed the connection) 16.00.35 # bieber: I've updated SkinRendering to reflect the above convo... bassically the default viewport is only handled differently in the sbs, otherwise it is the same as any other viewport. Not sure how you want to handle it in the editor... I'll probably have to add a flag for this in mine, you can probably ignore it (or just "draw" a fake list in the UI area post "sbs update") 16.01.15 # Okay, thanks 16.01.20 Quit stoffel (Ping timeout: 265 seconds) 16.01.54 # also svn doesnt compile... 16.06.24 *** Saving seen data "./dancer.seen" 16.09.36 # It doesn't? 16.09.53 Part ubuntu-nathan 16.10.07 # Oh, wow 16.11.08 # New commit by 03bieber (r26960): Theme Editor: Fixed typo that broke compile 16.12.42 # r26960 build result: All green 16.12.43 Quit kugel (Quit: Bye) 16.13.09 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.14.35 # bieber: cool :) a thin rectangle might be better though (not filled in) 16.14.50 # Yeah, that'll definitely be changed a lot 16.15.01 # I'm just drawing them solid for now so I can see how it's rendering 16.15.22 # I guess the screen size is static at the moment? 16.15.39 # can we get a drop down to choose the dimensions? 16.16.05 # If there's no project open, it just defaults to 300x200. If you open a project with #screenwidth and #screenheight properties or a backdrop image it will resize to fit 16.16.25 # it would be *really* cool to be able to select a viewport in the tree or code and have only that viewport highlighted in the display 16.16.37 # also clicking inside the display to get the piixel coords 16.16.39 # But yes, there'll definitely be controls for just about everything to do with the machine state soon 16.17.16 # great job so far :) 16.17.27 # Thanks 16.18.29 # Good idea with the coordinates, btw...I'm thinking maybe let the user switch cursors between click-to-select, click-to-drag, and a crosshairs type view that will show coordinates and snap to objects 16.19.20 # ok, I'm going to commit the s/#ifdef SIMULATOR/#if CONFIG_PLATFORM & PLATFORM_HOSTED/ patch and document the assumptions on RockboxAsAnApplication2010, ok? 16.19.56 # the assumptions: RaaA has color bitmap "lcd", no recording, no charcell display 16.20.02 # why the 2010 in the page title? 16.20.21 # because there's a page already for the 2008 attempt 16.20.37 # so rename that one? 16.20.48 # RockboxAsAnApplication should be current and up to date 16.20.55 # otherwise it is pretty useless 16.21.01 # I cannot rename 16.21.05 # we can do that I don't care 16.23.37 # well if it is a worklog then 2010 is fine, but those assumptions are important for when someone wants to change or start a new RaaA target 16.27.37 Quit halmi (Read error: Connection reset by peer) 16.28.11 Join halmi [0] (~netbook@80-123-39-209.adsl.highway.telekom.at) 16.35.57 # JdGordon: it's as a worklog yes 16.36.13 # ok 16.36.21 # a new page should be added for directions to port the application (or add it to NewPort) 16.36.28 # yeah 16.38.27 Quit CIA-85 (Ping timeout: 264 seconds) 16.53.05 Join CIA-8 [0] (cia@208.69.182.149) 16.57.28 Quit piggz (Read error: Connection reset by peer) 17.02.52 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 17.05.38 Quit thefirstM (Remote host closed the connection) 17.09.07 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 17.10.22 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.48) 17.11.27 Quit S_a_i_n_t (Ping timeout: 264 seconds) 17.13.43 # * kugel has a strange issue with the patch 17.13.55 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 17.15.03 Join Jerom [0] (~Jerom@79.132.53.242) 17.15.13 # sysfont.h... 17.17.18 # what about it? 17.17.44 # I have a problem with it, it's not created reliably with my patch 17.17.45 Quit dfkt (Ping timeout: 245 seconds) 17.18.12 # pamaury, bertrik: I have same impression concerning battery drawing in clip+ after rockbox shutdown. I will ckeck this today. 17.24.54 Join Viaken [0] (~david@li16-211.members.linode.com) 17.26.21 # Hey. I don't have the ability to reply to the Sansa AMS topic, but I just had success with a blue FuzeV2, BH 0909 BMUK 4GB 17.26.37 # Used the 2.03.33 OF. 17.26.54 # And SVN rbutilqt 17.29.33 # http://forums.rockbox.org/index.php?topic=14064.0 If someone wants to report it for me or something, if it matters. :) Thanks for the awesome work, guys. 17.35.06 # this issue with fuzes refusing to get flashed is quite mysterious indeed 17.41.18 # Hm... I'm having some playback skips. UI showed 2:50 left in that song and it was ending. 17.42.28 # There was a noticable skip at about 0:50. 17.42.41 # I'll poke around, see if it's related to a specific option or something. 17.43.04 Join hebz0rl [0] (~hebz0rl@dslb-088-067-205-154.pools.arcor-ip.net) 17.48.40 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 17.51.43 Join einhirn [0] (~Miranda@p54850BF9.dip0.t-ipconnect.de) 17.51.45 Quit einhirn (Client Quit) 17.52.11 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 17.54.23 Join einhirn_ [0] (~Miranda@p54850BF9.dip0.t-ipconnect.de) 17.58.18 Quit einhirn (Ping timeout: 265 seconds) 18.02.19 Join r0b- [0] (~nnscript@adsl-76-235-162-105.dsl.klmzmi.sbcglobal.net) 18.03.28 Quit pixelma_ (Quit: .) 18.03.32 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) 18.06.28 *** Saving seen data "./dancer.seen" 18.07.34 Quit halmi (Quit: halmi) 18.07.59 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 18.09.09 Quit dfkt (Disconnected by services) 18.09.16 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 18.10.17 Quit t0rc (Quit: Leaving) 18.10.36 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 18.10.40 Quit Jerom (Remote host closed the connection) 18.11.34 Join Jerom [0] (~Jerom@79.132.53.242) 18.11.50 Part Jerom 18.11.52 Join Jerom [0] (~Jerom@79.132.53.242) 18.31.46 Quit Jerom (Remote host closed the connection) 18.32.24 Quit BradC (Quit: Tune in next week or I'll come through your set and rip yer bloody arms off) 18.32.42 Join Jerom [0] (~Jerom@79.132.53.242) 18.34.05 Join flydutch [0] (~flydutch@host110-154-dynamic.14-87-r.retail.telecomitalia.it) 18.39.29 Join pamaury_ [0] (~quassel@p5DDEF6F6.dip.t-dialin.net) 18.43.00 Quit pamaury (Ping timeout: 258 seconds) 18.46.43 Join funman [0] (~fun@rockbox/developer/funman) 18.49.07 # pixelma: my commit shouldn't break anything; the features were not needed in these rules, i only left them for voices; manual makefile was not touched by this commit 18.50.06 # funman: ACTION_FM_QUICKSCREEN should have been used, I guess it also got lost in the fms commit 18.50.33 # i didn't check the history 18.51.58 # also i wondered what a FM quickscreen would look like 18.53.44 # funman: like the normal quickscreen 18.54.24 # I added quickscreen access from the radio screen not too long ago but I also recently noticed it doesn't work anymore 18.55.47 Join stoffel [0] (~quassel@p57B4C7C4.dip.t-dialin.net) 18.57.51 # what settings would you change in the radio from a quickscreen? 18.58.05 # funman: the bininstall doesn't work for the sim 18.58.43 # pixelma, wondered about that too. repeat, shuffle ? :P 18.58.50 # clip+ with PLLA@384MHz doesn't work fine 18.59.15 # pixelma: whatever you have in the quickscreen 18.59.32 # * kugel doesn't understand why the "where you come from" matters at all 19.00.39 # well, because you usually change settings when you need to change them, when listening to the radio I would never think "oh, forgot to change back my repeat settings" 19.01.00 # funman: Now you're here...(and I am as well) 1: Yes, I can confirm that there is no undesirable effect running Nano 1g with arm-elf-eabi. 2: I would be happy to either confirm/deny FS#11404 if I were pointed to the exact feilds I needed to edit in the source to force 44kHz sound for plugins or if some kind soul could make a diff to that effect. 19.01.08 # what if you have settings in the quickscreen that make sense everywhere, like backlight brightness? 19.01.33 # S_a_i_n_t_: just run them unmodified or play a 22.05kHz mp3 file 19.02.01 # you could add some radio specific settings to the quickscreen too 19.02.14 # the things I could imagine wanting to change easily in the radio would be preset mode or force mono which are easily accessed sometimes directly or through the radio context menu 19.02.17 # bertrik: did you test playback on clip+ with PLLB@384MHz ? 19.02.23 # no not yet 19.02.35 # "run them unmodified"? sound in doom/rockboy for example is awful, but I thought this was known? 19.02.43 # no it works fine for me 19.03.03 # Oh. 19.03.22 # I don't, so it's hard to imagine (besides I almost never use the quickscreen, usually just because entering by accident and then trying to leave as soon as possible) 19.03.43 # the driver should support 11.025 22.05 44.1 and 88.2 kHz 19.04.35 # Well, then yes...rockboy is possibly the best example of this. the sound on Nano2g is horrible enough to force someone to turn the sound off or violently snatch the IEMs out of ones ears. 19.05.01 # (IMO), but I thought this was well known. 19.05.11 # What's so horrible about it? is it choppy? noisy? 19.05.43 # it sounds like it's being played through an internal PC speaker...from the 1980s 19.06.14 # IIRC, Nano1g isn't any better though. 19.06.15 # can you record it and share the recording? 19.06.31 # unfortunately, no, I can't. :/ 19.06.46 # S_a_i_n_t_: that's how the gameboy sounded back then 19.07.12 # in fact, the first game buy was from the 80s and only had a small speaker 19.07.15 # boy* 19.07.26 # ffmpeg -i file.mp3 -r 22050 out.mp3 # should give you a 22.05kHz file 19.07.31 # kugel: No, it's worse than that...it sounds fragmented/choppy/scratchy 19.07.46 # probably because of frame skipping 19.07.50 # it sounds...sick. 19.08.42 # And the 2g can handle the lowest frameskip quite well, it doesn't seem to effect the sound. 19.08.44 # kugel: what's wrong with bininstall in sim ? 19.08.59 # the binary isn't in .rockbox 19.09.54 # so the rule shouldn't exist? 19.10.07 # dunno 19.10.19 # the binary is in the build dir so nobody would run it anyway 19.10.51 # New commit by 03funman (r26961): bininstall: works for PREFIX directories with spaces 19.12.28 # r26961 build result: All green 19.13.07 # * kugel finds the all green message annoying 19.14.38 # 384MHz PLLB for playback works fine 19.18.26 # funman, sorry, I somehow misread that you were talking about PLLA 19.20.25 # our macro for calculating fclk divider overflows with 384MHz 19.21.24 # (*(volatile unsigned long *)(0xC80F0000 + 0x10)) = ((((((384000000*(8-0)/8) + 192000000 - 1) / 192000000) - 1) << 4) 19.23.02 # fclk@192MHz boots fine 19.25.31 # "integer overflow in expression" 19.27.48 # supposedly 120MHz fclk boots fine: PLLA@384MHz, fclk prediv @ 5/8 19.36.49 Quit kugel (Ping timeout: 240 seconds) 19.36.56 Quit hebz0rl (Ping timeout: 245 seconds) 19.39.38 # bertrik: apparently changed pclk causes problems on fuzev2 19.40.34 # and my test shows that predivider is correctly applied to cpu freq 19.41.25 # http://pastie.org/1011579 19.45.33 # funman, you got 120MHz instead of 240MHz with PLLA@384MHz and prediv of 5/8? 19.45.54 # no, i got 120MHz with PLLA@384MHz, prediv 5/8, postdiv 2 19.46.04 Join binaryhermit [0] (~binaryher@adsl-99-141-184-240.dsl.emhril.sbcglobal.net) 19.46.06 Quit Strife89 (Ping timeout: 260 seconds) 19.46.15 # if i try to get 240MHz with postdiv 1 the clip+ doesn't boot and crashes randomly 19.46.29 # hm 19.46.53 # i'll try with PLLA@384MHz, prediv=1 (8/8), postdiv=2 => fclk@192MHz 19.47.54 # works fine 19.48.23 # (all tests with pclk@24MHz on clip+) 19.48.31 Nick detaos_ is now known as detaos (~quassel@ip72-218-104-242.hr.hr.cox.net) 19.50.06 # PLL@384 FCLK@240 PCLK@64 = same problems 19.51.00 # AzureSky: could you try to modify clock-target.h to use 62MHz PCLK on fuzev2? (instead of 41333333...334 19.52.24 # a bit more battery life on clipv1 perhaps: 8h18, i need to test if it's my patch 19.52.30 Quit funman (Quit: free(random());) 19.52.52 # I'm not completely sure how this prediv works. I can imagine it just passes 5 ticks and then skips 3 ticks. The 5 ticks could be fast ticks at 384 MHz. 19.57.43 # * TheSeven has a bit of time during the next weeks 19.58.07 # I'm still wondering what to do about the nano2g bootloader/FTL issue 19.58.49 # yelling at it didn;t work then obviously? 19.58.55 # ;) 19.59.23 # TheSeven: what is the problem ? 19.59.26 Nick pamaury_ is now known as pamaury (~quassel@p5DDEF6F6.dip.t-dialin.net) 19.59.42 Quit pamaury (Changing host) 19.59.42 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 19.59.48 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.48) 20.00.33 Quit einhirn_ (Read error: Connection reset by peer) 20.00.37 # pamaury: things are just broken 20.01.19 # basically everyone uses the iLoader no ? 20.01.22 # nope 20.01.42 # TheSeven: You seem to hit more issues than I do it seems? 20.02.07 # I, personally, am not hitting any issues (I use iLoader) 20.02.25 # My 2G Nanos (using RB bootloader) have been solid for a while now. 20.02.30 # however, other people keep having trouble with the iloader installation/uninstallation 20.03.07 # I haven't seen any of the really annoying issues the 2G used to have in a loooong time now. 20.03.12 # * S_a_i_n_t touches wood. 20.03.15 # and iLoader is intended to be a very flexible solution for power users, not the default way of booting rockbox 20.03.39 Join CaptainKwel [0] (~jason@207-237-113-115.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 20.04.04 # S_a_i_n_t: Still, the possibility of storage corruption is blocking the target's promotion to "stable" IMO 20.05.00 Join Strife89 [0] (~Strife89@adsl-80-182-32.mcn.bellsouth.net) 20.05.31 # Because of the sturdyness it seems to have lately, I have even started to give the 2G preference over the 1G...but, I do see what you mean. Although I have been updating it regularly, and transferring large ammounts of data without a single hiccup sine I don't know when. 20.06.00 # s/sine/since/ 20.06.09 # Sadly I had some iloader-unrelated hiccups not too long ago 20.06.22 # :/ 20.06.26 # and i have no idea what was going on 20.06.32 *** Saving seen data "./dancer.seen" 20.06.34 # (and can't reproduce it either) 20.07.02 # My 2G (one in particular) used to WSOD daily, now...seems solid. 20.07.24 # but I still don;t really trust it. 20.07.30 # ;) 20.07.36 Quit mitk (Quit: Leaving) 20.07.53 # those wsods aren't fixed, just hidden (most of them were stkovs which were "fixed" by increasing the stack size) 20.08.12 # IMHO the storage/file system layer needs some serious work 20.08.18 # Ah, yes...I keep forgetting about that. 20.08.22 # still way too many buffers all over the place 20.08.43 # There aren't that many buffers 20.08.57 # IMO there should never be *any* of those on the stack 20.09.00 # I've noticed that it takes a lot longer for the 2G to start now. 20.09.05 # (using RB bootloader) 20.09.12 # Ah, on the stack, yes 20.09.27 # it used to blitz the Nano1G, now it's about a second behind it. 20.09.29 # TheSeven: where are those famous buffers on stack ? 20.09.44 # if i knew... 20.09.59 # some of them are certainly in plugins, especially batterybench seems to have trouble with them 20.10.21 # and I have the impression that the FAT code will sometimes use stack buffers 20.10.44 # I thought I had cured the FAT code from this illness but perhaps I'm wrong 20.11.01 # Give a minute to check this assertion 20.11.05 # i haven't checked that recently, at least there were some a few months ago 20.11.25 # yes 20.11.33 # let me check some things 20.11.53 # There is one is fat_mount :( 20.11.55 # * TheSeven will add a panic on misaligned buffers (this is also causing quite some performance penalty) 20.11.55 Quit stoffel (Read error: Connection reset by peer) 20.12.00 # One sector 20.12.04 # well, the mount one won't hurt 20.12.11 # that's only done once in the main thread 20.12.41 # Yep but I'm pretty sure it could use another one, the remaining buffers are unused at mount time so could be used perhaps 20.13.08 # Hum, but I guess all the buffers are in the file.c code anyway (or something like that) 20.13.49 # There is one in update_fsinfo 20.14.11 # This one is not great 20.14.31 # that might well be the one that's causing the stkovs everywhere 20.15.29 # Yep, it can be invoked on lots of call actually: create/remove dir, close file, recalc free space, ... 20.15.45 Quit flydutch (Quit: /* empty */) 20.16.24 # There is one in write_long_name, not good at all 20.16.47 # Well, in fact there are lots of them, but there are not so easy to get rid off 20.16.52 # :( 20.18.20 # I'll have a look at this. Some of them can probably be removed but I need to seriously think about it, the code is quite tricky already 20.18.24 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 20.19.40 Quit CaptainKwel (Quit: Ex-Chat) 20.19.42 # * S_a_i_n_t would be happy to test any patches on his Nano2Gs if need be... 20.20.43 # Well, I can test the fat code myself (and I'll don't want to be responsible for a massive fs destruction in RB :)) 20.21.28 # The problem is always the same, the 2G has a big sector size... 20.23.11 # that won't be a problem as long as there aren't any buffers where they shouldn't be 20.24.15 # indeed :) 20.26.12 # hm, stack dumping code would be helpful 20.26.46 # to trace back overflows ? 20.28.05 # I thought we already have something like that in the "View OS stacks" debug menu 20.29.02 # Or is every thread affected by this? 20.35.24 Join Topy44 [0] (~topy@my.fastsh.it) 20.35.31 # I think he was more talking about displaying the stack on overflow or something like that. The view OS stacks debug menu only list threads, status and stack use 20.39.07 # actually I'd just like to see where a certain misaligned disk access is coming from 20.40.11 Quit Topy44 (Ping timeout: 260 seconds) 20.40.24 # Is this causing issues ? 20.41.37 # it's an easy way of finding most of the on-stack buffers, and misaligned accesses need copying-around in the NAND code 20.42.28 # so we could get rid of a static sector buffer in the NAND driver if we get rid of all misaligned accesses 20.42.49 # this one is probably the mount one you talked about 20.43.00 # (accessing sector 0 and only requesting that single sector) 20.44.20 Join Topy44 [0] (~topy@my.fastsh.it) 20.44.59 # indeed 20.45.39 Join saratoga__ [0] (463f90ed@gateway/web/freenode/ip.70.63.144.237) 20.46.10 # * TheSeven wonders if that access could be done through the FAT cache to avoid the need for that buffer 20.47.14 # oh, that's only for the FAT itself 20.47.24 # The thing is that the FAT code hasn't got a "FAT cache" in itself so it's not that simple but I promise I'll have a look in a few hours. When i'm bored trying to make usb work. 20.48.17 # it actually seems to have one 20.48.36 # I'm not sure of its actual usage, except for the FAT itself 20.49.06 # But perhaps you're right 20.49.22 # Anyway, at mount time, the cache is unused so it's safe to use it :) 20.49.23 # it's only for the FAT itself, but we can certainly abuse it 20.49.28 # no, it isn't 20.49.37 # at least not if there are multiple volumes 20.49.59 # however, we can just lock the mutex, flush page 0 if it is in use, and use that for the boot sector 20.50.00 # Then we can probably evict one entry from it 20.50.38 # i'd just keep the mutex locked until we're done, or we'll be running into trouble if someone else tries to flush our buffer 20.50.52 # For sure 21.01.28 # no, it wasn't that access 21.01.52 # but I have a suspicion what it could have been 21.02.57 # it's the FS type determination 21.03.01 # but where was that code? 21.03.34 # I didn't know we had FS type determination code... 21.03.47 # or rather partition table parsing code 21.03.56 # i.e. looking for the start of the fat partition 21.04.06 # ah, I think we have this code :) 21.04.18 # I woudl go for disk.c but that's a guess 21.05.02 # The disk_init function does that I think, check common/disk.c 21.05.51 Quit Topy44 (Ping timeout: 260 seconds) 21.06.20 # JdGordon|: Yep, so if you have no need for viewports then it is perfectly fine to not use them at all :) 21.06.22 # hmm, damn, no buffer around that could be abused 21.07.40 # hm, you're right, that's seems quite hard in this case 21.07.43 Join Topy44 [0] (~topy@my.fastsh.it) 21.07.59 # i'll use an aligned stack buffer then 21.08.33 # How do you do that ? 21.08.46 # Does gcc enforces that on stack ? 21.09.13 # no, but we can just add STORAGE_ALIGN_MASK bytes to the size and ceil the pointer 21.09.48 # that may waste up to 16 bytes of stack in this case, but who cares 21.10.14 # * pamaury feared that TheSeven would say that 21.12.55 # pamaury: you were working on the amsv1 usb right? 21.13.07 # I'm working on amsv2 usb 21.13.17 # On my clip+ right now 21.13.21 # ah ok 21.13.30 # was going to ask how similar they are 21.13.42 # saratoga__: ranma was working on amsv1 usb 21.14.00 # pamaury, do you want someone to review your code? I'm volunteering to have a look and help. 21.14.06 # They are different. the clip+ controller is the same as the nano2g except it's a newer version (2.6 vs 2.2) 21.15.08 # bertrik: I'll appreciate some help, I'm must be missing the problem. I'm currently cleaning up the code because it's a mess and I'll commit that soon. Then you are welcom :) 21.15.24 # ok 21.15.46 # pamaury: I'm looking at your code and trying to get a USB_GINTMSK_outepintr but I never get one, do you have any idea why ? 21.16.19 # so they're completely unrelated controllers? 21.16.36 # Jerom: that has been my problem for two weeks now 21.17.21 # pamaury: did you remove the usb_disable_global_interrupts(); at the end of handle_usb_reset ? 21.17.26 # yes 21.17.49 # The svn code is quite outdated, I changed it a old 21.18.13 Quit saratoga__ (Quit: Page closed) 21.18.13 # s/old/lot 21.26.16 # I hope you will get it to work pamaury because Sansa's OF is a pain when handling USB 21.27.32 # hm, STORAGE_ALIGN_DOWN seems to be broken 21.31.59 # why does "make manual" care that I have not set up arm-elf-eabi-gcc yet? :\ 21.37.00 # grr, there are misaligned non-stack bufferes in the fat.c code somewhere 21.37.34 # at least they're somewhere in here: 21.37.34 # .bss 0x0810e638 0x1016c /data/rockbox-trunk/build/nano2-app/firmware/libfirmware.a(fat.o) 21.37.47 # how can i find out what this consists of? 21.38.58 # objdump on the .o ? 21.39.20 # hm, no easier way? (some more detailed listing) 21.43.22 # arm-elf-eabi-addr2line perhaps? 21.43.55 # oh, it's in .bss 21.48.40 # pamaury, we changed the PLLA frequency to 248 MHz on as3525v2. I hope that's not interfering with your USB work. 21.49.56 # As long as it does not prevent bus reset and enumeration, I guess it's ok. I think my current svn head has old plla though 21.50.29 Quit Battousai (Read error: Connection reset by peer) 21.50.51 Join Battousai [0] (~bryan@gentoo/developer/battousai) 21.55.52 # funman sorry i was in bed when you requested i edit that, I have no clue how to edit the clock seettings.....have you done a testbuild with those settings? 21.57.39 # damn, fat_cache_sectors is misaligned 22.06.36 *** Saving seen data "./dancer.seen" 22.07.48 # pamaury: oh well, misaligned buffers all over the place 22.08.01 # STORAGE_WANTS_ALIGN seems to have been ignored widely 22.08.16 # hehe, time to fix it 22.08.16 Quit Topy44 (Ping timeout: 260 seconds) 22.08.46 # can somebody give me a little help doing what funman wanted done earlier?(when i was asleep) 22.09.39 # New commit by 03jethead71 (r26962): iPod 3G: Implement wheel acceleration and repeats. Chosen settings feel pretty decent but can be tweaked. 22.10.25 Join Topy44 [0] (~topy@my.fastsh.it) 22.11.14 # r26962 build result: All green 22.13.43 # pamaury: I'm running into a problem 22.14.19 # how can i efficiently make sure that a buffer thats inside three levels of nested structs is aligned properly? 22.17.37 Join Dekkard [0] (~psykobabb@c-67-167-177-8.hsd1.mi.comcast.net) 22.20.04 # im having a problem with wps working.. 22.23.21 # More details please :) 22.23.39 # But at a guess - the WPS syntax changed between 3.6 and the current builds 22.23.50 # I'd guess you are trying to use a wps for one on the other 22.24.25 # yay 22.24.32 # sector buffers on the usb thread's stack 22.25.41 # hey there. is it possible to write a plugin that scans the FM spectrum and makes a graph based on signal strength? 22.26.02 # pamaury: could the fsinfo updater always steal a sector buffer from the fat cache? 22.26.42 # sharp: yes, you should be able to tune the radio and measure the power from a plugin 22.28.03 # saratoga: cool. i can just reference functions in the radio "driver" from the plugin? 22.28.37 # you'll probably have to add them to plugin.h unless theres already some plugin that records from the radio 22.29.37 # * TheSeven is getting grumpy 22.32.57 # TheSeven: inside three levels ? Align each structure and align the field into the structure 22.33.21 # TheSeven: what do you mean by always ? 22.33.23 # what happens if those structs have an odd size and are in an array? 22.33.40 # If you ask the that the structure be align, it will workj 22.33.51 # I think 22.33.57 # the struct definition itself? 22.34.00 # yes 22.34.31 # re fsinfo updating: never allocate the buffer on the stack, steal it from the fat cache instead 22.35.14 # Ok, five me a few minute to finish have a coffee and commit my usb stuff, so I can work on this buffer problem 22.36.01 # New commit by 03kkurbjun (r26963): iPod Mini 1G - Build with EABI. 22.36.58 # New commit by 03jethead71 (r26964): iPod 3G: Add a small check to ensure backlight never gets stuck off if wheel is inactive for too long (because it limits the number of backlight_on ... 22.37.35 # r26963 build result: All green 22.38.47 # New commit by 03pamaury (r26965): as3525v2-usb: don't disable interrupts on bus reset (that was for debug purpose) 22.38.48 # funman: playback on the current build is somewhat broken on the clipv2, lossless files pretty quckly die with codec failure or simply static 22.38.53 # I should have commit usb stuff before 22.39.00 # i'm guessing this is an SD driver issue 22.39.13 # bah, i cant checkout code for a build i need to test(to be 100% sure 37 is the cause of the loss of microsd card support) bah 22.39.19 # r26964 build result: All green 22.39.29 # wow.. when i run like arbox widgets.. i dont get the wps.. just the theme for the rest of the screens.. sorry.. 22.39.30 # New commit by 03pamaury (r26966): as3525v2-usb: reorganize thing, don't renable ep0 on enum because it's already done 22.39.34 # New commit by 03pamaury (r26967): as3525v2-usb: rework thing, simplify 22.39.41 # New commit by 03pamaury (r26968): as3525v2-usb: tweaks things but still doesn't work. 22.39.47 # New commit by 03pamaury (r26969): as3525v2-usb: simplify register definitions 22.39.54 # New commit by 03pamaury (r26970): as2525v2-usb: coherence fix 22.39.55 # Dekkard: you're using an outdated theme, update it 22.39.59 # New commit by 03pamaury (r26971): as3525v2-usb: major code renaming 22.40.06 # assuming you got it from the theme site you should just be able to redownload it 22.40.10 # New commit by 03pamaury (r26972): as3525v2-usb: end of massive renaming 22.40.18 # New commit by 03pamaury (r26973): as3525v2-usb: remove useless macro 22.40.19 # ok.. just installed with the utility,, on a currnet build 22.40.44 # TheSeven: ok, now I can work on fat 22.41.00 # how do you commit so quickly in sequence? is that a git thing? 22.41.07 # yeah 22.41.18 # r26965 build result: All green 22.41.27 # I'm a serial-committer ;) 22.41.28 # do them all as local commmits, then push them to svn 22.41.29 # Git is the perfect tool to try to get interesting revision numbers 22.42.32 # i need to figure out git someday 22.42.50 # gevaerts: do you happen to know why a sector buffer might be lingering on the usb stack? 22.42.51 # TheSeven: did you modify some thing in the fat code already ? 22.42.52 # r26973 build result: 0 errors, 36 warnings (pamaury committed) 22.43.10 # pamaury: yes, I modified fat_mount to not use an on-stack sector buffer 22.43.17 # huh ? What is this build order ???? 22.43.22 Join anewuser [0] (anewuser@unaffiliated/anewuser) 22.43.34 # TheSeven: ok, I'll have a look at the other buffers 22.43.43 # Did you fix the disk.c one ? 22.43.53 # is there a make switch to build all the test plugins? 22.43.54 # New commit by 03gevaerts (r26974): Also tell the build system that we now build the iPod Mini 1G with eabi 22.44.13 # saratoga: afaik no 22.44.19 # pamaury: yes, i just aligned that one 22.44.34 # saratoga: In debug 22.44.44 # so its in configure? 22.44.48 # yeah 22.45.13 # Sorry, I meant advanced, not debug 22.45.19 # But yes, when you configure 22.45.31 # TheSeven: check_disk_present() uses one sector worth of stack space 22.45.40 # where is that? 22.45.47 # usb_storage.c 22.45.49 # * gevaerts checks if that's needed 22.46.42 # hm 22.46.48 Quit Dekkard (Quit: Going!) 22.47.29 # The call during usb_storage_init_connection() could clearly use the transfer buffer, but the one during usb_storage_notify_hotswap() isn't as straightforward 22.48.10 # is someone around who gets users' ml mails? 22.48.23 # and can reply to 22.48.26 # New commit by 03kkurbjun (r26975): iPod Nano 1G - Build with EABI. 22.49.08 # New commit by 03pamaury (r26976): as3525v2-usb: fix yellow about unused functions (they can be resurrected from an older revision if needed) 22.49.17 # * pixelma didn't know kkurbjun had a Mini1G and a Nano1G 22.49.34 # pamaury: the build system doesn't do all revisions if it's running behind 22.49.55 # r26975 build result: 0 errors, 36 warnings (kkurbjun committed) 22.50.06 Join kkurbjun [0] (~kkurbjun@c-24-9-122-9.hsd1.co.comcast.net) 22.50.13 Quit kkurbjun (Changing host) 22.50.13 Join kkurbjun [0] (~kkurbjun@rockbox/developer/kkurbjun) 22.50.38 # kkurbjun if ur wondering CIA-8 r26975 build result: 0 errors, 36 warnings (kkurbjun committed) 22.51.12 # TheSeven: you removed the buffer in update_fsinfo ? 22.51.17 # r26976 build result: All green 22.51.18 # not yet 22.51.33 # AzureSky: that information is availaible on a web page that I'm sure he knows about. Also, please use real words. Ur is an ancient city, bot a word 22.51.35 # how does test disk work? does it just run forever until it gets an error? 22.51.36 # *not 22.51.46 # gevaerts: OK, it was definitely check_disk_present that was causing the error 22.51.46 # Ok, I'll try to remove the one from write_long_name. Perhaps I can use the file's cache 22.52.30 # kkurbjun: were those eabi builds tested on target? I'm wondering because I didn't know you had these two 22.52.33 # New commit by 03gevaerts (r26977): Also tell the build system that we now build the iPod Nano 1G with eabi 22.52.41 # nice getting on my arse about spelling and you cant even do it your self. 22.52.59 # pixelma: yes, they were tested on target - I have both 22.53.06 # AzureSky: there's a slight difference between a typo and a deliberate decision not to care 22.53.21 # AzureSky: The guidelines do specify real words - this is for people using screen readers and non-native speakers. Please respect them. 22.54.00 # gevearts: though it used to show all the revisions included in a particular build when clicking the rxxxxx link 22.54.39 # thanks for the build system updates gevaerts 22.54.40 # hm, yes, I seem to remember that vaguely 22.55.01 # kkurbjun: ok, good to know, also for the next time testers are needed (especially the Mini1G as it is more rare) 22.56.02 # Three targets left: ipod 4g, d2 and vibe500. 22.56.04 # I thought there was a wiki somewhere with that information.. I'll have to update it if its not there 22.56.38 # RockboxTesting 22.56.51 # gevaerts: domonoky has a G4 22.57.05 # That's why I iwas summoning him... didn't work so far 22.58.17 # damn, apparently there's another sector buffer on the usb stack 22.58.28 # at least it stkov's if I remove the additional space for it 22.59.40 # * jhMikeS wants all ARM to get eabi'd ASAP so he can remove some long call constructs from thread asm code 23.00.41 # damn, it's the one I just aligned 23.00.42 # b0hoon hasn't been online since a while now 23.00.49 # thanks for the misleading comment in usb.c 23.01.08 # * jhMikeS sees all PP getting eabi'd will be sufficient for that 23.01.48 # jhMikeS: two of the three remaining ones are PP, so that doesn't help you much :) 23.02.10 # vibe500? 23.04.07 # PP5020 23.04.09 # what do we consider better (or rather less ugly)? having another static sector buffer just for reading the partition table, or increasing the USB thread's stack by the size of a sector buffer to allocate it from there? 23.04.10 # has anything failed yet (besides the pp5002 thread glitch)? 23.04.25 # D2 i2c code 23.05.08 # * TheSeven still likes the idea of a global sector buffer pool 23.05.17 # but that's not PP, only PP makes long calls in the thread support routines (which are dual-core related). it's inconsequential to getting rid of that. 23.05.24 # gevaerts: b0hoon has been active in the forums recently (seems he has a GoGear too) 23.05.29 # Also this weird gradiuent in PF on arm7 23.05.59 # Probably a mail to the ML would be useful 23.06.49 # * jhMikeS looked at that and can't see readily anything but a gcc bug being the reason (given compiling as arm9tdmicc makes it go away) 23.07.22 # someone on the users' ml who could also add "daily manuals broken too" to the English voice thread? 23.08.32 # I'd like to get Zagor's attention since he's not around and we are only keeping 3 or 4 dailies now and will soon lose them (tomorrow or the day after) 23.09.04 # and since he answered that thread... 23.09.32 # * pixelma still thinks 3 or 4 dailies is a bit too few 23.12.07 # update_fsinfo, write_long_name, add_dir_entry, update_short_entry, fat_create_dir, free_direntries, fat_rename, ... 23.12.13 # still loads of on-stack sector buffers 23.12.37 # * TheSeven starts to like the idea of a global sector cache even more 23.12.50 # yep 23.13.54 # the write_long_name one is impossible to get rid off without using the fat cache basically 23.15.56 # i'm thinking of removing all the stack buffers and also the ones from the structs and having one big pool instead 23.16.28 # that way we can use otherwise unused e.g. file or dir buffers as read cache 23.17.06 # * TheSeven suggests a fully-associative cache with a LRU replacement strategy 23.17.31 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 23.19.09 # pamaury: can you think of anything that could cause problems with that approach? 23.20.04 # Currently no, but I'm thinking about it. I'm trying to determine if we really should get rid of all the buffers in the structure or not and how much work that would be 23.20.29 # pamaury: they're effectively dead memory 23.20.44 # TheSeven: You'd need very careful locking to do that 23.20.51 # yes, of course 23.22.07 # pamaury: basically we can just allocate a buffer from the cache as soon as the file/dir is opened to replace the one in the struct 23.22.17 # but as long as the struct is unused, we don't need to waste that memory 23.22.54 # that's true 23.23.13 # that shouldn't be too much work either 23.23.19 # Anyway, the buffer in fat_dir is only used when seeking in the file I think 23.23.39 # that can of course be optimized then 23.23.58 # (once the rest of it works ;-) 23.24.26 # We need to check outside use of the fat structure (like in file.c, dircache.c) 23.25.14 # Ok no problem, the sectorcache buffer does not seem to be used 23.25.38 # So we *just* need to write the sector buffer pool :) 23.25.39 # and even if it is, that will just give a compilation error which can be tracked down easily ;-) 23.26.23 # * TheSeven might have a go at that tomorrorw 23.26.27 # tomorrow* 23.27.45 # New commit by 03bluebrother (r26978): Add error messages to a few more failure cases to beastpatcher. 23.29.11 # r26978 build result: All green 23.33.41 # pamaury: I see you removed every USB_ prefix, where you tired of typing it ? ^^ 23.35.02 # That was stupid, the header is not used by any other file so it's obviously usb related :) 23.35.35 # and it's for readability. Where you write USB_regname & USB_regname_fieldname, each character counts ! 23.38.45 # Noob question: does logf write the log to a file ? 23.39.34 # no, you need to dump it via the debug menu 23.40.35 Quit Highlander (Ping timeout: 276 seconds) 23.42.44 # bertrik: if you want to have a look at the usb code, see if you see something wrong 23.43.07 # I'm going to check that all registers have a correct address and there are no wrong bits 23.49.58 # I have a problem, When I Type /tools/configure from inside the rockbox/build folder it says "bash: /tools/configure: No such file of directory" 23.49.59 # 23.51.06 # you probably want ../tools/configure 23.51.16 # ie with two dots first 23.52.04 # thx 23.52.38 # Bagder: do you know something about the daily builds breakage mentioned in http://www.rockbox.org/mail/archive//rockbox-archive-2010-06/0038.shtml - alternatively when Zagor will be around? 23.52.47 # nope 23.52.56 # testing one build back once this finishes compiling, wana be 100% sure its 26937 thats causing microsd cards to not work 23.52.59 # and nope 23.53.45 # daily manuals haven't been build either (last on the 17th) and since we only keep 3 or 4 dailies recently, there won't be any soon 23.54.21 # maybe it would make sense to add the manuals to the build system? 23.55.03 # so manuals after all commits too? 23.55.30 # why not? Shouldn't take too long. The only problem is that there is nothing like ccache for TeX 23.56.18 # or maybe as separate build round to not slow the builds itself down? 23.56.42 # nothing against that really, thinking of recent breakage and fixes which needed you to wait until the next day to see if all have been fixed 23.57.50 # my question was more about how that could help now (and I first thought you just meant build to see if it still builds as done with sims, which wouldn't help in this case) 23.58.38 # well, not sure if it would make sense to publish current manuals. Would be an option of course.