--- Log for 29.04.110 Server: bartol.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 13 hours ago 00.01.13 Quit RadicalR (Ping timeout: 245 seconds) 00.04.15 Quit fyrestorm (Read error: Connection reset by peer) 00.08.01 Quit blithe (Read error: Operation timed out) 00.08.18 Join blithe [0] (~blithe@72.14.176.144) 00.10.52 Quit linuxstb (Ping timeout: 276 seconds) 00.11.19 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 00.11.21 *** Saving seen data "./dancer.seen" 00.11.27 Quit mikroflops (Ping timeout: 252 seconds) 00.11.53 Quit crwl (Ping timeout: 264 seconds) 00.16.40 Join MethoS- [0] (~clemens@134.102.106.250) 00.17.19 Join zivan56 [0] (~not@64-46-5-45.dyn.novuscom.net) 00.19.10 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 00.20.35 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 00.20.40 Join DoingGodsWork [0] (~Invitee@unlimited01.swisscom-mobile.ch) 00.20.43 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) 00.20.56 Part DoingGodsWork 00.21.02 Quit kenguest (Read error: Connection reset by peer) 00.22.28 Join kenguest [0] (~radagast@lir.talideon.com) 00.25.55 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 00.27.52 Quit bertrik (Quit: De groeten) 00.36.02 Quit wodz (Quit: Leaving) 00.37.36 Quit DataGhost (Ping timeout: 240 seconds) 00.39.29 Quit DerPapst (Quit: Leaving.) 00.46.47 Quit TheSeven (Read error: Connection reset by peer) 00.50.01 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 00.53.16 Quit archivator (Quit: Leaving) 00.57.24 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 00.59.16 Quit liar (Quit: Verlassend) 01.00.36 Quit mikroflops (Ping timeout: 246 seconds) 01.05.11 Quit ender` (Quit: Trying to establish voice contact ... please yell into keyboard.) 01.12.46 Quit robin0800 (Quit: Leaving) 01.15.38 Join kisak_ [0] (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) 01.17.55 # hello, I found what appears to be the wiki equivilent to lint 01.20.24 # on http://www.rockbox.org/wiki/SansaFuze down in the Fuze v2 section there is a speculation "Presumably based on an AS353x CPU like the ClipV2." Isn't the development of the Fuse v2 to the point that we know that it contains an AS3525? 01.23.03 # (especially since it's referenced 3 lines later) 01.32.16 Quit MethoS- (Remote host closed the connection) 01.43.44 Join linuxguy3 [0] (~timj@adsl-75-57-198-233.dsl.emhril.sbcglobal.net) 01.53.28 Part toffe82 01.57.27 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 01.58.56 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 01.58.58 Quit panni_ (Ping timeout: 248 seconds) 01.59.24 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 02.01.37 Quit komputes_ubuntu (Quit: I haven't slept for ten days, because that would be too long.) 02.06.40 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) 02.06.40 Quit rasher (Read error: Connection reset by peer) 02.07.51 Quit Rob2223 (Quit: Rob2223) 02.08.56 Quit lifeless__ (*.net *.split) 02.08.56 Quit jfc (*.net *.split) 02.10.20 Join lifeless__ [0] (~lifeless@90.151.222.231) 02.11.22 *** Saving seen data "./dancer.seen" 02.11.35 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 02.11.36 Quit rasher (Changing host) 02.11.36 Join rasher [0] (~rasher@rockbox/developer/rasher) 02.16.57 Quit markun (Read error: Connection reset by peer) 02.16.58 Join markun_ [0] (~markun@rockbox/developer/markun) 02.22.09 Join Rob2222 [0] (~Miranda@p4FDCA468.dip.t-dialin.net) 02.26.38 Quit robin0800 (Remote host closed the connection) 02.33.37 Quit kerwood (Quit: Leaving.) 02.43.27 # New commit by 03funman (r25753): as3525v2: effect of CGU_PROC on fclk is instant ... 02.43.39 Join funman [0] (~fun@rockbox/developer/funman) 02.44.14 # kisak_: yup it's based on as3525, probably nobody fixed the wiki 02.47.49 Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.48.34 # weird: current build seems to not crash on Clip+ .. ? 02.51.29 # ah "nice" it still crashes :) 02.52.13 # still in set_cpu_frequency(), when storing the new frequency to memory (cpu_frequency global variable) 02.55.33 # well, seeing as I'm not a registered wiki user, would someone clean out that lint? 02.56.13 # I can help you to get write rights ;) 02.57.21 # at this point the wiki pages for each model are not particularly helpful for development (except perhaps pictures of the boards) so i have no strong will to keep them up to date with current knowledge 02.58.54 # they also make good history 03.01.41 # oh, I just found a simple typo 03.05.18 # so I'm not allowed to use my alias as my wikiname? 03.07.35 Join komputes [0] (~komputes@ubuntu/member/komputes) 03.08.23 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 03.08.28 # nope, you must use FirstnameLastname 03.09.58 Join Anonomizer [0] (~chatzilla@dhcp-168-105-235-18.wireless.manoa.hawaii.edu) 03.10.05 Quit Anonomizer (Remote host closed the connection) 03.15.04 Join hebz0rl_ [0] (~hebz0rl@dslb-088-067-199-149.pools.arcor-ip.net) 03.15.40 Quit w1ll14m (Read error: Connection reset by peer) 03.16.34 # is user registration handled manually? 03.16.59 # registration no, but once you're registred I have to give you write rights manually (just give me your username) 03.18.00 # ok, I'm waiting for a confirmation email 03.18.49 Quit hebz0rl (Ping timeout: 264 seconds) 03.20.55 Quit panni_ (Ping timeout: 265 seconds) 03.22.40 Quit n17ikh (Ping timeout: 264 seconds) 03.29.25 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 03.30.11 Join anewuser [0] (anewuser@unaffiliated/anewuser) 03.30.18 Join Guest23293 [0] (~n17ikh@host-69-59-126-212.nctv.com) 03.34.12 Quit n17ikh (Ping timeout: 259 seconds) 03.34.52 Quit Guest23293 (Ping timeout: 240 seconds) 03.39.12 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 03.45.23 Quit adnyxo (Quit: Leaving) 03.54.50 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 03.54.52 Join Strife89|PalmTX [0] (~cstrife89@adsl-80-137-151.mcn.bellsouth.net) 03.56.39 Join DJVistaMan [0] (~Anthony@bas1-montreal30-2925418447.dsl.bell.ca) 03.57.04 # Are there any mods for the iPod Nano 3Gen available? 03.57.17 # On any platform 03.57.21 # DJVistaMan: Not here at least... 03.57.33 # ok Thanks 03.58.04 Quit DJVistaMan (Client Quit) 03.58.54 Join CGL [0] (~CGL@190.207.188.162) 04.07.43 Join Barahir_ [0] (~jonathan@gssn-5f756a72.pool.mediaWays.net) 04.08.39 # something fishy is going on with memory 04.08.46 # someone with a fuzev2 handy ? 04.11.09 Quit Barahir (Ping timeout: 264 seconds) 04.11.23 *** Saving seen data "./dancer.seen" 04.12.52 Quit komputes (Ping timeout: 246 seconds) 04.23.20 # crap a full album played on Clip+ but clipv2 crashed fast 04.26.41 Quit pixelma (Disconnected by services) 04.26.41 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.26.51 Quit amiconn (Disconnected by services) 04.26.53 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.27.03 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.27.15 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.28.25 # 'prefetch abort at (some instruction, not a valid address)' 04.34.49 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 04.51.48 # the truth is out there... 04.54.04 Join chrisb [0] (~chrisb@pool-98-111-157-115.phlapa.east.verizon.net) 04.56.42 # i have this little cradle charger with an audio line-out for my sansa e250 04.57.21 # i'm running rockbox. when i plug the sansa in, there isn't any output on the audio line-out 04.59.08 # is that a dock which plugs on the USB port? 05.03.23 # found this http://www.rockbox.org/wiki/SansaFAQ#Do_the_Sansa_dock_and_remote_con 05.04.06 # my bad, no support 05.04.21 # funman: yes, it is a dock which plugs into the usb port on the bottom 05.04.56 # yeah it will likely not work, perhaps in the future if someone has the hardware, the dev skills and the motivation 05.05.02 # you'd better use the jack output 05.10.14 # funman: the cradle seems to cut out the jack output 05.10.23 # :( 05.10.40 Join RandomInsano [0] (~Edwin@wnpgmb0806w-ad07-62-231.dynamic.mts.net) 05.12.11 Quit Strife89|PalmTX (Quit: Bed.) 05.14.48 # So working on making a bootloader. Just editing the telechip's main() function. When I look at the code with objdump, I'm expecting to see some of my magic numbers (0x80003000 for PORTA) in the assembler code. Should they be in there directly or might GCC be mucking around with them? 05.15.20 # New commit by 03funman (r25754): as3525v2: crashless cpufreq switching ... 05.16.03 # RandomInsano: telechips is ARM, right? 0x80003000 could be calculated in 2 instructions instead of 1 load from memory 05.16.17 # It is arm. 05.16.44 # That might be entirely possible. I'm also setting everything to 0xFFFFFFFF and seeing nothing about 0xFFFF 05.16.44 # like, mov rX, #0x80000000 ... and rX, rX, #3000 05.17.01 # Interesting. I'll look for something along those lines. 05.17.29 # if you can't see the value with an hex editor, perhaps running grep on objdump output might help 05.17.30 # I'm extremely new to real assembler. My comp sci department uses the fake LC3 to teach that stuff 05.17.49 # I'm doing that exactly. Well, piping to less 05.17.51 # (afaik objdump sometimes use base 10, so be sure to grep for both representations) 05.18.23 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.19.01 # hum.. it won't help if this value is calculated on 2 instructions though. But I remember most of PP registers can be represented as an immediate value (8 bits + shift), so they show up in objdump output if mov is used 05.19.01 Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) 05.19.03 # That makes things trickier :( 05.19.39 # btw are you looking at OF code ? 05.19.54 # Bit of both, but this specifically is mine 05.20.06 # It doesn't *seem* to be working on my DAP. 05.20.25 # I'm putting all of PORTA high and when I test for voltages I get floating. 05.20.49 # void* main(void) 05.20.49 # { 05.20.49 # #ifdef TCCBOOT 05.20.49 DBUG Enqueued KICK RandomInsano 05.20.49 # int rc; 05.20.49 # unsigned char* loadbuffer = (unsigned char*)LOAD_ADDRESS; 05.20.49 *** Alert Mode level 1 05.20.49 # #endif 05.20.49 *** Alert Mode level 2 05.20.49 # // LCD uses PORTA, so there's lots of pins to check 05.20.50 *** Alert Mode level 3 05.20.50 # uint32_t* gpio_a = (uint32_t*)0x80003000; 05.20.50 *** Alert Mode level 4 05.20.50 # // Set b for output 05.20.51 *** Alert Mode level 5 05.20.51 # *(gpio_a + 0x4) = 0xFFFFFFFF; //0x1 << 18; 05.20.51 *** Alert Mode level 6 05.20.51 # while (1) 05.20.52 *** Alert Mode level 7 05.20.52 # { 05.20.52 *** Alert Mode level 8 05.20.52 # *(gpio_a) = 0xFFFFFFFF; //0x1 << 18; 05.20.53 *** Alert Mode level 9 05.20.53 # } 05.20.56 # hmm please use pastebins 05.20.57 # use a pastebin 05.21.05 # GAH! Pastebin, please! 05.21.07 # Good plan. 05.21.14 # Time to try this 'paste bin' 05.21.45 # btw, wouldn't (gpioa+4) be 0x80003010 ? 05.21.49 # http://pastebin.com/vtx59D5p 05.21.58 # Oh poop, you're right. 05.22.15 # Curse you decimal! 05.22.30 # it's not decimal, it's int32_t :) 05.22.34 # Wait no, I should be good. 05.23.25 # +4 should be 0x800003004 I would think. 05.24.02 # Well, in... Whatever. I know that the direction register is a 4 byte offset from the base of porta 05.24.38 # Also my comment is a tad outdated :P 05.26.24 # RandomInsano: no.. +4 skips 4 elements of whatever gpio_a points to, here it's an int32_t so it skips 4*4 bytes 05.26.26 # Everything looks okay. I have no idea if the firmware crashes before this point or what. I'm using a TCC77x chip as my base, but I assume none of it's initialization stuff runs before main() 05.26.33 # Oh crap! 05.26.36 # You're right 05.26.58 # first thing you need is some visual output: backlight or button light if it's present 05.27.05 # Coming from a 'java for everyone' university, I'm not to great with these pointers 05.27.28 # hope you can learn with rockbox :) 05.27.31 # Yeah, tried for backlight, turns out it's harder than I thought. So I can use my voltmeter to check for high output 05.28.14 # The anode and cathode seem to get power 100% of the time. I'm assuming there's a transistor nestled away somewhere. 05.30.02 # maybe i can boot into sansa os before docking... 05.30.54 *** Alert Mode OFF 05.31.38 # Does the rockbox scrobber have a built-in limit on the size the log can reach? 05.31.54 # Bah, changing 4 to 1 didn't fix my problem. 05.32.20 Quit S_a_i_n_t () 05.33.00 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.192) 05.33.51 # ALL GPIO TO ON! MWAHAHA! (here's hoping that works). 05.38.10 # Nope. Nothing :( 05.38.10 # Curse you... Telechips? 05.39.00 Quit Horscht (Quit: Verlassend) 05.46.04 Quit CaptainKewl (Remote host closed the connection) 06.10.51 Join BHSPitMini [0] (~BHSPitMon@pool-71-170-176-30.dllstx.fios.verizon.net) 06.11.27 *** Saving seen data "./dancer.seen" 06.13.27 Quit funman (Quit: free(random());) 06.13.29 # S_a_i_n_t: try the patch? 06.18.42 Quit CGL (Remote host closed the connection) 06.23.43 # JdGordon: Well, it's built...but I have to wait until I get home to actually test it on a device. 06.23.55 # I'll let you know when I have done so. 06.24.00 Quit elcan (Read error: Connection reset by peer) 06.29.56 Join elcan [0] (user36@pr0.us) 06.30.30 Part Boldfilter 06.40.45 Part RandomInsano 06.41.18 # http://pastebin.com/h23eU6qM <==Failed SIM build...any ideas anyone? 06.41.26 # Clean, brand new checkout... 06.49.15 # Blarggh!!! It happened again, after a "make veryclean" as well...A 'Normal Build' builds fine, but the SIM fails with those errors. 06.49.19 # WTF?!? 06.55.15 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 07.04.22 Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il) 07.16.42 # Any plans to have Rockbox display the album art contained within a FLAC file? Or perhaps that has been decided against? Nothing on the bug tracker. 07.17.21 # crculver: There *is* a patch on the tracker to display embedded AA 07.17.33 # not sure if it'll work with .flac though 07.18.02 Nick shaggy-h is now known as chrism (~kiwi@78-86-164-31.zone2.bethere.co.uk) 07.18.02 Nick chrism is now known as shaggy-h (~kiwi@78-86-164-31.zone2.bethere.co.uk) 07.19.00 # crculver: http://www.rockbox.org/tracker/task/11216?project=1&show_task=&order=dateopened&sort=desc 07.20.35 # crculver: At the present point, apparently it only supports .jpg files embedded in .mp3 07.31.52 # my playlists go into the root directory by default...how can i set up the default directory to be /PLAYLISTS ? 07.42.51 # chrisb: Open the config file (config.cfg) and change the path in there. 07.43.39 # chrisb: Add/Edit the line so it appears as "playlist catalog directory: /Playlists" 07.44.43 # you'll need to do this on your PC (well, you *can* do it on the DAP, but it's a lot easier to do it using your PC) using a text editor, Notepad is OK to use in this case. 07.44.44 # Can't you also just do it from the context menu when selecting that folder or something? 07.44.52 # Most options have a way to change them without editing config files 07.45.15 # Llorean: I *think* there's something like that, but I wasn't sure...so I went with the way I know. 07.47.31 # But, I think you're right...I believe you can just create a new .dir on the DAp, name it whatever you want, then bring up the context menu on it and select "Set as Playlist Directory" (or similar)...but I'm not 10% if that is the *exact* details, and I don't have a gadget I can check it on nearby. 07.47.53 # *100% (lol) 07.48.04 # chrisb: Well, check the context menu first. It could save you some effort. :) 07.51.36 # Hehehe...depending on your idea of "effort", I've personally always found the virtual keyboard a _nightmare_ to use (on the iPods at least) to use myself ;) 07.51.58 # I tend to delegate renaming things to a PC :) 07.52.05 # Yeah, but if you have a folder already, there's no vkeyboard use needed 07.53.10 # I imagine the virtual keyboard would be a LOT easier to use on touchscreen targets, but I've never had a chance to test that theory. 07.53.59 # S_a_i_n_t, Thanks 07.54.12 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 07.54.12 # * S_a_i_n_t nods 07.54.26 # Most of the album art I have embedded is hi res, though and this requires the image be less than 96 kb. 07.54.44 # But maybe it could be a starting point for FLAC support 07.55.18 # Setting up AA for Rockbox can be a daunting task...I'm fairly certain there are a few apps that can automate this task though. 07.57.22 # I believe Mp3Tag can run through a dir and extract embedded AA recursively 07.57.38 # theres been some discussion of that patch, but I see none of it was actually added to the patch 07.57.47 # perhaps unhelpful or kugel could add their thoughts 07.59.09 # * Unhelpful thinks that the issue ought to be fixable with the right implementation - a jpeg decoder with a hook to read the next bit of image data, imo. 08.05.50 Quit zivan56 () 08.09.09 Nick markun_ is now known as markun (~markun@rockbox/developer/markun) 08.11.28 *** Saving seen data "./dancer.seen" 08.13.10 # S_a_i_n_t, The whole point of embedding was to avoid the clutter of extra files 08.13.49 # yes, well...it all depends on wether or not you want AA in Rockbox really... 08.14.19 # there are several different naming/placement conventions...I'd suggest looking on the wiki to find one that suits you. 08.15.25 # It is *easy* to avoid "clutter" (visually at least) by just changing the file properties to "hidden" for all your AA...then you won't see them in the filebrowser on your DAP at least ;) 08.16.01 Join B4gder [0] (~daniel@rockbox/developer/bagder) 08.22.10 # S_a_i_n_t: thanks 08.22.49 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.24.43 # * JdGordon suddenly wonders if there is any point adding some "is showing a splash?" tags to the skin anguage and some extra suff so the splash viewport can be set in the .sbs 08.26.05 # S_a_i_n_t, If I can find the time, I'll look into extending the patch to FLAC 08.26.51 # JdGordon: I could dig that idea... 08.27.12 # that way a theme could have a designated "info area" 08.27.31 Join ender` [0] (krneki@foo.eternallybored.org) 08.27.32 # yeah, I'm not sure how it would work though... it might 08.27.43 # (one of those awesome ideas that only happen when on the can) 08.27.52 # ;) 08.28.00 # Of which there are many... 08.28.59 # I can send you some screenshots of my "fat cabbie" soonish...the battery and volume look awesome using the progressbar logic ;) 08.29.37 # especially as the reflections are there (and actually move with the battery/volume as well) 08.29.46 # *a nice touch I thought. 08.30.26 # cool 08.36.10 # * JdGordon needs to see what happens when splashes block 08.36.17 # using a simple conditional might be enough for this 08.39.25 Join flydutch [0] (~flydutch@host24-146-dynamic.15-87-r.retail.telecomitalia.it) 08.40.10 Quit elcan (Ping timeout: 264 seconds) 08.40.33 Join esperegu [0] (~quassel@145.116.15.244) 08.40.41 Join elcan [0] (user36@pr0.us) 08.42.38 # gevaerts: The h300 *could* do MTP as well, via the isp1362 08.42.52 # (full speed only though) 08.49.36 Join wodz [0] (~wodz@chello087206240004.chello.pl) 08.49.42 # amiconn: ping 08.54.50 # pong 08.55.42 # aa I got You :-) 08.55.52 # can I take You few minutes? 08.58.55 Quit BHSPitMini (Read error: Connection reset by peer) 08.59.41 # hmm I gues not :-/ 09.00.14 # wodz: it's better if you just ask what you want and then he can reply when he reads it and gets time to answer 09.00.29 # just higher latency conversation 09.00.52 # wodz: Don't ask to ask, just ask 09.00.56 # Am I understanding http://www.rockbox.org/tracker/task/11216 correctly, that it's stealing 96KB of the codec buffer, and using that to store the album art? 09.02.24 # * Llorean wonders why there's a limit on the bitmap size, or if that's just the existing limit. 09.03.00 # That also seems to be stored in the codec buffer. 09.03.26 # Isn't there already a place album art is stored, or is that to avoid reopening the file once playback gets to it? 09.03.41 # amiconn: I don't quite understand lcd_grey_data in lcd-as-m3.S 09.03.47 # linuxstb: I think it fread()s the image to a seperate buffer and then applies jpeg_decode_from_mem() to it. I don't quite understand the reasoning for that. Also, I'd think the image is already in rum due to metadata buffering 09.04.31 # what does numbers in comments regariding register content mean? 09.04.41 # pixels or what? 09.07.03 Join petur [0] (~petur@rockbox/developer/petur) 09.07.06 Quit BHSPitMonkey (Remote host closed the connection) 09.09.41 # Yes, those numbers refer to the pixels within that block 09.10.20 # at line 433 You have comment d5 = ........................01234567 than You duplicate the content to the upper byte in word of d3 and if You are done it is transfered with write_word 09.10.38 # The m3 asm is one of the most complex low-level greylib functions, because of the interleaved calculation and serial output 09.11.51 Join PRINCESS_FLUFF [0] (~princess@modemcable116.35-20-96.mc.videotron.ca) 09.12.12 # The duplication is necessary since the greylib works by using fully black or fully white pixels, but the m3's lcd controller is 2bpp 09.12.55 # amiconn: ok now I understand 09.13.03 # Is there a way (not too technical) to change the output volume for some plugins? When I listen to SPC music, the volume is about half as high as other songs. So I inevitably turn it up only to have my eardrums bleed from the next song if it's not an SPC file (spc = super nintendo music files) 09.13.31 # This is on a Sansa E200 btw 09.13.42 # amiconn: so basicaly I can loop this part of code right? 09.13.47 # Lines 437..439 do exactly that. 09.14.10 # Yes, since in your case the lcd controller is connected in parallel 09.15.15 # amiconn: how do I test if I do things correctly? Display some jpg or is there some more analitical test included? 09.15.24 # In case of the m3, I'm precalculating one word worth of pixels (lines 404..439), then outputting it bit by bit while calculating the next one in the main loop (444..543) 09.15.53 # ...and finally outputting the last word (reusing the tail from another routine) 09.16.47 # Displaying a .jpg should work as a test, however, you probably need to calibrate the lib for the hd200's lcd panel 09.16.59 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 09.17.00 Quit Zagor (Changing host) 09.17.00 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 09.17.16 # so I can use 404..439 to process one word, send it to the lcd and loop this until finished right? 09.17.43 # how do I calibrate? 09.17.43 # For this purpose there are two test plugins you need to build: test_scanrate and test_grey 09.19.08 # test_scanrate in turn needs a working lcd_blit_mono() 09.19.33 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 09.20.03 # and lcd_blit_mono needs working lcd_mono_data 09.21.37 # First, you run test_scanrate and increase/decrease the frequency until the black blob at the left stops, or nearly stops. Note down the frequency, then create an #elif section at the top of grey_core.c for your lcd, taking the m3 section as a basis 09.22.31 # Change the #define LCD_SCANRATE to the nearest HZ value of frequency you measured. 09.22.53 # Then rebuild the plugins, so test_grey will use the new value 09.24.37 # If you run test_grey, you'll see 9 rectangles in a black frame. With left/right you can change the grey level you're adjusting, with up/down you change the value 09.24.40 Join einhirn [0] (~Miranda@p54858B1B.dip0.t-ipconnect.de) 09.25.22 # The outer 8 rectangles are use ordinary ordered dither to approximate a level of grey, only the central one uses the actual greylib mechanism 09.26.14 # The goal is to adjust the center rectangle (with up/down) to match the brightness of the left, right, top and bottom rectangles at each of the levels 09.26.23 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 09.26.28 Join DerPapst [0] (~Alexander@dslb-088-069-149-077.pools.arcor-ip.net) 09.27.21 # In order to do this, watch the display in a not too bright environment, keep it away far enough so the dithering works (arm's length) and try looking exactly perpendicular (as contrast varies with angle) 09.28.05 # When finished, exit the plugin. It will write a result file to the root. This result file can then be used to create the lcdlinear[] array by using interpolation 09.28.24 # This step isn't automated yet..... sorry 09.29.00 # are all these steps documented somewhere? 09.29.51 # so the workflow is: 1) Implement lcd_mono_data 2) rework lcd_blit_mono() 3) compile test_scanrate 4) measure scanrate 5)adjust settings in grey_core.c 6) implement lcd_grey_data 7) rework lcd_blit_grey_phase 8) fiddle with test_grey 9) implement lcdlinear[] based on data from test_grey 09.30.37 Quit DerPapst (Ping timeout: 240 seconds) 09.30.51 Join DerPapst [0] (~Alexander@dslb-088-069-149-077.pools.arcor-ip.net) 09.36.27 Quit kugel (Ping timeout: 276 seconds) 09.37.40 Quit solexx (Ping timeout: 260 seconds) 09.39.13 Join solexx [0] (~jrschulz@e176101146.adsl.alicedsl.de) 09.39.34 Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) 09.39.47 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.39.54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.45.10 Quit crculver (Quit: Leaving) 09.49.32 Quit kugel (Remote host closed the connection) 09.56.03 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.09.38 Quit esperegu (Remote host closed the connection) 10.11.21 Quit chrisb (Ping timeout: 265 seconds) 10.11.30 *** Saving seen data "./dancer.seen" 10.16.21 Join esperegu [0] (~quassel@145.116.15.244) 10.24.20 # amiconn: I have some doubts how lcd_mono_data is supposed to work. You take first byte of data (LSB of 8 pixels strip) and duplicate it to the upper byte in the word, than You do the same with the second byte. Doesn't this mean You produce twice as much data as needed by lcd? 10.26.37 Quit einhirn (Read error: Connection reset by peer) 10.27.16 # hmm probably not, nevermind 10.28.24 # http://imgur.com/CQQdr.png <-- Cabbie + Fat == "Flabbie"? 10.29.03 Join liar [0] (~liar@212067227007.public.telering.at) 10.30.22 # Comments on that theme screenshot are welcome, I have only just finished sticking it together now. ;) 10.31.29 # I like it 10.31.42 # good for landscape targets 10.32.33 Quit hebz0rl_ (Quit: Ex-Chat) 10.32.38 # it's 176x132 at the moment (Nano 1/2g), but I could be convinced to make versions for other targets also. 10.32.51 Join hebz0rl [0] (~hebz0rl@dslb-088-067-199-149.pools.arcor-ip.net) 10.33.30 # well, I'm using widecabbie on my sansa e200, because I like the volume level that appears when you change volume 10.34.18 # I think it's something every wps should have ;) 10.35.08 # Normally I'd do something like that...but in this case, the volume/battery use the logic from the progressbar, if I did that you wouldn't see the nice, smooth-scrooling volume icon ;) 10.35.25 # *scrolling 10.46.49 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 10.47.30 Quit shai (Disconnected by services) 10.47.33 Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il) 10.49.24 Quit wodz (Quit: Leaving) 10.57.32 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.31.33 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 11.48.25 Join Kamyk_ [0] (kamyk@szluug.org) 11.48.28 # hello all 11.48.52 # i have Philips Go Gear SA3085/02 - is it rockbox will work on it? 11.49.36 # look at www.rockbox.org to figure out 11.49.53 # only explicitly listed devices are supported 11.50.29 # wodz: There is no repeated duplication, just one duplication per source byte, in order to convert mono data into lcd format 11.50.55 # i don't find my mp3, but itis any possible to upgrade my mp3 in future? 11.52.43 # amiconn: I missread the code - I was thinking that lcd_mono_data takes data in lcd native format not b&w 11.53.13 # There's a reason why it has 'mono' in its name :) 11.54.44 # :-) 11.55.22 # I am just uploading new firmware and test plugins to try test_scanrate 11.55.40 Quit tchan (Read error: Connection reset by peer) 11.55.44 Quit phanboy4 (Read error: Connection reset by peer) 11.56.07 # Kamyk_: it's always possible. Someone (who has such a player or wants to buy one) has to volunteer to work on it. 11.57.05 # what is the scanrate for M3? 11.57.53 # Kamyk_: some info: http://www.rockbox.org/wiki/NewPort 11.58.03 Join _arbingordon [0] (~w@c-68-44-148-113.hsd1.pa.comcast.net) 11.58.31 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 11.58.33 Quit _arbingordon (Client Quit) 12.00.05 Quit BlakeJohnson86 (Ping timeout: 265 seconds) 12.00.20 Quit arbingordon (Ping timeout: 276 seconds) 12.00.21 Join _arbingordon [0] (~w@c-68-44-148-113.hsd1.pa.comcast.net) 12.00.25 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 12.01.38 # amiconn: how should change the black blob in test_scanrate when changing frequency? 12.03.18 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 12.07.36 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 12.09.50 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 12.11.32 *** Saving seen data "./dancer.seen" 12.12.10 Join newuser [0] (~474b45aa@giant.haxx.se) 12.12.40 Join watto [0] (~watto@193.203.81.165) 12.15.15 # hello? 12.16.00 # i was wondering if someone could help me with something 12.16.39 # newuser: just ask :) 12.16.54 # it that something is something I can help maybe I will help :-) 12.17.03 # s/it/if/ 12.18.02 Quit phanboy4 (Ping timeout: 258 seconds) 12.18.30 # i am trying to install rockbox on my sansa e250 12.18.39 # i am running ubuntu 9.10 12.18.39 Join b0hoon [0] (~quassel@62.87.184.82) 12.18.56 # it won't let me install - says permission denied when i try to install bootloader 12.19.12 # Are you using Rockbox Utility? 12.19.26 # can't figure out how to run install utility with elevated privs 12.19.27 # linuxstb: Unhelpful: (others), uuchan can in IRC a few days ago and bassically said that replies should go in the tracker because he cant come in IRC often 12.19.27 # yeah 12.19.31 # probably You have to be root 12.19.52 # yeah 12.20.01 # newuser: sudo 12.20.07 # yeah 12.20.18 # i am in the directory, type "sudo RockboxUtility" 12.20.23 # and it says that is not a command 12.20.42 # sudo ./RockboxUtility should do 12.20.50 # ... 12.20.51 # haha 12.21.02 # i am an idiot and just spent 2.5 hours 12.22.02 # every time with ubuntu i spend hours just to learn i need a period here, a slash there 12.22.06 # thanks guys! 12.23.46 # it works! awesome! thanks again! 12.23.48 # :-) 12.24.49 # JdGordon: Yes, I agree someone needs to say something on that task. I don't really know what to suggest to uchan, apart from saying that his patch looks to be doing things completely wrong... 12.24.53 # Hi, it looks like Rockbox runs well on the Vibe 500, has a complete manual and is supported by the installer :) 12.25.13 # I would like to propose to jump with it to the stable section. 12.26.04 # linuxstb: yeah, I agree that stealing the codec buffer just looks wrong 12.26.15 # * JdGordon suggests smoeone comment in the task 12.27.20 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 12.27.36 # New commit by 03jdgordon (r25755): centre splashes inside the UI viewport instead of the whole screen. Fixes the flickering statusbar issue and saves alot of fullscreen clears 12.28.30 # JdGordon: which tasks ? 12.28.49 # 11216 12.29.53 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 12.30.26 # b0hoon: So all the necessary bootloader/installation binaries released ? I don't know what's been done in the past (or if people agree with this), but maybe "stable" should mean that there is an official (3.x) release for that device. So it can be made stable on the day of the next release. 12.32.08 # linuxstb: yes, there is a bootloader file on the server and the installation works through the RBUtility. 12.32.55 # JdGordon: I don't really know that part of the code but stealing the codec buffer is just not possible, we can't have code that keep stealing buffers this way or it will become impossible to follow. There are sufficiently many stealing hacks in the code right now :) 12.33.44 # indeed 12.33.44 # linuxstb: don't know how the ports are accepted to the stable state, so that's why i'm asking. 12.35.50 # b0hoon: http://www.rockbox.org/wiki/TargetStatus#Current_status_of_supported_targ 12.36.02 # Gives the criteria more or less 12.36.08 # b0hoon: Did you release the bootloader? I can't see it tagged in svn. 12.36.39 # http://www.rockbox.org/wiki/TargetClassifications also 12.37.06 # kugel: Ah, that's a good one 12.37.59 # b0hoon: Also, did you build the bootloader with a version number, or just the SVN revision? 12.38.05 # New commit by 03jdgordon (r25756): fix red 12.38.06 # * linuxstb should document a bootloader release process... 12.39.03 # hmm i guess i forgot to tag the bootloader, i've just sent it to Zagor but it is some build from my svn. 12.39.37 # b0hoon: It needs a release version number too, not a SVN revision :) 12.39.51 # ah, linuxstb already said that 12.41.02 # linuxstb: yeah, it would be good, cause i don't know what really what to do. I guess that i must tag it somehow as a version 1.0 and then upload it to the server again? 12.42.02 # b0hoon: You just need to build it with "make VERSION=1.0" (I think...) and then tag - the UsingSVN page should tell you how to tag. 12.42.07 # http://www.rockbox.org/wiki/UsingSVN#Tagging_releases 12.44.50 # * linuxstb adds a short comment to http://www.rockbox.org/tracker/task/11216 12.45.41 # * JdGordon got in first with a shorter one :) 12.45.45 Join matsl [0] (~matsl@94.136.75.10) 12.46.44 # Ah flyspray doesn't have the useful "someone else has just replied" warning the forums do... 12.50.46 # wodz: M3 has 150Hz scanrate, as you can see at the top of test_scanrate.c 12.52.20 # Also I forgot to mention something: If the scanrate is very high, and the update function is slow (like it's the case with M3), you may use a fractional update frequency in the greylib 12.53.33 # Scanrate: 150Hz, update frequency: 50Hz; otherwise the update would draw too much cpu power (due to the serial transfer) 12.54.08 # On the MPIO this is probably unnecessary (and if it also has 150Hz scanrate, greylib will probably work very well) 13.00.50 Quit kugel (Remote host closed the connection) 13.02.02 # amiconn: Do I understand correctly that I should find frequency that black blob doesn't change colour? 13.02.20 # I mean no moving strips or something 13.02.34 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 13.02.36 # The black blob should never change colour. If it does, you're very far off with the frequency 13.03.03 # so what effect should I see when f is ok 13.03.17 # It should stop (or move as slow as possible, since the smallest step is 01.Hz), being fully black on fully white background 13.03.42 # It shouldn't be grey or flickering 13.03.51 # aa ok 13.03.52 # Err, 0.1Hz 13.04.58 # amiconn: could You look at this: http://pastebin.com/sEpGq5Rb 13.05.06 # does it look ok for You? 13.07.42 # and this: http://pastebin.com/nvtsnJdF 13.10.32 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 13.14.57 Quit mikroflops_ (Ping timeout: 264 seconds) 13.23.22 # wodz: Looks good 13.25.39 # at f=145.3 the blob sloooowly dimms and comes back again 13.28.57 Quit newuser (Quit: CGI:IRC (EOF)) 13.35.22 Quit robin0800 (Remote host closed the connection) 13.37.04 # linuxstb: ok, thanks. 13.41.45 Join neonesis [0] (~jkosidlo@212.182.71.178) 13.51.52 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 13.55.01 # amicon: This is the simples form of lcd_grey_data I think, but doesn't work http://pastebin.com/0PyU2Vyb 13.56.59 # and http://pastebin.com/wu6KDKF1 for completnes 14.09.27 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.11.35 *** Saving seen data "./dancer.seen" 14.14.38 Join MethoS- [0] (~clemens@134.102.106.250) 14.15.39 # It dims and comes back? That's not how it's supposed to be 14.17.47 # does it shoud run up/down or left right when unsynced? 14.18.25 # That depends on how the panel is controlled. On most targets it runs up/down. On the M3 it runs sideways 14.18.44 # hmm 14.18.47 # If that's the case on MPIO as well, you should set the appropriate #define in test_scanrate 14.18.48 Join Schmogel [0] (~Miranda@p3EE22D35.dip0.t-ipconnect.de) 14.19.18 # (it will change the orientation of the "blob strip" on the screen to horizontal) 14.20.41 # hmm we will see 14.34.55 # * S_a_i_n_t wishes that the "line selector" used magenta as a "magic colour" for transparency also... 14.36.56 # So that I could use text colour as the sole visual reference for selection. An effect the theme I'm working on now could do with. 14.39.32 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 14.39.38 Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 14.39.52 Quit advcomp2019 (Read error: Connection reset by peer) 14.39.52 Quit evilnick (Read error: Connection reset by peer) 14.39.52 Quit Rob2222 (Read error: Connection reset by peer) 14.39.52 Ctcp Ping from gevaerts!~fg@rockbox/developer/gevaerts 14.39.59 Join Rob2222 [0] (~Miranda@p4FDCA468.dip.t-dialin.net) 14.40.13 # At the moment, it is possible to do this effect, but only if your backdrop is a solid colour...if you have a gradient effect (or anything else other than solid colour actually) in your backdrop this effect won't work. >:( 14.41.34 Part b0hoon ("Back to work.") 14.43.48 # can't you use the pointer selector with line text colour? 14.44.34 # pixelma: If I wanted to use the pointer...then, yes. 14.45.10 # Well, actually...no, you can use the pointer *or* the line selector, and only change the text colour with the line selector. 14.45.42 # the pointer also annoyingly offsets the icons. 14.48.16 # pixelma: Yes, just checked up on that now. You can't change the text colour with the pointer, only with the line selector. 14.48.49 # My desired effect would be to just use the text colour (or the change in text colour rather) as the "selector". 14.48.59 Quit liar (Quit: Verlassend) 14.49.13 # should be trivial to implement 14.49.39 # Implement away, good Sir. ;) 14.50.22 Quit adnyxo (Ping timeout: 276 seconds) 14.50.48 Quit B4gder (Quit: It is time to say moo) 14.50.52 # I figure all it needs is to accept magenta as a "magic" colour as well...I doubt many people will want a solid-bright pink line selector ;) 14.50.59 # ...but I may be wrong. 14.57.16 Join geertvdijk [0] (~chatzilla@5ED780FA.cable.ziggo.nl) 14.58.32 # hey all, just updated rockbox to current build again on my sansa, and noticed now that when the screen goes dark after a minute, and you then plug in your headphones (without touching buttons or turning wheels), it wakes up. any plans for pause on unplug/resume on plug? 15.00.07 # it's an e200 btw, might that be of any importance 15.01.27 # I'd say it will almost certainly be implemented at some stage... 15.01.46 # When however, would be impossible to predict. 15.02.20 Quit Battousai (Remote host closed the connection) 15.02.33 Join Battousai [0] (~bryan@gentoo/developer/battousai) 15.02.33 Quit antil33t (Read error: Connection reset by peer) 15.02.40 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.03.08 # S_a_i_n_t: would it be hard to implement? I mean, could a semi-experienced developer hack it in using some code from the media control found in plugins now in place of the headphone-detection wakeup? 15.04.12 # No idea sorry... 15.04.21 # geertvdijk: if the hardware can do it (and from what you say it might well do), it should simple. We do have pause on unplug on some devices 15.04.59 # gevaerts: thanks, I'm going to look into it tonight when I get home. don't expect to be able to do much, but I just might. any idea in which files I should look? 15.05.33 Quit neonesis (Remote host closed the connection) 15.06.10 # geertvdijk: start by looking for HAVE_HEADPHONE_DETECTION. Possibly some GPIO debug screen can be helpful too 15.06.56 # geertvdijk: I'm not aware than any of the sansas the feature you're describing 15.07.08 # +have 15.07.19 # kugel: neither was I, but I thoroughly tested it as it really surprised me. 15.07.23 # gevaerts: will do, thanks. if I find out anything and/or need some help i'll get right bakc here :) 15.07.33 # -but +so 15.07.33 # what sansa? 15.07.42 # e250v1, no fm radio 15.08.28 # geertvdijk: if you find a GPIO pin that does this, you only need to implement headphones_inserted() basically 15.09.34 # gevaerts: that does sound like something I could do, as long as there's other devices that do it already ^^ 15.10.58 # ok 15.11.19 # this is really odd now, it now does it only sporadically, and I'm making sure each time I check that I'm not accidently touching any buttons/sd cards 15.12.16 # kugel: magenta for that might not be so trivial 15.12.48 # * JdGordon doesnt think using text colour as the selection thingy would work so well 15.13.17 # geertvdijk: concentrate on the GPIO debug screen, if the e200 has one (which it probably does) 15.13.24 # just disable selector drawing completely if the bar color is the magic color 15.13.47 # Blargh! mumble something, conflicting opinions..., mumble 15.13.47 # yes I just went ahead and plugged and unplugged the headphones concentrating on each individual value of the i/o ports screen 15.14.14 Quit advcomp2019_ (Read error: Connection reset by peer) 15.14.23 # FWIW, if you're using a solid background colour...text colour as the selector is quite effective. 15.14.39 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 15.14.45 # New commit by 03wodz (r25757): HD200 - add FM support. 15.16.39 # S_a_i_n_t: have you actually tried a solid selector bar with that colour? 15.16.49 # yep. 15.17.00 # It's pink, not transparent as I'd expected. 15.18.17 # transparency might give some nice effects if used with gradient bars (and implemented properly) 15.18.46 # gevaerts: so far nothing, but there seem to be more values listed than fit on the screen. do you happen to know if these are all ADC-related things (as the last fully visible ones are)? 15.19.09 # no idea 15.20.18 # adding trancparency will slow it down a fair bit ownt it? 15.20.59 # I doubt 15.21.36 # it doesn't really matter if you mix two predefined patters or 1 predefined pattern with the background color 15.21.39 # lcd_fillrect() cant do a simple memcpy() or memset() if that were added 15.22.25 # that is done on the area, then the text is added 15.22.31 # it can memcpy from the background color, memset might not be possible. but you usually cannot use mem* 15.22.42 # on color targets anyway since a pixel is more than 1byte 15.23.22 # it is passed in a fb_Data* so you can 15.24.06 # oh no its not 15.24.46 # * JdGordon is too tired to try understanding lcd driver code 15.36.19 # Dammit...some changes to lib/viewer.c makes FS#6697 compile witha *bunch* of errors...far beyond my comprehension. Which is a crying shame, as it is by far better than dict,rock, "by far better" is probably an underestimation... 15.39.35 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 15.39.58 Join CGL [0] (~CGL@190.207.188.162) 15.42.23 # is there an SVN command to automagically remove .rej .orig files etc? 15.42.56 # find is your friend I would say 15.43.16 # I realise that they *shouldn't* make a difference, but it'd be nice to be able to clean up my tree without killing it and checking out again... 15.43.37 # svn stat, awk and rm can help 15.43.54 # wodz: I was hoping for a more automated soultion...I was kinda hoping "svn revert" would take care of them actually...but, nope. :( 15.44.14 # S_a_i_n_t: what's not automated about find? 15.44.32 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.45.04 # gevaerts: there's no way of knowing if the .orig file is in use currently or not. 15.45.19 # removing all of then may bot be the bast of ideas. 15.45.26 # *not 15.45.31 # *best 15.45.45 # S_a_i_n_t: well, use svn stat and awk then :) 15.46.10 Quit bmbl (Ping timeout: 258 seconds) 15.46.10 # * S_a_i_n_t has no idea of those two functions... 15.46.18 # I'm a themer..gimme a break ;) 15.47.12 # what is the output of "svn stat" telling me? 15.47.27 # is that the list of files *not* in the checkout? 15.47.44 # no .orig files are in use, they're always left over from not applying patches 15.48.11 # Aha...good to know. 15.48.26 # As for 'svn stat'? Am I correct in that assumption? 15.48.52 # S_a_i_n_t: it's the list of files that's different from the repository. The first two characters tell you what 15.48.55 # 's different 15.49.22 # gevaerts: they all have a "?" in front... 15.49.40 # That means they're all not in the repository 15.50.15 # so, if I removed them *all*, it would be a "clean" checkout again? 15.51.04 # "svn diff" comes back ok...I'm just not a fan of leftover files. 15.51.08 Quit hebz0rl (Ping timeout: 268 seconds) 15.51.26 Join hebz0rl [0] (~hebz0rl@dslb-088-067-199-149.pools.arcor-ip.net) 15.51.58 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 15.52.52 # S_a_i_n_t: 'svn status' will tell you if you have unversioned files in your tree (marked with '?') 15.53.32 # You can delete all of them if you don't need them anymore 15.54.00 # Is someone able to give me a command using 'svn stat' and 'rm' that will just kill then all in one fell swoop? 15.54.06 # * S_a_i_n_t often bash fails... 15.54.13 # If you have your build dir(s) in the same tree (like me), that will come up as unversioned too, of course 15.54.34 # I do, but that is no loss if I delete those. 15.55.04 Join Gyuri [0] (~bd196e85@gateway/web/freenode/x-tzdilmmeogfyytwq) 15.55.13 # S_a_i_n_t: Do any of your files have spaces in the filenames? 15.55.17 # amiconn: something like for file in $(svn status | awk '{if($1=='?') print $2}'); do rm $file; done (untested) 15.55.27 # (if you have no spaces in the filenames) 15.55.38 # linuxstb: Yep, I guess that's a problem... 15.56.04 # S_a_i_n_t: No, it just makes the script a little trickier... 15.57.16 # S_a_i_n_t: Maybe something like: svn st | awk '/^?/ {print substr($0,8)}' | (while read a ; do echo "$a" ; done) 15.57.27 # Replace "echo" with "rm" when you're happy it's doing the right thing 15.57.36 # * linuxstb expects there are 50 other ways to do that 15.58.25 # amiconn: I hanged definition in test_scanrate.c. Now I have horizontal strip. Depending on frequency it flickers more or less until around 146Hz where it stays black and very slowly changes colour but not line by line (some irregular pattern) 15.59.14 # linuxstb: THANKS!!! 15.59.31 # amiconn: Maybe I will record video how it looks tomorrow and than You will tell if this is correct 15.59.40 # it couldn;t remove the (empty) build dirs for some reason...but otherwise worked like a charm ;) 15.59.55 Part Gyuri 16.00.02 # * S_a_i_n_t adds this to an alias immediately. 16.00.13 # S_a_i_n_t: If you want to remove empty directories, just do "rmdir *" - that will fail if any of the directories have anything in. 16.00.38 # (but succeed with any empty ones) 16.00.48 # * S_a_i_n_t always thought that was kinda silly... 16.00.55 # S_a_i_n_t: learn a bit of "awk", that's really handful for that kind of stuff 16.01.05 # *not being able to delete non-empty dirs 16.01.07 # the man of awk is well done also 16.01.43 # * linuxstb drags this to -community 16.04.32 # how to add something to front page of rockbox? 16.05.04 # wodz: Checkout the www module in svn, commit your change, and then ask Bagder or Zagor to update the site. 16.05.22 # I see 16.06.16 Quit Hillshum (Ping timeout: 245 seconds) 16.10.41 Quit wodz (Quit: Leaving) 16.11.38 *** Saving seen data "./dancer.seen" 16.12.28 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 16.12.44 Quit Zagor (Quit: Clint excited) 16.16.28 # * kugel wonders how to replace sdl drawing 16.18.22 Quit JohannesSM64 (Max SendQ exceeded) 16.20.09 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 16.20.44 Quit JohannesSM64 (Max SendQ exceeded) 16.22.01 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 16.31.17 Join Schmo [0] (~Miranda@p3EE22D35.dip0.t-ipconnect.de) 16.35.00 Quit Schmogel (Ping timeout: 245 seconds) 16.35.14 Quit flydutch (Quit: /* empty */) 16.45.12 Quit ender` (Quit: As a computer, I find your faith in technology amusing.) 16.45.25 Quit matsl (Ping timeout: 245 seconds) 16.46.17 Quit jfc^2 (Remote host closed the connection) 16.49.23 Quit kugel (Read error: Operation timed out) 16.49.24 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 16.51.03 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.51.17 Join ender` [0] (krneki@foo.eternallybored.org) 16.54.29 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.58.15 Quit kugel (Remote host closed the connection) 17.00.29 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 17.03.18 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 17.13.37 Join mt [0] (~chatzilla@41.91.195.18) 17.14.53 # New commit by 03mt (r25758): Revert r25739 which added libwmapro to apps/codecs, in preparation to commit the unmodified ffmpeg files first, for the sake of a consistent/complete ... 17.21.08 Join elinenbe [0] (~d1c4c008@giant.haxx.se) 17.23.21 Quit hebz0rl (Ping timeout: 276 seconds) 17.25.03 # Bagder: are you here? 17.25.45 Join hebz0rl [0] (~hebz0rl@dslb-094-217-139-239.pools.arcor-ip.net) 17.29.57 Join jfc [0] (~john@dpc6682208002.direcpc.com) 17.37.15 Quit lpereira (Quit: Leaving.) 17.46.30 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 17.49.45 # * linuxstb looks around the wiki for SoC pages... ;) 17.51.03 Quit mt (Ping timeout: 276 seconds) 17.52.34 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 17.54.46 # Is there a way for plugins to separate their headers and .c files? I'm trying to build flite under Rockbox's build system but mkdepfile seems very confused by the dir structure and insists that there should be a $(BUILDIR)/.h file. 17.56.19 # archivator: You mean put the .c and .h in different subdirectories? 17.56.23 # The original Makefile basically adds an -I$(FLITE_TOP_DIR)/include to every gcc invocation. 17.56.27 # linuxstb: yes. 17.57.06 # archivator: Probably not. I expect you would need to write your own makefile 17.57.19 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.57.45 # Where in Rockbox are you planning to put the code though? 17.58.03 # linuxstb: under plugins/ for the moment 17.58.21 # first get it to work at all I guess? 17.58.52 # I guess it will always be built as some kind of plugin though? 17.59.01 # (even when integrated into the core) ? 17.59.02 # gevaerts: get what to work? I can't get it to build since mkdepfile is confused by #include "flite.h" statements where flite.h is not next to the .c file 17.59.37 # archivator: I mean, that's what you're trying to achieve by building it as a plugin first 17.59.38 # linuxstb: part 1 is making it a plugin, so that I have something to test out and work on. Part 2 is porting it to the core 17.59.49 # Ah, sorry, I misunderstood. 18.01.07 Quit pamaury (Quit: Quitte) 18.01.46 # archivator: Which makefile did you copy for "flite.make" ? 18.02.12 # linuxstb: pdbox.make since it allows for extra compile flags 18.02.52 # Have you tried adding -I there? 18.02.57 Quit petur (Quit: *plop*) 18.02.59 # linuxstb: won't work 18.03.04 # linuxstb: it breaks long before that - the dep file is all wrong 18.03.16 # The dependency generation doesn't use flags in the SUBDIRS makefiles 18.04.38 # gevaerts: Yes, I'm just catching up.... (reading plugins.make) 18.04.42 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.05.34 # * gevaerts found out about this when working on r24916 18.05.43 # * linuxstb assumes the flite source code is more than a handful of files.... 18.06.20 # archivator: Maybe Zagor has some ideas - this build system is mostly his work... 18.06.26 # linuxstb: you assume rightly, about 100 files total 18.07.42 # archivator: Did you also say that flite voices are compiled as code? 18.07.48 # gevaerts: Did you get any further with your "pebbles" idea? Or is that just dead in the water now? 18.08.04 # linuxstb: correct 18.08.38 # archivator: Does flite offer loadable voices, or are they all compiled into a big binary? 18.08.43 # S_a_i_n_t: yes and no :) 18.09.21 # gevaerts: Yes, you've got further, and no, it's not dead in the water? 18.09.41 # linuxstb: usually, they're statically linked into a binary blob but it shouldn't be *too* difficult to compile them for a specific address and load them on demand 18.10.12 # The general idea is still there, but the particular approach is dead in the water 18.10.36 # right...gotcha. 18.11.00 # If it were a bigger job, it would/could have made a nice GSoC project. 18.11.23 # Maybe archivator will squeeze it into his project... ;) 18.11.37 # * S_a_i_n_t wants to be able to use a demo in his WPSes for cases where there is no AA ;) 18.11.41 *** Saving seen data "./dancer.seen" 18.11.48 # S_a_i_n_t: it's big enough I think, and it is on the ideas list! 18.12.09 # * S_a_i_n_t stares at archivator then ;) 18.12.10 # linuxstb: well, if anyone makes a relocatable loader, that would come in really handy. 18.12.49 # * archivator bows his head in shame 18.12.58 # * S_a_i_n_t attempts to "Jedi Mind Trick" the GSoC students... 18.12.59 # I'm afraid that sorta stuff is out of my competence 18.13.09 # To work well it also needs the buflib work 18.13.28 # S_a_i_n_t: you should have done that earlier! Projects have been selected now 18.13.52 # Maybe I should have asked this earlier, but what's the point in TTS in the core? Is the intention to replace the voice files and talk clips? 18.14.02 # "These are not the droids you're loo...I mean, write pebbles.rock" 18.15.01 # linuxstb: I was wondering that also...I *believe* that is the goal? 18.15.14 # *removal of .voice .talk files 18.15.18 # linuxstb: ultimately, yes. In practice, desktop engines offer far wider language support. 18.15.20 Quit geertvdijk (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 18.15.35 # archivator: And better quality... 18.15.44 # For now, removing .talk files for English, adding voicing to plugins/database, that kinda thing. 18.15.55 # Announcing the artist/track, too :) 18.16.07 # Basically voicing everything that currently isn't 18.16.12 # That could also be achieved with talk clips though. (the database) 18.16.36 # Or maybe not easily... 18.16.44 # linuxstb: right, and the moment you change a single tag, you'd need to re-voice everything 18.17.09 # Well, not *everything*, but it'd be rather hard to maintain 18.17.14 # It's a tradeoff I think. Regenerating talk clips every time isn't that wonderful 18.17.24 # Announcing track info in the wps would be cool, also volume, anything that changes really...awesome. 18.17.42 # * S_a_i_n_t sends good vibes archivator's way. 18.17.52 # If I'd use voice, I guess I'd prefer voice clips for the menus and TTS for track info 18.18.28 # * linuxstb wonders what happened to midgey's work on voicing plugins 18.18.41 # linuxstb: wasn't that just translating? 18.18.48 # Or was it both? 18.18.52 # * gevaerts doesn't remember 18.19.02 # gevaerts: Hmm, I'm not sure... 18.19.06 # * S_a_i_n_t *thinks* it was both... 18.19.15 # *but, isn't sure either. 18.19.15 # In any case, the general consensus is that my current situation with the dependencies can't be fixed quickly, correct? 18.19.40 # archivator: I think the current consensus is that no-one who is here can fix it quickly... 18.20.06 # archivator: the easiest way to get it working would be to use full relative paths in the include statements I think 18.20.17 # Not good in the long term of course 18.20.37 # gevaerts: can't I just add an EXTRADEPINCLUDES in the Makefile and add that to mkdepfile? 18.20.56 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.21.18 Join lifeless_ [0] (~lifeless@188.18.86.72) 18.25.44 Quit lifeless__ (Ping timeout: 265 seconds) 18.27.08 # archivator: Just in case you don't know it already, "make V=1" is helpful. 18.28.35 # linuxstb: didn't know about that but it doesn't really help in any way. Thanks, though. 18.37.30 Join abc [0] (~586c3898@giant.haxx.se) 18.39.03 Quit abc (Client Quit) 18.42.59 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 18.45.01 Quit Schmo (Read error: Connection reset by peer) 18.48.20 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 18.48.42 # archivator: the problem I think is that all dependencies are done in one go, so that would add those includes to all C files 18.50.23 # gevaerts: would it? from what I can see, mkdepfile calls gcc with the -MM and -MG parameters. Building on that, if I add an -I to the call, it should resolve the header files properly. Or am I missing something fundamental? 18.50.46 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 18.51.38 Quit elinenbe (Quit: CGI:IRC (EOF)) 18.52.50 # archivator: you could try. I suspect it's not that simple though 18.58.20 Quit Luca_S (Quit: CGI:IRC (EOF)) 19.01.43 Join ATTIKIT [0] (~1875bf37@giant.haxx.se) 19.04.21 # gevaerts: turns out, it *is* that simple. Good news is it works. Bad news is it's ugly and hacky. 19.04.49 # archivator: you're sure it doesn't influence other code at all? 19.04.50 Quit ATTIKIT (Client Quit) 19.05.15 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 19.05.46 # I thought miidgey added a patch to the tracker with as far as he came. I don't know what the question "wasn't it just translating" means 19.06.27 # gevaerts: if by influence you mean "add flite headers to every single file's dependencies list", then no. That's as far as it goes right now since it doesn't really compile :) 19.06.55 # ok then. That's reasonable I think 19.07.51 # in this context, I mean. I sure can translate it literally 19.11.21 Quit shai (Read error: Connection reset by peer) 19.11.33 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.11.53 Quit Utchybann (Ping timeout: 276 seconds) 19.12.27 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 19.13.24 Quit DerPapst (Quit: Leaving.) 19.17.37 Quit JohannesSM64 (Ping timeout: 240 seconds) 19.19.18 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 19.21.10 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.21.58 # gevaerts: do you think I should paste what I wrote in my application to the wiki page? 19.24.18 # I'm a tad bit worried I might fail through the final evaluations if I happen to not manage a complete port (without SDL) to a mobile device, even though that's not the primary objective 19.25.14 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 19.27.07 # Upon further investigation, the build fails exactly where it should - at the first call to malloc. Awesome. 19.27.43 # you could link tlsf malloc from the codec lib 19.27.57 # (for now, malloc is a nogo for the core) 19.28.21 Join Silverwolf [0] (~9e500802@giant.haxx.se) 19.29.16 # kugel: there's also dbestfit in pdbox.. 19.29.35 # I just registered on the Wiki, under the name RichardNease, and I'd like to have write permissions so I can add to the Wiki 19.29.40 # didn't pdbox switch to tlsf as well because there were problems with dbestfit? 19.29.53 # that's what I seem to remember from last year 19.31.13 # kugel: no idea, I only saw that it used dbestfit at some point in the past.. 19.33.59 # I might work on relocatable plugins for the next year's gsoc 19.34.04 Quit Silverwolf (Quit: CGI:IRC) 19.37.06 Join panni__ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 19.37.08 Quit panni_ (Read error: Connection reset by peer) 19.38.53 # kugel: maybe copy the actual technical content but leave out the milestones and dates for now? They should be there in a few weeks of course, but I think it's important to be able to start technical discussions as soon as possible 19.39.47 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 19.40.06 Join Kitr88 [0] (~Kitar_st@BSN-176-234-181.dial-up.dsl.siol.net) 19.40.34 Quit panni__ (Read error: Connection reset by peer) 19.41.26 # gevaerts: right, I'll do so very soon 19.41.47 # gevaerts: what I wondered, if anyone has tried to use rockbox' own threads when running the sim on an arm device 19.42.08 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.42.08 # probably not I guess 19.42.29 # kugel: when you tried the sim on your mini2440, was that with X on it? 19.42.42 # it really bugs me that I can't manage to get it running on my mini, I highly suspect I'm simply OOM even though I think 50MB free ram should be plenty 19.42.58 # I will buy a bigger sd card and setup a swap partition 19.43.18 # gevaerts: no, I also can't get X to run :\ 19.43.25 Quit Kitar|st (Ping timeout: 246 seconds) 19.44.39 # kugel: my latest plain unmodified svn sim crashes on my phone somewhere in unicode.c... 19.44.50 Quit Kitr88 (Ping timeout: 268 seconds) 19.45.37 # very strange 19.46.16 Quit Xerion (Ping timeout: 252 seconds) 19.46.17 Join Kitar|st [0] (Kitar_st@89.142.75.116) 19.46.50 # I'll do some debugging 19.48.34 # gevaerts: I meant to ask you if you have some tips on getting some useful qemu image(s) 19.49.57 # hm, not really. My qemu setup is a scratchbox thing, probably not ideal for what you're doing 19.56.19 Quit archivator (Quit: Leaving) 20.00.59 # I have no experience with qemu at all :\ 20.01.36 # * gevaerts decides to have a go at http://www.aurel32.net/info/debian_arm_qemu.php 20.02.00 Join DerPapst [0] (~Alexander@p4FE8FAD0.dip.t-dialin.net) 20.02.01 Join RichardNease [0] (~9e500802@giant.haxx.se) 20.02.48 # Could I be added to the WikiUsersGroup so I can edit some pages? 20.03.41 # RichardNease: what would you like to edit (just curious)? 20.04.38 # The pages referring to the Sansa line of products 20.04.41 Join Xerion [0] (~xerion@84.25.7.202) 20.04.47 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 20.05.07 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 20.06.09 Quit dfkt (Disconnected by services) 20.06.15 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) 20.06.49 # RichardNease: done, but promise to be nice :) 20.07.05 # I will be nice. Thank you 20.08.53 # kugel: http://people.debian.org/~aurel32/qemu/arm/ should be useful I suspect 20.09.05 # yes, I was looking through it as well 20.09.10 # it features X at least 20.09.16 Quit RichardNease (Quit: CGI:IRC) 20.09.39 # I'm now downloading the lenny stuff there 20.10.36 Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) 20.11.44 *** Saving seen data "./dancer.seen" 20.13.06 Join robin0800 [0] (~quassel@149.254.234.236) 20.15.26 # qemu is really easy, i tested the tremor stuff in it 20.15.35 # the problem is its also really, really slow 20.19.07 Join Moltare [0] (~d56a739b@giant.haxx.se) 20.22.18 Quit kramer3d (Quit: Leaving) 20.22.27 Join Courage [0] (~Mol@cpc2-cmbg13-0-0-cust922.cmbg.cable.ntl.com) 20.22.28 Quit Moltare (Client Quit) 20.22.35 Nick Courage is now known as Moltare (~Mol@cpc2-cmbg13-0-0-cust922.cmbg.cable.ntl.com) 20.24.03 # Good evening, ladies and gentlemen. I seem to have managed to entirely freeze my rockboxed iPod Video 60GB, such that it won't accept the standard reset solution and Windows claims the device has malfunctioned when plugged into USB. 20.24.11 # Could anyone offer advice on this, please? 20.24.19 Join Luca_S [0] (~5711b744@giant.haxx.se) 20.25.15 # try holding the buttons for even longer 20.27.40 # aha! Thank you 20.27.58 # Two minutes is rather more than the eight seconds claimed, but whatever works :) 20.28.07 # cheers and g'day to you all 20.28.13 Quit Moltare () 20.30.10 # kugel: have you ever looked at libao? (http://www.xiph.org/ao/) 20.30.42 # never heard of it 20.34.18 Quit Luca_S (Quit: CGI:IRC (Ping timeout)) 20.40.09 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 20.43.54 Join wodz [0] (~wodz@chello087206240004.chello.pl) 20.44.01 # gevaerts: not sure if that's useful, that's basically sdl with audio only, isn't it? 20.44.11 # maybe 20.44.18 # I haven't looked in detail 20.44.22 # I thought we wanted to use os capabilities (or libs that are as close to the os as possible) 20.45.12 # or maybe we just wanted alternatives for sdl so that we don't rely on sdl being available on the target plattform 20.45.32 # on n900 you basically want either gstreamer or pulseaudio 20.46.46 # I think my alsa-sim work actualy uses pulseaudio, there's some strange interactions between them I haven't figured out completely yet 20.47.03 # but I read that alsa wraps around pulseaudio which wraps around alsa 20.47.14 # yes, it's an interesting setup 20.48.15 # I'm quite happy with the alsa thing, as we basically only need plain pcm playback. the only drawback seems the volume changing, but that's software volume changing is acceptable IMO 20.48.35 # also alsa should be available on every linux setup 20.48.53 # I'm not sure what volume changing behaviour in an app should be anyway 20.49.02 Join fml [0] (~chatzilla@port-83-236-234-85.static.qsc.de) 20.49.38 Join tchan1 [0] (~tchan@c-69-243-144-70.hsd1.il.comcast.net) 20.49.44 # well it's a definitely a nice to have, but I expect you'd rather use hardware volume buttons (which affect the whole system) or some OS widget for that on mobile devices 20.50.04 # but I think a desktop app should have that 20.50.44 # all the other linux programs I looked at also do sw volume changing, but in a later step (not in the dsp) as I currently implemented 20.51.00 # the only difference is the 3s delay when changing volume :P 20.51.07 # Well, I mean, isn't that as simple as allowing software volume adjustment in Rockbox, but disabling the keys on targets where good hardware volume is considered the "better" solution (and setting the default volume to line leve) 20.51.09 Quit tchan (Read error: Connection reset by peer) 20.51.15 # pixelma: domonoky: amiconn: bluebroth3r: hello. Please compare FS#11186 and FS#11228 (both are German translations). If I had noticed FS#11186 I wouldn't have done FS#11228. But now it's there and there are somedifferences. What do you prefer? 20.51.26 # Then people can still adjust it through the settings if they want it set at a specific level relative to their other apps, but won't accidentally adjust it all the time. 20.52.03 # I mean "as simple" in terms of the disabling of the buttons, not necessarily the implementation of software volume. 20.52.34 # disabling the buttons would be complicating it a slight bit :) I don't think there's a need to do that 20.52.58 # Well, if we're depending on hardware volume, there's no real reason there should be separate Rockbox volume controls in the WPS too 20.53.05 # s/disabling the buttons/not mapping the buttons in the first place/ ? 20.53.09 # A player doesn't need what appear to be two different volume buttons. 20.53.13 # gevaerts: Yes 20.53.36 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 20.53.58 # in multitasking environments having separate volume levels for each app is appreciated, and mobile phones do multi tasking nowadays 20.54.00 Join robin0800 [0] (~quassel@149.254.234.236) 20.54.41 # disabling the buttons would mean an artificial limit I cannot see a rationale behind 20.54.55 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 20.55.21 # It reduces complication - two sets of volume controls are complicated. 20.55.46 # In cases where we cannot 'steal' the hardware volume buttons for use as Rockbox volume when it's in the foreground, I think we should just treat them as *the* volume buttons and not have our own. 20.56.15 # but it's not confusing, on normal PCs you have a much wider variety of abilities to change volume. people will just use what suits them best 20.56.17 # fml: maybe you can combine those language patchs ? I also like "Tastenkürzel" better then "spezialtaste". 20.56.33 # At least with pulseaudio you can set the volume per stream 20.56.46 # kugel: On normal PCs you also have a speaker knob, which is the primary thing you use to adjust volume after you've got the apps set up relative to one another. 20.56.58 # i.e. the rockbox volume controls could be rockbox only while still leaving it to the environment 20.57.14 # I'm not saying disable the ability to adjust the volume 20.57.22 # I'm just saying, not map keys to it in the WPS / List. 20.57.24 # Use the setting. 20.57.31 # gevaerts: with pulseaudio you even get a third way if I understood it correctly 20.58.00 # domonoky: But then it's weird. We do not assign somethingto the "Tastenkürzel" (but the phrase says so). We either assign Tastenkürzel to a function or we assign function to the Spezialtaste. 20.58.45 # gevaerts: do you think I should rather look into pulseaudio again? I thought using alsa directly is good enough 20.58.53 # hmm I just fired up test_scanrate.c on my mini 1G and I have scanrate 92.3Hz while in grey_core.c there is 87Hz defined for mini 21.00.05 # kugel: it doesn't matter. You use the one that's most appropriate for the device you're working on 21.00.21 # wodz: oh, you also have a Mini 1G? Seems to be rare 21.00.38 # I do 21.00.42 # gevaerts: I'm not working a device currently, but exploring possiblities :) 21.01.36 # fml: Spezialtaste sounds a bit like it would give you an extra button somehow and Tastenkürzel is the usual translation for this kind of thing (although I don't have a strong preference yet) 21.01.38 # but I think alsa is pretty appropriate, I think it is the one with the least overhead and perfectly fits our needs 21.01.48 Part watto 21.02.06 # our needs are defined by the environment :) 21.02.22 # but that only applies for linux targets yes, on android I'm going to need jni calls 21.02.51 Part Boldfilter 21.02.52 # I'd assume so 21.03.14 # wodz: as a hint: if you want your new MPIO target be added to the automated buildsystem, you have to add it to www/buildserver/builds in svn :-) 21.03.53 # I've shortly looked into it, and there's a pcm-buffer-callback-like jni call so that might not be a problem 21.04.48 # pixelma: but the English original also doesn#t use the usual term "Shortcut". And that's OK since the "Shortcut" is const but the function assigned to it varies. Normally, when "Shortcut" is used, it's the other way around: you have a function and you assign one or another shortcut to it. 21.05.29 # gevaerts: well, w.r.t. to audio we only really need pcm passthrough, not any other fancy audio feature that an os might provide 21.06.13 # domonoky: thanks for the tip 21.06.32 # wodz: about the scanrate thing - I know that it varies a bit at different temperatures and probably slight differences in the panels (I mean same type but build somewhere else or so). It could also be that the difference is in 1G vs. 2G Mini and the former hasn't been tested yet. Not sure how important this difference you measured is 21.06.38 # especially not audio format conversion 21.07.32 # kugel: definitely 21.07.40 # pixelma: I'm just gonna compare two bilds with current scanrate 87 vs. measured 92 21.08.03 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 21.08.59 # wodz: also trunk/tools/builds.pm and www/index.t could need updating for the new target. 21.10.18 # index.t too? 21.11.51 # afaik index.t contains the targets on the front page 21.12.40 # ah right 21.14.51 Quit robin0800 (Remote host closed the connection) 21.16.08 # fml: hmm... maybe we can find something different? Spezialtaste also doesn't cover button combos (which it is in some cases). I also don't like "Spezialtaste-Einstellungen", if at all then "Spezialtasten..." 21.17.33 # pixelma: the point is: it's *the* Taste, there are not many of them :-/ 21.18.26 # and it would be really nice if we could find something better for "zurückspulen"... although it's the exact translation of rewind... but you're not winding your MP3 or whatever audio file 21.18.46 # I suggested Tastenkürzel as well 21.19.26 # kugel: but I already explained why I don't quite like it. 21.19.30 Quit Boldfilter (Quit: Boldfilter) 21.20.15 # sometimes it's not a matter of preference, but what the usual/common translation is 21.20.51 # fml: btw., putting "we pe es" in thevoice string is unclean. Whether your TTS can deal with the abreviation correctly depends on your TTS and there is a script in Rockbox which does the correction for some TTSs 21.21.35 # * pixelma actually doesn't want to sound so negative... sorry 21.23.43 # Tastenbelegung? (for one key or key combo only though) 21.24.37 # How about: Tastenkürzel belegen mit ...? But what Tastenkürzel? I give up for now. Maybe tomorrow it will come to my mind by itself. 21.25.32 # why there are no links to ports pages in "unusable ports" section on frontpage? 21.25.45 # is it "by design"? 21.26.44 # I don't think so 21.27.21 # the actual question is why unstable ports are clickable links 21.28.23 Join Luca_S [0] (~5711b744@giant.haxx.se) 21.28.31 # hehe 21.28.46 # I didn't noticed that stable targets aren't 21.30.17 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 21.31.59 # I think "stable" doesn't really need to be clickable, but "unstable" helps users trying to decide just how "unstable" something is. 21.32.06 # Meanwhile, "unusable" is a pretty explicit description. 21.32.45 Join Schmogel [0] (~Miranda@p3EE22D35.dip0.t-ipconnect.de) 21.33.06 # * kugel join #gsoc-de 21.33.08 Quit Boldfilter (Client Quit) 21.33.16 # meh 21.33.24 Quit Luca_S (Quit: CGI:IRC (Ping timeout)) 21.34.39 # Llorean: I found it counterintuitive - the stable target should have clickable links redirecting to download section IMO 21.34.45 Quit fml (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 21.35.13 # wodz: But people should be using rbutil 21.35.15 # Not the download page. 21.35.27 # That's why theres a single link to the installer, instead. 21.35.30 # Right at the top of the stable list 21.35.52 # If you add a whole bunch more links, people are more likely to click the target one (which is less helpful) than the installer one 21.35.57 Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) 21.36.14 Quit JohannesSM64 (Ping timeout: 264 seconds) 21.36.18 # so make the installer link more obvious (aka BIGGER) 21.36.23 # Anyone with a fuze experiencing 1-5 minute boot times like Overlord Nathan is reporting in the forums? 21.37.00 # what is the syntax of www/buildserver/builds ? 21.37.00 Quit hebz0rl (Read error: Connection reset by peer) 21.37.00 # not my fuze v1 on current svn 21.37.09 # couple of seconds max 21.37.11 # wodz: But the fact that it's not bigger isn't a reason to add confusing links that could misdirect users... 21.37.46 Quit phanboy4 (Quit: Leaving) 21.37.49 # Llorean: where is that fuze report? 21.39.11 # Llorean: ok it is going to be more philosophical dispute 21.41.17 # FlynDice: http://forums.rockbox.org/index.php?topic=24637.msg165975;topicseen#msg165975 21.41.28 # thx 21.41.44 # wodz: The front page is mostly user oriented, so ideally the links should be the ones users need to find, rather than developers 21.41.52 # Or, more specifically, the ones we want users to find. 21.42.41 # biggest thing that influenced my fuze's boot time was a big font, but never 1-5 minutes 21.42.56 # Llorean: I am not going to redesign frontpage don't be afraid :-) 21.42.58 # wodz: I think it would be confusing if the stable targets linked to the downloads, and the unstable targets linked to the port pages. I agree the unusable targets should be links, and the "installer" link much more prominent. 21.43.28 # * Llorean can agree that the installer link should be more prominent. 21.44.13 # linuxstb: I think that the "status summary" link is really where people interested in the unusable targets should be directed first, though. 21.44.18 # New commit by 03wodz (r25759): Add MPIO HD200 to the frontpage 21.44.24 # It's a lot more user oriented of a page. 21.44.41 # Llorean: The same for "unstable" as well? 21.45.26 # For unstable, we've already told the user "this should at least work and you should be at least able to listen to audio" from the summary, so the individual links should probably actually be to either a warning anchor (for what's broken) or an install anchor on the individual target page 21.45.28 # Llorean: Or the port pages should have a user-friendly status summary at the top. 21.45.35 # Since in those cases, people clicking the links *should* be people wishing to install 21.45.46 # wodz: about the syntacs of the builds file. its; buildtype:configure targetname: Userreadable targetname:outoutfile:configure options needed: 21.45.47 # User friendly summary on the status pages would be great. 21.45.55 # But I don't know how likely it is to happen. :) 21.46.11 # Llorean: I'm not sure I agree with that - we're calling them "unstable", so people may want to know what that means before installing. 21.46.26 # ^what that means specifically for that player 21.46.30 # I just think, from one perspective the current links make a lot of sense: Stable - installer. Unstable - install instructions as user friendly as we have. Unusable - Our most user friendly description if *why* they're unusable. 21.46.33 # can I ask for update of frontpage? 21.46.53 # wodz: You need to ping Bagder or Zagor (I guess I just have...) 21.47.01 # But I do agree that it'd be nice if we could mix "explaining why they're unstable" and "easy to find install instructions" 21.47.21 # wodz: you need to poke Bagder or Zagor for the index.t update. all other changes are updated automatically. 21.48.05 # Llorean: I just think it's more "intuitive" if the name of a player in a list of targets links to a description of that player, rather than a download. Otherwise, the list should have the heading "Downloads". 21.49.17 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 21.50.16 # domonoky:--target=xxxx - xxxx is the configure name or what? 21.50.19 # funman (logs): after your latest cpu freq changes my clip+ got very useful again. before it often didn't turn on without holding power 20 secs. now it starts always and it hasn't crashed for several mp3 albums 21.50.51 # linuxstb: Well, currently that's basically what they do. 21.50.53 # wodz: thats the options you need to pass to configure to build your target. 21.51.26 # wodz: actually it's what ever your switch case accapts for the mpio. i.e. also the number 21.51.30 # accepts* 21.51.39 # the unusable list of targets look funny with one
  • only 21.52.13 # that's only for indentation :p 21.52.32 # funny indentation 21.52.44 Join anewuser [0] (anewuser@201.248.225.97) 21.52.44 # and the final number? How do I get score? 21.52.45 Quit anewuser (Changing host) 21.52.45 Join anewuser [0] (anewuser@unaffiliated/anewuser) 21.52.49 # it indents even without
  • actually 21.53.35 # wodz: the easiest is to just copy from a similar target and let it get calibrated correctly later on 21.53.49 Join Boldfilter [0] (~Boldfilte@adsl-82-151-224.jax.bellsouth.net) 21.54.29 # ok 21.58.32 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 21.59.55 # topik: Can you startup with uSD inserted? 22.01.15 # New commit by 03wodz (r25760): Add MPIO HD200 to automatic build system 22.08.24 Join bluebrother [0] (~dom@f053152119.adsl.alicedsl.de) 22.08.24 Quit bluebrother (Changing host) 22.08.24 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.09.21 # New commit by 03wodz (r25761): Add MPIO HD200 to builds.pm 22.11.47 *** Saving seen data "./dancer.seen" 22.12.19 Quit bluebroth3r (Ping timeout: 276 seconds) 22.17.02 # FlynDice: It shouldn't take long for him to uninstall? The fact that he's "still uninstalling" might also be a sign. 22.17.32 # anyone remembers FS number of the patch that changes ipod charging current from 100mA to some more? 22.20.06 # Llorean: Yes, it's pretty easy to flash an unpatched OF and delete the .rockbox dir. He's going to be upset when he does that and it still takes 5 mins to boot due to file system problems though I bet... 22.37.12 # wodz: If your blob is not moving, but isn't pure black on pure white, you didn't hit the proper scanrate, but a (simple) ratio of it, e.g. 2/3 22.37.54 # amiconn: I fired up test_scanrate on my mini 1G so now I know how it should look 22.38.11 # This often happens for new targets because the scanrate varies a lot between different targets 22.38.36 # but is it possible that scanrate is obove 150Hz? 22.38.47 # s/obove/above 22.39.17 # It might be. Most controllers use something between 70 and 80 Hz. M3 has 150 Hz 22.40.12 # is there some simple test to see if blit_mono is working correctly? 22.40.49 # If I'm setting twice the real scanrate on my mini (176Hz instead of 88Hz), I'm seeing two (smaller) blobs 22.41.34 # is scanrate specific to controller or to the lcd panel? 22.42.11 # It's specific to the controller, its programming, and the clock source for the controller 22.42.51 # At 2/3 (58.7Hz) I'm also seeing two blobs, but dark grey on light grey, not black on white 22.43.26 # have You looked at pastebins of lcd_grey_data? Do this look ok for You? 22.43.33 # 1/3 gives one dark grey on light grey blob 22.43.50 # (and a bit of flickering since that's only 29.2Hz) 22.44.42 # I've seen those for mono blitting, but not for grey 22.45.39 # FlynDice: I have a crazy idea for possibly making your Clip+ 'usable' 22.45.55 # Hmm, the blob changing colour but not position sounds weird 22.46.02 # * amiconn would like to see that 22.46.06 Join merbanan [0] (~banan@c-94-255-217-199.cust.bredband2.com) 22.46.38 # Attach an attiny to the JTAG port, which on poweron halts the CPU, pokes instructions into memory and resumes a new microbootloader and goes to sleep. 22.47.27 # * amiconn looks 22.47.29 # The new bootloader would then read a few sectors from microsd to load the rockbox loader. 22.47.45 # amiconn: Now I can say I saw no blob but stripe 22.48.09 # Then I'd just have to patch rockbox so that it always uses the external SD in place of the internal one :) 22.48.20 # Hmm. Did you try 292Hz? 22.48.50 # amiconn: no, I didn't go above 200Hz 22.49.07 # * amiconn wonders whether it's really that high, but I think that may even be the case for the TL0350 22.49.20 # ranma: I was just going to suggest using the external but current svn is rather sketchy as far as the uSD goes 22.50.29 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 22.50.53 # The earlier builds worked pretty well but for awhile now the clip+ uSD function has been pretty iffy. I've actually been investigating that today. 22.51.43 # wodz: Your lcd_grey_data has several problems. 22.52.34 # (1) There must be 8 pixels per block, not 4 22.53.09 # I am not surprised :-) I don quite understand what this should do 22.54.43 # (2) %a2 is a length (rather: a width, in pixels), not an end address. If you want to use it as such, you have to do two things to convert it: (a) multiply by the number of pixels in a block, because one pixel == one phase byte (b) add the start address 22.55.35 # 2) is easy 22.55.50 # I don't understand (1) 22.56.13 # Well, you have a TL0350. The TL0350 uses 2 bit vertical interleaved pixels 22.56.21 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 22.56.58 # I know 22.57.15 # This means there are 8 pixels per word. The greylib uses two buffers of one byte per pixel, one buffer for the pixel values (only possible values are 0..128) and one for the phases 22.57.20 # I need one word of data for single vertical strip of pixels 22.57.38 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 22.58.14 Join dantje [0] (~dvg@HSI-KBW-095-208-155-207.hsi5.kabel-badenwuerttemberg.de) 22.58.24 # However, these buffers are *not* laid out like an ordniary byte packed image, but they are in the controller's pixel order, in order to speed up lcd_grey_data() 22.59.34 # Hence, you need to calculate 8 pixel values for every word written to the lcd controller. YOu only calculate 4. 23.00.14 # Oh, and you also forgot the final duplication, before writing to the controller 23.00.50 # amiconn: but move.w to the lcd is actually single byte 23.01.08 # lcd is wired to the lower byte only 23.01.12 # Ok, then you need to transfer the same byte twice 23.01.23 # Like in lcd_mono_data() 23.01.39 # But you also need to calculate a whole byte, not a half byte 23.01.55 Quit pamaury (Quit: Page closed) 23.03.09 # The greylib always works with mono pixels, even if the controller does 2bpp natively, for two reasons 23.03.50 # (1) The interaction between native shades and temporal dithering would be hard calculate 23.04.21 # gevaerts: I get a kernel panic :( 23.04.32 # Give it back! 23.05.01 # ah, older kernel works it seems 23.05.43 # actually I had that kernel panic too with qemu from the mini2440-qemu repo 23.06.15 # (2) Even though calculation would still be manageable (I even did it for a quick test, back in the days of the old graylib), doing this creates nasty interference, due to the way native shades work: the controller does basically the same as we do in software, but we can never match the frequency 100% 23.06.19 # hm, no, it's not doing anything now instead of giving the panic 23.07.30 # kugel: the setup from http://people.debian.org/~aurel32/qemu/arm/ works for me. Lenny and 2.6.26 23.07.40 # ah, there we go 23.08.12 # i used the images from here now http://ftp.de.debian.org/debian/dists/lenny/main/installer-armel/current/images/versatile/netboot/ 23.09.10 # maybe abi incompatibilities 23.09.48 Quit domonoky (Read error: Connection reset by peer) 23.11.07 Quit evilnick_B (Quit: Page closed) 23.11.10 # amiconn: Thank You. 23.13.44 # Like this: http://pastebin.com/ANdt62rS (untested, so no guarantees...) 23.13.56 Quit M3DLG (Read error: Connection reset by peer) 23.14.25 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 23.15.15 # If back-to-back writes are too fast for this controller, you can spread out the two writes a bit. The first could be moved up two instructions, directly after lsr.l #7, %d1 23.16.14 # * amiconn likes using lea.l for a register arithmetics :) 23.17.51 # I'll test tomorrow 23.23.36 # hmm. Maybe problem with scanrate comes from lcd_mono_data doing back-to-back writes to the controller? 23.27.05 Quit kugel (Remote host closed the connection) 23.27.10 Quit shai (Quit: Leaving) 23.27.25 Quit w1ll14m (Read error: Connection reset by peer) 23.28.28 Quit wodz (Quit: Leaving) 23.29.12 Quit bmbl (Quit: Bye!) 23.34.23 Quit CGL (Quit: A trabajarrrrrrrrrrrrrrrrrr) 23.34.24 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.40.02 Quit bertrik (Quit: De groeten) 23.42.08 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 23.46.54 Quit adnyxo (Ping timeout: 260 seconds) 23.49.35 Quit esperegu (Remote host closed the connection) 23.51.35 Quit ender` (Quit: Top reason why compilers are like women: Miss a period and they go crazy)