--- Log for 22.11.111 Server: pratchett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 7 hours ago 00.03.19 Join factor [0] (~factor@74.197.205.204) 00.03.48 Quit ender` (Quit: foot, n. a device used for finding Lego bricks in the darkness) 00.27.51 Join Topy44 [0] (~Topy44@f048237193.adsl.alicedsl.de) 00.28.40 Nick _dv_ is now known as dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) 00.31.21 Quit Llorean (Read error: Connection reset by peer) 00.31.21 Quit tchan (Read error: Connection reset by peer) 00.31.47 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 00.31.59 Quit scorche (Disconnected by services) 00.32.02 Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) 00.32.05 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 00.32.27 Quit Llorean (Changing host) 00.32.27 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 00.33.40 Join Keripo [0] (~Keripo@SEAS216.wlan.seas.upenn.edu) 00.33.40 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) 00.35.03 Quit liar (Ping timeout: 258 seconds) 00.37.02 Quit markun (Ping timeout: 240 seconds) 00.43.28 Join robin0800 [0] (~robin0800@149.254.61.157) 00.43.48 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 9.0/20111116091359]) 00.57.27 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 00.57.44 Quit tchan (Read error: Connection reset by peer) 00.57.51 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 00.58.06 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 00.58.42 Quit Guinness (Read error: Connection reset by peer) 01.00.11 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 01.00.53 Join GeekShadow [0] (~antoine@105.211.192.77.rev.sfr.net) 01.02.31 *** Saving seen data "./dancer.seen" 01.11.48 Join ReimuHak_ [0] (~reimu@208.119.81.194) 01.13.46 Join ChickeNE_ [0] (~ChickeNES@128.135.100.102) 01.16.35 Quit GeekShadow (Ping timeout: 240 seconds) 01.17.21 Join GeekShadow [0] (~antoine@57.128.197.77.rev.sfr.net) 01.17.54 Quit krnlyng (Remote host closed the connection) 01.22.51 Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 01.23.08 Quit Guinness` (Read error: Connection reset by peer) 01.23.22 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 01.25.39 Quit Scromple (Ping timeout: 240 seconds) 01.41.51 Quit ReimuHak_ (Quit: Leaving...) 01.47.11 Quit MethoS- (Remote host closed the connection) 01.57.31 Join markun [0] (~markun@s3eea32f5.adsl.wanadoo.nl) 02.01.04 Quit GeekShadow (Ping timeout: 260 seconds) 02.08.26 Join GeekShadow [0] (~antoine@129.129.197.77.rev.sfr.net) 02.23.20 Join AdrianG [0] (~speed@unaffiliated/amphetamine) 02.23.22 # hi 02.23.24 # anyone has a sansa? 02.41.23 # probably you. if you have a more specific question just ask it 02.49.28 # i googled my answer 02.54.57 Quit bluebrother (Read error: Operation timed out) 02.56.09 Join bluebrother [0] (~dom@f053154206.adsl.alicedsl.de) 02.56.09 Quit bluebrother (Changing host) 02.56.09 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 03.02.34 *** Saving seen data "./dancer.seen" 03.05.54 Quit robin0800 (Quit: Leaving) 03.06.45 Join robin0800 [0] (~robin0800@149.254.61.157) 04.03.57 Join ReimuHak_ [0] (~reimu@wireless.sit-co.net) 04.09.19 Quit ChickeNE_ (Quit: Computer has gone to sleep.) 04.27.04 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.27.04 Quit amiconn (Disconnected by services) 04.27.24 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.27.48 Quit pixelma (Disconnected by services) 04.27.50 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.27.52 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.34.12 Quit TheSeven (Disconnected by services) 04.34.29 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.51.31 Join Frag [0] (~androirc@122.63.85.212) 04.51.49 Nick Frag is now known as Weeble (~androirc@122.63.85.212) 04.52.14 Quit Weeble (Client Quit) 05.02.38 *** Saving seen data "./dancer.seen" 05.03.55 Join Rob2222 [0] (~Miranda@p4FFF10B0.dip.t-dialin.net) 05.04.30 Join dreamlayers [0] (~dreamlaye@rockbox/developer/dreamlayers) 05.07.43 Quit Rob2223 (Ping timeout: 248 seconds) 05.26.22 Quit Topy44 (Ping timeout: 252 seconds) 05.30.41 Quit robin0800 (Read error: Connection timed out) 05.32.19 Join robin0800 [0] (~robin0800@149.254.61.157) 05.34.36 Join Topy44 [0] (~Topy44@f048237193.adsl.alicedsl.de) 05.43.55 Quit Horscht (Quit: Verlassend) 05.49.44 Quit dreamlayers (Quit: dreamlayers) 06.23.17 Quit robin0800 (Read error: Connection reset by peer) 06.30.12 Quit nsx (Ping timeout: 240 seconds) 06.40.10 Quit Keripo (Quit: Leaving.) 07.02.41 *** Saving seen data "./dancer.seen" 07.09.32 Join Keripo [0] (~Keripo@165.123.49.235) 07.10.55 Quit factor (Ping timeout: 248 seconds) 07.13.29 Quit jhMikeS (Read error: Connection reset by peer) 07.20.26 Quit Keripo (Ping timeout: 245 seconds) 07.21.51 Join Keripo1 [0] (~Keripo@165.123.49.235) 07.22.23 Join factor [0] (~factor@74.197.205.204) 07.48.23 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 07.48.23 Quit jhMikeS (Changing host) 07.48.23 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 08.18.11 Quit hilbert (Quit: Computer has gone to sleep.) 08.27.24 Quit Scr0mple (Quit: Leaving) 08.34.39 Quit AdrianG (Ping timeout: 248 seconds) 08.35.21 Join GodEater_ [0] (93722cd0@rockbox/staff/GodEater) 08.35.35 Join hilbert [0] (~hilbert@7-111-204-62-static.cable.fcom.ch) 08.40.00 Quit Keripo1 (Quit: Leaving.) 08.55.59 Join freqmod_ [0] (~quassel@2001:700:300:1430:226:18ff:fe82:1a24) 09.02.19 Join ender` [0] (~ender@foo.eternallybored.org) 09.02.44 *** Saving seen data "./dancer.seen" 09.05.36 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.20.37 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.35.00 Join pamaury [0] (~quassel@sphinx.lix.polytechnique.fr) 09.35.01 Quit pamaury (Changing host) 09.35.01 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.37.54 # Zagor: hows your lcd cleanup stuff going? 09.38.04 # slowly :-( 09.38.36 # I have a lot of stuff done, but a lot of stuff is still broken by it. 09.38.49 # bummer 09.39.01 # or, actually, the cleanup should be fine. 09.39.20 # it's the relative positioning that breaks things 09.39.57 # I'll take a look at just the cleanup and see if I can make it fit for review/commit. 09.39.58 # do you deal with charcell at all? 09.40.03 # yes 09.40.52 # cool, yeah, getting that in would be nice :) 09.41.22 # would there be any obvious issues with disabling backdrops on specific viewports? 09.47.57 # I'm going to finish FS#12376 and probably commit by the week end if nobody objects 09.47.57 # http://www.rockbox.org/tracker/task/12376 3New batch of icons (patches, assigned) 09.48.43 # I'm focusing on that the icons can be generated from svgs, then we can have multiple sizes in svn 09.52.14 # amiconn: Zagor: any obvious issues with this? http://pastebin.com/q5f3tKg9 (obviously need to fix the other bitdepth files too) 09.52.53 # JdGordon: can you do it with the drawmodes? 09.53.03 # JdGordon: not that I can think of right now 09.53.34 # kugel: I've never figured it out, if you can that would work too 09.53.58 # I think a viewport field isn't needed. a new drawmode that does bgcolor even if a backdrop is set 09.54.44 # I'm possibly confusing things also... I want to draw over the current pixels and ignore the backdrop and bg_pattern completly also. I cant remember which of those is doable in svn and which isnt 09.54.54 # and no, I think drawmodes are nasty 09.55.12 # maybe I dont understand them enugh though 09.55.14 # JdGordon: I think a DRMODE_FORCE_BG case that would take the else branch in DRMODE_BG (can even do fall-through) would work 09.55.40 # is that really cleaner thogh? 09.56.27 # IMO yes. no need for multiple patterns 09.56.43 # multiple patterns? 09.57.05 # drawmodes and specific viewport fields 09.57.24 # (drawmode is already viewport specific) 09.57.39 # which is why it is in the viewport struct 09.57.46 # this is nothing more than natural evolution 09.57.56 # drawmodes are not clean IMNSHO 09.58.06 # why? 09.58.35 # you mean apart from that field merging style and drawmode in one? 09.58.51 # what? 10.01.08 # it seems sensible to me to pack that into the already existing drawmodes instead of adding another field 10.02.07 # yeah, ok. I disagree 10.02.21 # probably also means less #ifdef 10.03.00 # none are being added 10.03.36 # "+ bool disable_backdrop;" :)( 10.03.55 # thats not a ifdef? 10.04.28 # I thought that was regarding a field 10.06.45 # I expect drawmode is faster as well, since it's not an additional if per row 10.07.42 # I highly doubt that 10.14.31 Join wodz [0] (~wodz@89-76-160-35.dynamic.chello.pl) 10.16.35 # Anyone have idea how toshiba's nand flash interleaved mode works? It differs somehow from multiplane organization. I can't find any relevant datasheet about this. 10.16.40 # [7]:^ 10.20.40 # <[7]> wodz: I know of two distinct mechanisms to parallelize NAND accesses 10.21.07 # <[7]> you can either interleave the accesses to the planes, if the chip supports multiplane operation 10.21.27 # [7]: this one I understand and can match in disasm 10.22.03 # <[7]> or, if it does support the other mechanism, you can upload the data into a cache buffer while writing the previous page from the cache buffer to the flash 10.23.03 # This is other thing I think. You are talking about distinction between READ CACHE and READ with multiplane 10.23.21 # <[7]> I've never managed to implement this in the nano2g FTL because I don't have such a chip and organizing the flash accesses in the neccessary order is tricky from the FTL's perspective, but there are specifications of this in various nand chip datasheets 10.24.23 # [7]: could you provide me some references? I failed to find Toshiba's datasheet for which there is reference in disasm 10.24.52 # err I mean write 10.25.12 # <[7]> IIRC it works like this: upload bank1-page1, upload 2-1, upload 3-1, upload 4-1, write 1-1 async, upload 1-2, write 2-1 async, upload 2-2, write 3-1 async, upload 3-2, write 4-1 async, upload 4-2, write 1-2, write 2-2, write 3-2, write 4-2 (as a demo 8 page operation on 4 banks) 10.27.24 # <[7]> http://catalog.gaw.ru/project/download.php?id=11318 page 16 10.27.43 # wodz: will you commit your backtrace work? 10.28.53 # kugel: it is not finished 10.29.05 # what's missing? 10.29.09 # kugel: it definitely has a problem when called from panicf 10.29.17 # oh :( 10.29.20 # I didn't investigated it much 10.29.52 # first I need to understand why it is so and for this I need to have either working simulator or gdb stub 10.30.18 # I am not abandoning the idea but this will take some time 10.30.42 # one can debug rockbox natively on the mini2440 10.31.52 # wodz: what kind of problem is that? 10.33.18 # kugel: It could be 1) inconsistency with pc/sp passed to unwinder 2) exhausting of search for ret from routine 3) bug in unwinder 4) mix of above 10.34.24 # it doesnt print anything or crashes? 10.35.32 # it doesn't print anything 10.36.13 # perhaps it's worth trying on an ARM RaaA 10.36.16 # [7]: I can't deduce from the datasheet you linked how data will endup on flash 10.36.35 # kugel: you are welcomed to look at it - I don't have any suitable target 10.37.21 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 10.39.11 # [7]: hmm I think I start to understand - It is not implied how data are going to be distributed as you provide address along with every data to be written, right? 10.40.07 # <[7]> wodz: correct, you just upload one page in advance, while the previous write operation is still executing 10.40.22 # bugger 10.40.23 # <[7]> however IIUC you can only do this within the same block, for whatever reason 10.40.32 # oh 10.41.04 # <[7]> and i'm not sure what kind of constraints there are regarding bank switching 10.42.31 Join TomColler [0] (~thomas@net-93-144-158-131.cust.dsl.teletu.it) 10.43.10 # <[7]> http://www.eetindia.co.in/ARTICLES/2004NOV/A/2004NOV29_MEM_AN04.PDF?SOURCES=DOWNLOAD might be helpful 10.44.17 # [7]: thanks 10.45.29 # <[7]> this makes it look like it either doesn't make any sense on devices that have multiple planes, or that you can use it to emulate the multiplane behavior 10.47.00 # I think this the latter case 10.47.16 # I think this is pre-multiplane idea 11.02.47 *** Saving seen data "./dancer.seen" 11.12.13 Join T44 [0] (~Topy44@f049015205.adsl.alicedsl.de) 11.13.14 # I'm tihnking about adding an option to skins to draw a viewport without clearing the rectangle first, it would allow drawing text over the AA image. The problem is that any scrolling would make it look horrible 11.13.18 # so is it worth adding? 11.15.01 # OH! I know! I tihnk I want to add a second framebuffer to the skin so viewports can draw into that which can then be used as the backdrop image! :) 11.15.03 Quit Topy44 (Ping timeout: 240 seconds) 11.15.10 # would that actually be doable? 11.16.36 # a second framebuffer would be nice for a few other things 11.16.55 # mmm, semi-transparent AA as the wps backdrop! 11.16.56 # <[7]> JdGordon: while you're at it, add alpha blending to make the text that's drawn above the AA image actually readable :) 11.17.15 # well, we can now do that right? 11.17.25 # [7]: you mean that alpha blending that's in svn since a few month? 11.17.35 # ;) 11.18.04 # * [7] never really had a detailed look at those UI things 11.18.25 # this seems to be "just" a matter of teetelling the lcd api to draw to a different buffer for specifc viewports 11.19.23 # JdGordon: yea, replace the backdrop pointer with a pointer to any other image 11.19.59 # right, the problem is having other things populate that buffer 11.20.24 # * JdGordon has a play 11.20.31 # similarly to what I've done for 32bit bitmaps 11.21.52 # does the alpha stuff let us draw a image with a opacity given at runtime? 11.23.00 # that's the whole point of it :) 11.23.06 # do yea :) 11.23.09 # so* 11.23.51 Quit yosafbridge (Ping timeout: 240 seconds) 11.25.03 Quit lmh (Ping timeout: 240 seconds) 11.26.38 Join lmh [0] (lmh@nat/redhat/x-smwdviihzxjbcqak) 11.29.01 # crap, the lcd drivers arnt so simple to change the framebuffer to a given pointer 11.31.01 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 11.35.16 # <[7]> urgh 11.35.31 # <[7]> well, that needs to be redesigned as well 11.35.36 # <[7]> think double buffering / vsync 11.36.25 # <[7]> this is what's currently preventing us from making the lcd update instantaneous by doing it through DMA 11.37.02 # <[7]> btw, the ipod classic and nano4g displays are apparently RGB666, so we waste two bits of color depth right now :P 11.37.48 # FS#11615 does the work to change all the drivers from static arrays to pointers, but the broke on target and got abandoned 11.37.49 # http://www.rockbox.org/tracker/task/11615 3Dynamic screen size (patches, new) 11.38.16 # wont true double buffering really just waste ram? 11.38.56 # [7]: you're welcome to write an 18bit lcd driver if you think the two bits are worth it :) 11.39.34 # <[7]> i've done it for emcore :) 11.39.38 # probably easier to write a 24bit one and scale down in the driver 11.39.44 # <[7]> exactly that :) 11.39.58 # <[7]> of course with realtime dithering while pushing the pixels to the LCD 11.40.05 # [7]: well, that would be nice to have on rockbox too 11.40.10 # raaa can do better than 16bit 11.40.43 # the 24bit one I mean 11.41.22 # <[7]> btw, the dithering is faster than the the LCD on the nano2g and nano4g (barely), and slower on the classic 11.43.07 # <[7]> I think on the nano4g I needed to add like 4 nops to the pixel processing loop to not overflow the LCD's buffers. checking the lcd's status would have taken longer :) 11.51.01 Join Thra11 [0] (~thrall@87.112.174.211) 11.52.38 Quit stripwax (Ping timeout: 244 seconds) 11.57.19 Quit hilbert (Ping timeout: 248 seconds) 12.07.46 Quit factor (Read error: Connection reset by peer) 12.11.54 # [7]: http://pastebin.com/sSCD1abq <- this is how I understand disasembly of the function which sets address for nand access in rk SDK. Does TOSHIBA case makes any sense in your opinion? 12.13.45 Part TomColler 12.13.49 # <[7]> wodz: there's a dedicated bit in the nand chip id that tells whether cache/multiple is supported by the chip btw 12.15.13 # [7]: yes I know bit 6 in third byte of ID response to be precise 12.15.50 # <[7]> there are two bits, one for cache and one for multiplane... no need to tell anything from the vendor 12.16.39 # multiplane can be larger than 1bit 12.17.09 # <[7]> i don't mean the number of planes - there's a dedicated bit that tells whether multiple planes may be accessed in parallel 12.17.32 # <[7]> anyway, what are you trying to calculate? where the data ends up on the chip? 12.18.04 # you mean onfi? 12.18.15 # [7]: yes 12.18.42 # nand controller doesn't have dedicated logic to calc for me 12.19.10 # <[7]> usually the plane number corresponds to the lower bits of the logical page address, then there comes the page number within the block, and finally the block number 12.20.44 # for planes I think I understand, I don't get what TOSHIBA case is doing 12.21.07 # <[7]> so let's assume ppb = pages per block (single plane), np = number of planes 12.21.16 # <[7]> so the chip has blocks * np * ppb pages total 12.22.08 # <[7]> lpn = logical page number as seen in software, ppn[plane] = physical page number sent to the plane 12.23.01 Join hilbert [0] (~hilbert@adsl-89-217-170-127.adslplus.ch) 12.23.06 Join MethoS- [0] (~clemens@134.102.106.250) 12.23.14 # <[7]> plane = lpn % np, page = (lpn / np) % ppb, block = lpn / np / ppb 12.23.34 # <[7]> ppb[plane] = block * ppb + page 12.23.48 # <[7]> that's how the translation is usually done 12.24.53 # <[7]> apple does that translation in the same for both access models 12.25.17 Join factor [0] (~factor@74.197.205.204) 12.25.44 # <[7]> are you sure about the >>FlashSpec[chip].Interleave parts? i can't seem to make sense of that 12.27.34 # [7]: http://pastebin.com/A3P8cgMD 12.29.39 # <[7]> where does the interleave value come from? 12.29.43 # <[7]> what's the valid range for that? 12.30.14 # <[7]> could it possibly be something like the log2 of pages per block instead? 12.30.21 # FlashSpec[i].Interleave = (buff[2]>>6)&0x01; where buff[] is filled by READ_ID 12.30.35 # <[7]> hm 12.31.12 # [7]: this bit does match hynix datasheet you provided for example (and I checked some samsungs and others) 12.32.51 # <[7]> do they check for bit 7 somewhere as well? 12.33.18 # <[7]> they might not support cache operations at all and just do things sequentially if multiplane interleaving is not supported 12.35.35 # in init sequence they do check for bit 7 but I don't know it they use this actually 12.35.38 # <[7]> also what's PagePerBlock vs. PagePerBlockRaw? 12.36.18 # FlashSpec[i].PagePerBlock = FlashSpec[i].PagePerBlockRaw * FlashSpec[i].MulPlane; 12.36.47 # <[7]> and what's SecPerPageRaw? 12.37.57 # http://pastebin.com/u4qg4HBq 12.38.08 # <[7]> hm, time for lunch, i'll have a closer look later 12.38.20 # thanks anyway - this drives me mad 12.38.31 # * [7] knows that feeling :) 12.38.53 # and without understanding data layout I am unable to make any clue from FTL code 12.43.29 Join chkktri [0] (chikakitaa@unaffiliated/chkktri) 12.48.41 # regarding http://www.rockbox.org/tracker/task/11664 - its a bit unclear to me which patches to apply to get USB going 12.48.58 # is PIO neccessary? 12.49.41 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 12.54.50 # <[7]> Misanthropos: AFAIK PIO didn't help 12.55.37 # <[7]> but ask pamaury for details 12.56.23 # [7], thx. It would be nice to know if there is a working patch out there atm. 12.56.37 # what's about bertrik's latest patch? 12.57.02 # <[7]> if we would be confident that any of those patches really works, it would have been committed already :) 12.57.27 # the PIO pathc didn't seem to help 12.58.58 # so no luck... and no patch to try.... ? 12.59.49 # those patches worked some months ago but stopped working a some revision 13.00.26 # <[7]> smells memory corruption-ish 13.01.07 # you can try the one which change USB_HANDLED_BY_OF and USE_ROCKBOX_USB only but noone has looked at them for a long time iirc since none solves everyone's problem 13.01.27 # hehe, the second framebuffer actually works! 13.01.57 Join dfkt [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at) 13.01.57 Quit dfkt (Changing host) 13.01.57 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 13.02.41 # pamaury, by just enable USE_ROCKBOX_USB with the current SVN just gets the clip+ to charge, but won't get into file exchange mode 13.02.49 *** Saving seen data "./dancer.seen" 13.03.36 # you need to disable USB_HANDLED_BY_OF too 13.04.03 # i did that / but without any addition patch 13.04.14 # perhaps the usb host detection is not working anymore since we change a few things recently 13.05.14 # <[7]> wodz: there seem to be some inconsistencies in your disassembly 13.05.49 # <[7]> row = mulplne_offset + ((row & 1) * FlashSpec[chip].PagePerBlockRaw) + page_offset; 13.06.00 # <[7]> looks like it should correspond to 13.06.16 # <[7]> .text:00000240 LDRH R1, [R4,#0x10] ; PagePerBlockRaw 13.06.16 # <[7]> [...].text:0000025C AND R0, R0, #1 ; r0 = SecPerPageRaw & 1 13.06.16 # <[7]> .text:00000260 MLA R0, R1, R0, R2 13.06.57 # <[7]> did you mix up row with SecPerPageRaw? 13.07.13 # pamaury: did bertrik's patch help? 13.07.42 # * wodz looking 13.08.45 # some reporting success, I don't remember if I test it but I seem to recall it wasn't enough for me with a windows host, but as I said I haven't looked at it for some time now 13.09.27 # pamaury: worked for someone on windows (7 and xp) 13.10.45 # kugel: and ? 13.10.57 # [7]: ah, yes - r0 holds row - I fixed this in c translation and forgot about comments in IDA 13.11.42 # <[7]> sure? actually it seems to be row / FlashSpec[chip_num].SecPerPageRaw 13.13.44 # ok, let's call it that way function argument called row (this comes from the header file I have for this lib) is logical block address (or sector) 13.15.01 # so sector/FlashSpec[chip_num].SecPerPageRaw *is* logical page address 13.15.55 # [7]:^ 13.17.00 # is anything blocking 3.10? 13.17.11 # I suspect the lack of a release manager? 13.17.19 # IMO we should just release 13.17.32 # it takes way too long 13.18.07 # we at least have something to release :) someone needs to do the paperwork 13.19.01 # pamaury: are you going to fix the french updates I committed? 13.19.41 # oh I completely forgot that 13.20.02 # lcd_clear_display() just copies the bg_pattern into every pixel on the framebuffer right? (if no image is set) 13.20.51 # kugel: I'll do tonight if I have the time to 13.21.08 # poke me if I forget :) 13.22.57 # will try to :) 13.29.04 # kugel, this someone claimed it works / but no confirmation from any other side 13.31.16 # would be nice to see the usb support working, since with the clip zip there will be yet another device with this issue 13.33.06 Quit hilbert (Quit: Computer has gone to sleep.) 13.35.14 Join hilbert [0] (~hilbert@adsl-89-217-170-127.adslplus.ch) 13.35.28 # Misanthropos: you are free to fix this you know 13.39.37 # wodz, I tried / but I lack experience with microcontrollers and have no idea about what to do.... I understand fixing and/or debugging that problem seems not to be easy 13.44.36 Quit T44 (Read error: Connection reset by peer) 13.46.04 Join Topy44 [0] (~Topy44@f049015205.adsl.alicedsl.de) 13.48.08 Quit ReimuHak_ (Quit: Leaving...) 13.50.06 # grrr.. stupid black frambeuffer instead of what it should be 13.50.55 Quit factor (Ping timeout: 248 seconds) 13.51.46 # I know for sure im drawing to the right buffer, but it isnt being used for the backdorp like it shuld :/ 13.58.29 Join factor [0] (~factor@74.197.205.204) 14.01.42 Quit stripwax (Ping timeout: 244 seconds) 14.02.47 # woo! one silly mistake and its working (well almost) 14.15.40 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.18.40 Quit stripwax (Client Quit) 14.21.23 Quit factor (Ping timeout: 240 seconds) 14.23.42 Join factor [0] (~factor@74.197.205.204) 14.25.40 Quit bluebrother (Disconnected by services) 14.25.42 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 14.27.24 # kugel: how do i make an image transparent/opaque? 14.27.27 Quit fs-bluebot (Ping timeout: 240 seconds) 14.28.17 # JdGordon: with gimp? 14.28.30 # you said it could be done at runtime? 14.29.07 Join fs-bluebot [0] (~fs-bluebo@g224236127.adsl.alicedsl.de) 14.29.07 # you mean making an image that isn't meant to be transparent transparent? 14.29.13 # yeah 14.29.28 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.29.53 # you need to attach an alpha channel after the pixel data in the structbitmap 14.30.15 # 4bit per pixel, pad to even colums 14.30.27 # see lcd-16bit-common.c 14.31.03 # so not a quick 2sec addition? 14.32.17 # damn, scrolling doesnt work :/ 14.32.21 # well. it's designed to draw actual images with transparency (where each pixel can have different alpha values), not to make opaque images transparent 14.32.49 # but it can do that. there's just no simpler way implemented 14.33.05 # I assume you want the same alpha value for all pixels? 14.33.14 # yeah 14.33.39 # just append a buffer of x*y/2 size and memset() it to the value 14.33.52 # and set bitmap->alpha_offset accordingly 14.34.07 # ok, I'll look at that tommorow i guess 14.37.03 # JdGordon: what do you want to do? 14.37.41 # show text over a semi transparent AA image 14.38.36 # I thought that would make a nice screenshot 14.40.17 # we can actually support transparent AA fine, only BMP though 14.42.53 # isnt text drawn by default mono so the backdrop comes through? 14.43.16 # for some reason the text draws correctly the first time but i get a grey background when scrolling 14.44.08 # oh, hmm, actually looks like AA isnt being drawn on the correct layer 14.44.47 # yet more excuse to break the skin engine to draw exaclty when the image is in the skin and not at the end of the viewport 14.47.53 # JdGordon: I dont think anyone is opposed to that 14.48.13 # it breaks quite a few of svn cabbies 14.48.26 # they can be fixed 14.48.29 # though, i dont think that is my problem 14.48.38 # * JdGordon doesnt know what the heck is going on :) 14.49.17 Quit stripwax (Quit: http://miranda-im.org) 14.50.25 # yep, definately drawing to the right buffer 14.57.13 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 15.02.51 *** Saving seen data "./dancer.seen" 15.03.49 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) 15.04.11 Quit stripwax (Ping timeout: 240 seconds) 15.08.41 Quit chkktri (Ping timeout: 258 seconds) 15.11.14 # <[7]> hm, looking at the code it seems like our TLSF allocator is rather buggy? 15.13.33 # [7]: imported code 15.13.46 # doubt someone verfified it 15.13.49 # <[7]> yeah, but that might still cause trouble... 15.21.30 Join metaphys [0] (~jean-loui@d86-32-96-55.cust.tele2.at) 15.24.23 Part Zagor 15.27.50 # hi!! I've got some problem to implement a new target installation method in rbutil: bootloaderinstallbase.cpp:(.text+0x5fb): undefined reference to `BootloaderInstallImx::BootloaderInstallImx(QObject*)' 15.27.52 # I suppose I must be missing some #include somewhere but i can't find where! 15.28.53 # I did create a bootloaderinstallimx.cpp and .h 15.30.07 # I've put a #include "bootloaderinstallimx.h" at the beginning of bootloaderinstallbase 15.31.06 # stil the compilation stop on the file I've add to bootloaderinstallbase.cpp: 15.31.10 # else if(type == "imx") { 15.31.12 # return new BootloaderInstallImx(parent); 15.31.14 # } 15.31.39 # Did i miss something? 15.33.04 # <[7]> that error message looks more like a missing object file 15.33.18 # <[7]> so there's probably some object file or some -l switch missing from the linker call 15.33.50 # perhaps the .cpp needs adding to some SOURCES? 15.34.04 # ?? 15.34.14 # euh I'm starting with C++ 15.34.23 # i have to say.... ;) 15.34.24 # <[7]> did you add bootloaderinstallimx.cpp to the SOURCES file of whatever you're compiling? 15.34.42 # euh no how to do that? 15.34.55 # <[7]> that's not a C++ problem, but one with the build scripts 15.35.07 # I've just downloaded a copy of the tree added files and edit some 15.36.04 # Is ist the right way to do? 15.36.19 # <[7]> you need to tell it to compile your new .cpp file somehow 15.36.38 # <[7]> apparently in rbutilqt.pri 15.40.32 # Thanks! I've got a new errors now but I know why! 15.43.45 Quit GermanMushroom (Read error: Connection reset by peer) 15.44.07 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) 15.46.37 Join ReimuHak_ [0] (~reimu@165.139.179.10) 15.54.57 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/) 15.55.19 Join hilbert [0] (~hilbert@adsl-89-217-170-127.adslplus.ch) 15.55.30 Quit ReimuHak_ (Quit: Leaving...) 16.12.37 Join wo|work [0] (~5f303f8a@www.haxx.se) 16.13.10 # pamaury: You may be interested: ftp://relay.alkotel.ru/service/MP3/T-25x/Service-manual.pdf 16.14.01 # or ftp://relay.alkotel.ru/service/MP3/T-25x/ in general 16.24.00 Quit GermanMushroom (Read error: Connection reset by peer) 16.26.30 # ok I 've a new compilation error: https://gist.github.com/1385926 16.26.43 # wo|work: what is this ? 16.27.33 # schematics for rknano player 16.28.46 # wo|work: I already found one but without the datasheet... 16.29.02 # but thanks anyway :) 16.30.23 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 16.31.24 # ../mkimxboot/mkimxboot.c is the tool to make the bootloader write by pamaury... This error seems like a C/C++ compatibility problem. I've tried to put the code in the header between #ifdef __cplusplus 16.31.26 # extern "C" { 16.31.28 # #endif 16.31.30 # #ifdef __cplusplus 16.31.32 # }; 16.31.34 # #endif 16.31.36 # but it didn't helps 16.33.35 # extern C is about calling conventions between C and C++ modules 16.33.43 # not language editions 16.33.58 # the code is using constructs that are not standard in C89 16.34.09 # and your compiler is opting to be strict C89 instead of allowing gnu extensions 16.34.15 # ..not sure why 16.35.06 # hrm 16.35.10 Quit wo|work (Quit: CGI:IRC (EOF)) 16.35.11 # actually maybe it's not allowed by gnu89 either 16.35.15 # that's.. weird 16.35.18 # i'm sure i've written that before :) 16.35.24 # what gcc version is that? 16.36.36 # 4.6.1-3 16.37.23 # well I guess I could add 4 int i in the code or is there a cleaner way to get rid of this? 16.37.34 # what's wrong? for(int i; ....) is only allowed in c99/gnu99 and c++. gcc defaults to gnu89 16.37.54 # dumb 16.37.55 Quit MethoS- (Read error: Connection reset by peer) 16.38.11 # oh, wait, is this not something that's already in the tree? 16.38.27 Join y4n [0] (y4n@unaffiliated/y4ndexx) 16.38.40 # it is in the tree 16.38.53 # Oh, the makefile is setting c99 16.39.10 # metaphys: how are you building this? 16.39.17 # our makefile is adding -std=c99 to the flags 16.39.30 # for rbutil builds too? 16.39.41 # qmake 16.39.44 # make 16.39.57 # oh, wait, yes, you're building rbutil, not mkimxboot 16.40.35 # shouldnt rbtuil just do make for mkimxboot instead of crafting another gcc cmdline? 16.40.54 # no, it's not compiling a seperate binary 16.41.01 # it compiles the code from those tools into itself 16.41.08 # make lib then 16.41.18 # anyway, qt projects don't really work that way 16.41.28 # IIRC this is what it does for mkamsboot 16.41.30 # but not sure 16.41.47 # Ah yes 16.41.58 # metaphys: wait, are you *adding* mkimxboot support to rbutil? 16.42.15 # if so then you need to be doing waht the others do in rbutilqt.pro 16.42.30 # they just invoke make libwhatever in the relevant directories to use our existing makefiles 16.42.39 # then pull in the static libs at link time 16.42.46 # they don't compile the sources again. 16.42.50 # it seems he added mkimxboot.c to rbutil's SOURCES 16.42.58 # Right, yeah. 16.43.05 # Look at how mkamsboot and the other ones work in rbutilqt.pro 16.43.08 # yeah that's it 16.43.10 # and do that. 16.43.34 # I had a problem so I follow what said someone and put it in the pri file 16.43.48 # sorry, it wasn't clear what you were doing, i didn't know this was not currently built 16.44.14 # ok ok are there any other file i should know about :) 16.44.49 # I will do some wiki update after that 16.47.22 # what about that in the wiki ? rbutilqt.cpp : installBootloader() - add a case for your new Bootloaderclass 16.47.57 # I didn't find anything relevant in rbutilqt.cpp about it 16.48.11 # then look in other fiels? maybe it's moved. 16.48.59 # isn't it the serie of 16.49.01 # else if(type == "imx") { 16.49.03 # return new BootloaderInstallImx(parent); 16.49.05 # } 16.49.07 # at the beginning of bootloaderinstallbase.cpp? 16.50.22 # It seems to be it but as I'm planning some edition on the wiki i would like to be sure... 16.50.49 # I'm starting and can pretty much mixing ideas... 16.50.54 Join dreamlayers [0] (~bgjenero@bas4-windsor12-1279316053.dsl.bell.ca) 16.50.54 Quit dreamlayers (Changing host) 16.50.54 Join dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers) 16.52.05 # if what you've done works then it's right, and it seems reasonable to update the docs to match :) 16.53.13 # ok 16.53.38 # let's first having it working then :D !! 16.56.54 Join WalkGood [0] (~4@unaffiliated/walkgood) 16.57.49 Quit pamaury (Remote host closed the connection) 17.02.31 Join SgtPnkks [0] (~wangchung@74-137-161-116.dhcp.insightbb.com) 17.02.35 Part SgtPnkks 17.02.53 *** Saving seen data "./dancer.seen" 17.03.24 Quit dreamlayers (Quit: Will be back later) 17.06.15 Join Misan [0] (~Misanthro@adsl-89-217-198-230.adslplus.ch) 17.34.14 Quit stripwax (Quit: http://miranda-im.org) 17.42.30 Quit factor (Quit: Leaving) 17.43.49 # There is still a problem: 17.43.51 # usr/bin/ld: cannot find -libmkimxboot 17.43.53 # collect2: ld returned 1 exit status 17.43.55 # make: *** [RockboxUtility] Erreur 1 17.43.59 # Seams to be related to the line: 17.44.01 # LIBS += -L$$OUT_PWD -L$$MYBUILDDIR -lrbspeex -lmkamsboot -lmktccboot -lmkmpioboot -libmkimxboot -lucl 17.44.03 # in rbutilqt.pro (I've added -libmkimxboot) 17.44.20 # you mean -lmkimxboot 17.44.26 # -l is the option that means "link a library" 17.44.38 # ok 17.44.40 # the linker adds the "lib" prefix and the appropriate extension for it 17.44.42 # hier it is 17.45.04 # I've writen 'lib' ok 17.45.09 # thanks 17.45.45 # (people abuse -l a lot so it can get confusing: there is a library called libiberty which you therefore use by passing -liberty :) 17.47.19 # :) 17.47.52 # ok and then ladies and gentlement.... back to the nearly beginning :D 17.48.16 # bootloaderinstallimx.cpp:(.text+0x2f1): undefined reference to `mkimxboot(char const*, char const*, char const*, imx_option_t)' 17.48.48 # is it me or the compiler is having smiley? 17.49.32 # hehe depends the way you see it 17.51.19 # this fonction is defined in the mkimxboot.h 17.53.08 Join Kayla_15 [0] (~Kayla_15@app5.chatmosphere.org) 17.53.49 # or shoud i write something so that gcc use the included library? 17.54.45 # guys 15-18, who has a blackberry pvt me:) 17.56.17 Quit Kayla_15 (Client Quit) 17.57.45 Quit GodEater_ (Ping timeout: 265 seconds) 17.58.16 # creeeeepy 18.00.59 # Torne: any idea about this library stuff? 18.01.24 # not without seeing your diff 18.02.08 # i would guess your library doesn't have what you expect in it 18.02.51 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 18.02.51 Quit pamaury (Changing host) 18.02.51 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.03.01 # you means something missing in rbutilqt.pro ? 18.03.19 # Oh, wait 18.03.26 # Now you are missing an extern "C", probably 18.03.29 # becaue that has a typename in it 18.03.30 # :) 18.03.36 # er, type signature, whatever. 18.03.41 # it should just be looking for mkimxboot 18.03.47 # not one with qualified types 18.04.05 # mkimxboot.h needs to be wrapped in the if __CPLUSPLUS__ foo you mentioned before 18.04.19 # otherwise when you include it into rbutil it will expect to be calling C++ code 18.04.19 # ho I've removed the C extern I thought it was not necessary for it didn't solve the problem.... 18.04.30 # It wasn't anything to do with your previous proble, no 18.04.35 # yes like the amsfile 18.04.39 # but you still need it to call C functions from a C++ program 18.04.46 # the C functions' declarations have to be wrapped that way. 18.05.01 # ok let's try this then 18.07.50 # yes! It was it 18.08.41 # new errors! But I'll try to fix it myself... 18.12.05 # a lot of file in the mkamsboot tool have something like that: 18.12.07 # #ifndef O_BINARY 18.12.09 # #define O_BINARY 0 18.12.11 # #endif 18.12.13 # What is it? Do I need that to? 18.12.15 # *too 18.14.40 # it's defining things only if some header hasn't already defined them for you 18.16.45 # umm the error I get now seems to be related with some automatic generated by bin2c file... Those dualboot file that are also in the mkamsboot 18.18.04 Quit WalkGood (Ping timeout: 252 seconds) 18.18.31 Join dreamlayers [0] (~bgjenero@bas4-windsor12-1279316053.dsl.bell.ca) 18.18.31 Quit dreamlayers (Changing host) 18.18.31 Join dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers) 18.18.44 # /home/jean-louis/rockbox-devtree/rockbox/rbutil/rbutilqt/build//libmkimxboot.a(mkimxboot.o):(.rodata+0x68): undefined reference to `dualboot_fuzeplus' 18.19.15 # still a c++ wrapper to add somewhere isn't it? 18.22.53 # no 18.22.59 # that's looking for a C symbol already 18.23.05 # ..er, maybe 18.23.38 # Yeah, sorry 18.23.41 # dualboot.h needs the same treatment 18.23.47 # Any header you include into rbutil 18.24.16 # ..hm, or maybe it's just missing 18.24.19 # funny there isn't much in it and the ams version doesn't have a wrapper 18.24.21 # play with nm ;) 18.24.27 # nm? 18.25.02 # grep -R "CPLUPLUS" ./ 18.25.20 # oups wrong windows ;⁾ 18.25.38 # Ah, yeah 18.29.50 Quit Torne (Ping timeout: 240 seconds) 18.32.30 Join Torne [0] (~torne@rockbox/developer/Torne) 18.33.00 # no this time this is not it 18.34.03 # New commit by 03dreamlayers (r31041): FS#12397 : On targets which load .data directly into its final location and lack code for moving it, remove linker script trick which ignores section ... 18.35.04 Join saratoga [0] (9803c31c@gateway/web/freenode/ip.152.3.195.28) 18.35.42 Quit saratoga (Changing host) 18.35.42 Join saratoga [0] (9803c31c@rockbox/developer/saratoga) 18.36.19 # r31041 build result: 2 errors, 0 warnings (dreamlayers committed) 18.37.10 # Why is svn not terminating and instead still showing "Transmitting file data". The commit is there, and it built already. 18.37.48 # I guess I can quit it with Control-C, but I want to be sure that won't do something bad. 18.37.53 # I've got it 18.37.54 # dreamlayers: stuck post commit script 18.37.54 Join WalkGood [0] (~4@adsl-74-233-24-234.mia.bellsouth.net) 18.38.10 # but I hope I didn't do something bad... 18.38.39 # funman: Did I do something bad and cause a script to hang? 18.38.55 # no 18.39.14 # So, it's safe for me to kill svn now, right? 18.39.25 # I had to change dualboot.c line: 18.39.27 # unsigned char dualboot_fuzeplus[36] = { 18.39.29 # to: 18.39.31 # extern unsigned char dualboot_fuzeplus[36] = { 18.39.37 # <[7]> dreamlayers: just wait, it will terminate in like a minute :) 18.39.44 # <[7]> already had that a couple of times before 18.40.00 # <[7]> metaphys: ouch 18.40.15 # ?? oups? 18.40.27 # <[7]> "extern" and "= {" are kind of a contradiction 18.41.12 # <[7]> you'll probably want to remove one of them, and which one depends on what you're trying to do 18.41.20 # was to nice to be true correcting pamaury code.... ;) 18.42.00 Quit Thra11 (Quit: kthxbai) 18.42.19 Quit WalkGood (Changing host) 18.42.19 Join WalkGood [0] (~4@unaffiliated/walkgood) 18.42.50 # did I do something wrong ? 18.42.57 # I'm trying to get rid of this error: 18.42.59 # /home/jean-louis/rockbox-devtree/rockbox/rbutil/rbutilqt/build//libmkimxboot.a(mkimxboot.o).rodata+0x68): undefined reference to `dualboot_fuzeplus' 18.43.33 # no I guess this is just me that don't know how to make the code compile inside rbutil 18.43.57 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.44.14 Quit antil33t (Read error: Connection reset by peer) 18.44.20 # there was a cpluplus wrapper missing in mkimxboot but I'm stuck on this one... 18.44.29 # are you sure dualboot.c is compiled in ? 18.44.32 Join antil33t [0] (~antil33t@101.98.148.94) 18.45.09 # ha it could be the problem what do I have to do to have it compiling? 18.46.15 # not sure, there might be a subtlety if the #include "dualboot.h" is within extern "C" {} 18.46.52 # ok I can try that 18.46.55 # did you touch the mkimxboot code ? can you pastebin the diff ? have you check that the standalone executable still compiles ? 18.48.08 # yeah I checked that by every change 18.48.23 # didn't change a lot through 18.49.19 # only adding the C++ wrapper and moving #include "sb.h" to "../../utils/imxtools/sb.h" 18.49.32 Join Thra11 [0] (~thrall@87.114.77.12) 18.49.45 # why did you change this #include ? 18.50.33 # because else he's not happy but I was wondering If there was perhaps a way to include the whole directory 18.51.15 # see IMXTOOLS_DIR=../../utils/imxtools/ in Makefile, it's already included at compile time 18.52.23 # I don't now it seems to work 18.53.03 # now 18.53.10 Quit bluefoxx (Read error: Connection reset by peer) 18.53.35 Join bluefoxx [0] (FuzzyLomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 18.55.39 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.02.54 *** Saving seen data "./dancer.seen" 19.16.47 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 19.17.04 Quit Zoiah (Ping timeout: 260 seconds) 19.17.29 # pamaury: time to remind you :-) 19.17.33 Join Zoiah [0] (zoiah@matryoshka.zoiah.net) 19.17.48 # thanks, give me two minutes :) 19.17.50 Join Keripo [0] (~Keripo@165.123.49.248) 19.18.34 Quit bluefoxx (Quit: bluefoxx) 19.20.34 Join lebellium [0] (~chatzilla@91-65-137-216-dynip.superkabel.de) 19.22.19 Quit Keripo (Ping timeout: 260 seconds) 19.22.40 # svn is still waiting after r31041 commit "Transmitting file data", with an established connection to giant.haxx.se 19.24.50 Part metaphys 19.27.01 # kugelp: what is list_line_padding exactly ? I feel the current french translation is not accurate 19.27.34 Join Strife89 [0] (~Strife89@207.144.201.128) 19.28.16 # pamaury: x pixels added to the font height for the line height 19.30.02 # hum, translating this is tricky :) 19.38.08 Quit WalkGood (Ping timeout: 244 seconds) 19.40.09 # New commit by 03pamaury (r31042): Update french translation 19.40.28 # kugelp: do I need to commit this to a banch too ? 19.42.03 # r31042 build result: 2 errors, 0 warnings (pamaury committed) 19.49.06 Join lorenzo92 [0] (~chatzilla@host197-107-dynamic.45-79-r.retail.telecomitalia.it) 19.50.23 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.52.54 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/) 19.54.59 Join metaphys [0] (~jean-loui@d86-32-96-55.cust.tele2.at) 19.55.59 # I killed the hanging svn, and had to kill -9. I wonder if it's just a broken local svn binary. I had to compile it from source because Debian only has svn 1.6. Is there a known good package I could use? For now I'll do commits from Cygwin, because it has a subversion 1.7 package. 19.56.06 Join ReimuHak_ [0] (~reimu@165.139.179.10) 20.09.11 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111115183813]) 20.12.36 Quit Strife89 (Quit: Vamoose!) 20.13.43 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 20.15.27 Join WalkGood [0] (~4@adsl-74-233-24-234.mia.bellsouth.net) 20.18.53 Quit WalkGood (Changing host) 20.18.53 Join WalkGood [0] (~4@unaffiliated/walkgood) 20.19.09 Part WalkGood 20.25.50 Join Llorean1 [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) 20.27.55 Quit Llorean (Ping timeout: 245 seconds) 20.29.29 # i had svn hang the other day 20.29.58 Quit ReimuHak_ (Quit: Leaving...) 20.41.55 Quit Misan (Remote host closed the connection) 20.43.08 Join Keripo [0] (~Keripo@seas692.wireless-pennnet.upenn.edu) 20.43.59 Part metaphys 20.45.51 Quit dreamlayers (Quit: brb) 20.48.29 Join dreamlayers [0] (~dreamlaye@bas4-windsor12-1279316053.dsl.bell.ca) 20.48.30 Quit dreamlayers (Changing host) 20.48.30 Join dreamlayers [0] (~dreamlaye@rockbox/developer/dreamlayers) 20.48.40 Join metaphys [0] (~jean-loui@d86-32-96-55.cust.tele2.at) 20.49.11 Part metaphys 20.59.33 # New commit by 03dreamlayers (r31043): FS#12378 : Removal of Archos HWCODEC unused code and data. Several large hardware-specific functions are kept for reference or future use. 20.59.43 Join metaphys [0] (~jean-loui@d86-32-96-55.cust.tele2.at) 20.59.51 Part metaphys 21.01.02 Quit Keripo (Quit: Leaving.) 21.01.56 # r31043 build result: 2 errors, 0 warnings (dreamlayers committed) 21.01.58 Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) 21.02.55 *** Saving seen data "./dancer.seen" 21.07.36 # svn is hanging again, this time in Cygwin. This means there's probably a server-side issue. Fortunately, besides the hanging, everything seems to be working fine. 21.11.09 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 21.11.10 Quit bertrik (Changing host) 21.11.10 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 21.12.41 Join robin0800 [0] (~robin0800@149.254.60.163) 21.15.01 # Is there any reason why SH targets can't have INIT_ATTR? 21.22.55 Quit scorche|sh (Ping timeout: 245 seconds) 21.25.38 # New commit by 03bertrik (r31044): FS#12399 - Second november update of Czech language by Marek Salaba 21.27.43 # r31044 build result: 2 errors, 0 warnings (bertrik committed) 21.30.53 # dreamlayers: probably not 21.32.55 Join Strife89 [0] (~Strife89@207.144.201.128) 21.33.01 Join scorche|sh [0] (~scorche@squisch.net) 21.33.24 # I like this cabbie v2 port for sansa clip zip in FS#12390 . Any remarks / objections / fixes for this? 21.33.24 # http://www.rockbox.org/tracker/task/12390 3Sansa Clip Zip Cabbiev2 Port (patches, unconfirmed) 21.35.59 # pamaury, I think we can apply the 64-byte packet fix to AMSv2 too, right? (it's not going to get worse ... :) ) 21.36.34 Join hilbert [0] (~hilbert@adsl-89-217-170-127.adslplus.ch) 21.37.03 Quit robin0800 (Read error: Operation timed out) 21.42.09 # New commit by 03lenzone10 (r31045): Updated italian translation. 21.44.12 # r31045 build result: 3 errors, 0 warnings (lenzone10 committed) 21.47.05 Join TheLemonMan [0] (~giuseppe@adsl-ull-171-211.50-151.net24.it) 21.49.45 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.51.41 Quit saratoga (Ping timeout: 265 seconds) 21.54.08 Quit domonoky (Quit: Leaving.) 21.57.13 # pamaury: yes but I can handle that later 21.57.20 # if you like 21.57.33 Quit Sundiver (Ping timeout: 244 seconds) 22.00.32 Join domonoky [0] (~Domonoky@agsb-4d04021a.pool.mediaWays.net) 22.00.33 Quit domonoky (Changing host) 22.00.33 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 22.00.59 Join Buschel [0] (~chatzilla@p54B66C4E.dip.t-dialin.net) 22.03.07 Quit stripwax (Quit: http://miranda-im.org) 22.06.57 # kugelp: that would be nice of you :) 22.07.14 # bertrik: yes, but I didn't test the patch I wrote :) 22.08.39 Join robin0800 [0] (~robin0800@149.254.60.168) 22.14.21 Join metaphys [0] (~jean-loui@d86-32-96-55.cust.tele2.at) 22.17.27 Quit dreamlayers () 22.17.53 Part metaphys 22.18.23 Quit benedikt93 (Quit: Bye ;)) 22.22.29 Join MethoS- [0] (~clemens@134.102.106.250) 22.27.30 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243]) 22.29.24 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 22.38.43 Quit TheLemonMan (Remote host closed the connection) 22.39.58 Join ReimuHak_ [0] (~reimu@208.119.81.194) 22.41.43 Join TheLemonMan [0] (~giuseppe@adsl-ull-171-211.50-151.net24.it) 22.48.14 Join icarusfactor [0] (~factor@74.197.205.204) 22.57.30 Quit TheLemonMan (Remote host closed the connection) 23.02.57 *** Saving seen data "./dancer.seen" 23.05.15 Quit Strife89 (Read error: Connection reset by peer) 23.16.46 Join Strife89 [0] (~Strife89@207.144.201.128) 23.23.45 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 23.30.22 Quit Strife89 (Quit: Heading out) 23.37.02 Quit lmh (Ping timeout: 248 seconds) 23.37.46 Join lmh [0] (lmh@nat/redhat/x-plxixpxposwgapbj) 23.45.28 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 23.54.39 Quit wodz (Quit: Leaving)