--- Log for 25.01.109 Server: grisham.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 10 hours ago 00.02.27 # It's in RButil? 00.02.59 Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) 00.04.20 Quit killan_ (Read error: 104 (Connection reset by peer)) 00.05.18 Join solexx_ [0] (n=jrschulz@e176118056.adsl.alicedsl.de) 00.08.07 # low_light: two yellows to work on now then! ;-) 00.10.05 Join QuickStart [0] (n=QUICKSTA@pool-72-88-190-6.nwrknj.east.verizon.net) 00.10.47 Quit jhMikeS (Nick collision from services.) 00.10.53 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 00.12.16 # 95 builds 00.12.52 Quit solexx (Read error: 60 (Operation timed out)) 00.13.39 Quit bertrik ("Leaving") 00.14.34 Join yhuang [0] (n=yhuang@nat01-voorhees-ext.rutgers.edu) 00.15.48 Quit HBK (Client Quit) 00.19.20 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 00.22.07 Quit parafin (Read error: 60 (Operation timed out)) 00.22.57 Quit obo (Read error: 60 (Operation timed out)) 00.23.02 Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) 00.32.27 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 00.38.25 Quit n1s () 00.38.38 Join slyyf [0] (n=slyf@142.46.8.26) 00.39.02 # Hey guys, I am modding the conwond2 because I foundout it actually boots on the P2 00.39.18 # I compiled it, it worked, well, booted and told me there was no power left.. 00.39.19 # BUT 00.39.32 # I changed the resolution so it would actually looks proper 00.39.36 # and now it wont compile 00.40.19 # A bunch of things tell me the lcd isnt supported, and other things tell me something_X not defined 00.40.32 # is there something that contains a list of resolutions the lcd supports? 00.40.53 # there is things in the code that depend on the screen size, yes 00.41.32 # Bagder: K, any idea what I should do? 00.41.53 # yes, edit/fix those places of the code 00.42.52 # can I just not build the apps? 00.43.21 # you mean the plugins? 00.43.35 # yes 00.43.44 # those are not the only things in rockbox that need the size fine 00.43.56 # ah ok 00.43.59 # but disabling them is a start 00.44.18 # Is there something I should pass to make to do that? 00.44.26 # edit configure 00.44.28 # ah 00.46.45 # Thanks for your help, I am not used to this codebase yet 00.52.29 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 00.53.17 Join v445 [0] (n=chatzill@lns-bzn-60-82-254-211-239.adsl.proxad.net) 00.54.28 Quit v445 (Client Quit) 00.57.28 # What is the significance of LCD_Pixelformat? 00.57.49 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 00.58.01 # Oh, nevermind 00.58.21 Join tvelocity [0] (n=tony@adsl18-57.her.forthnet.gr) 01.00.43 # I am trying now to load the firmware and I would like to know if there is diferencies between bootloader and application linkers scripts files (.lds) 01.01.04 # Bagder: is there any big diferencies? 01.01.23 Quit _lifeless (Remote closed the connection) 01.01.53 # casainho: I'm not sure, but I think you need to add codecs and plugin sections 01.01.58 Join _lifeless [0] (n=lifeless@94.50.176.150) 01.02.21 # kugel: ok, I will look on that ;-) 01.02.42 # * kugel isn't the man to talk with about lds though 01.02.45 # the code mounts correctly the FAT partition ;-) 01.02.52 # cool 01.03.20 Join tvelocity[a] [0] (n=tony@adsl2-230.her.forthnet.gr) 01.03.29 # and I think I need to use load_raw_firmware(), right? 01.03.32 # The framebuffer doesnt appear to like that resolution, even though it compiled correctly, does anybody know of any code that should be changed when changing resolution? 01.03.54 # casainho: no, load_firmware should be it 01.05.24 # slyyf: have you changed LCD_WIDTH and LCD_HEIGHT? 01.05.36 # kugel: do you know why not the load_raw_firmware? 01.05.40 # that should be sufficient actually, at least if the lcd driver is done right 01.05.47 # kugel: what are the diferencoies? 01.06.03 # casainho: no, but almost every other target uses load_firmware 01.06.41 # I'd guess raw doesn't handle the header, which is added to the binary by scramble 01.07.06 # ah, okok :-) 01.07.10 # and load_firmware does handle is (reading the model string and doing a basic checksum) 01.07.37 # kugel: Yes, that is what I changed, I am booting the ConwonD2 firmware on the P2, with the smaller resolution it wasnt using the screen corectly, but was readable, now its not readable, but uses the whole screen 01.08.51 # slyyf: well, I don't know d2 code, but you should look into the lcd driver 01.09.18 # the other code is basically known to be independent of the resolution if LCD_HEIGHT and LCD_WIDTH are correct 01.09.57 # it might be, that in some spots in the lcd driver the immediate nummber is used instead of LCD_WIDTH/_HEIGHT 01.11.14 # kugel: I dont know much about LCDs, but there is something in here setting an HTIME, and a VTIME, is that resolution dependent? 01.12.01 # maybe 01.12.04 # I can't really tell you 01.12.24 # I would just look out for numbers which are equal to the D2's lcd dimensions 01.12.41 # or 1 lower 01.12.52 Join parafin [0] (i=parafin@paraf.in) 01.13.31 # I looked for the actual resolution, I will look for one lower 01.13.32 # e.g. if the x resolution is 320, you should search for 320 and 319 (and replace them with LCD_WIDTH and LCD_WIDTH-1 respectively) 01.13.49 # every other change is probably just guess work 01.13.54 # kugel: Be careful. 01.13.57 # kugel: Yes, looking 01.14.01 # There could be 320 and 319 for other reasons. 01.14.16 # Llorean: of course 01.14.27 # I should've been clearer, sorry 01.14.47 # AHHA 01.14.58 # LCDC_VTIME1 = LCDC_VTIME3 = (0<<16) | 239; 01.15.07 Quit Lynx_ (Remote closed the connection) 01.15.07 Join tvelocity[away] [0] (n=tony@adsl26-98.her.forthnet.gr) 01.15.12 # its 320x240 01.15.52 # slyyf: see, this might be a good catch. but as Llorean said, those number doesn't necessarily have to be the lcd dimensions (it's worth a try though I'd say) 01.16.08 # I will try it 01.16.29 Quit tvelocity (Connection timed out) 01.16.46 # slyyf: oh, and if you succeed, make a photo! ;) 01.17.43 # kugel: Its still displaying all funkly ): 01.17.51 # Oh, should I have reconfigured and make cleaned? 01.17.58 # I just ran make 01.18.17 # not sure 01.18.25 # better to play safe I guess 01.18.48 # Ok, it'l take a few mins to build 01.18.49 Join akur [0] (n=akur@bl5-224-196.dsl.telepac.pt) 01.19.11 # I don't think make clean is needed actually 01.19.43 # kugel: I didnt recompile anything, so I did so anyways, all it did was rebuild the image from the existing buid 01.19.49 # slyyf: well, if that all doesn't work, I can't really help you. I haven't even looked once into the d2 code 01.19.56 # No prob 01.20.11 # Is there a configure option to not bother compiling all the codecs? 01.20.17 Quit parafin (Read error: 60 (Operation timed out)) 01.20.36 # I just recall, that the lcd is the only real thing known to be different between the d2 and p2, so it might require more work 01.20.51 # slyyf: make bin 01.22.01 # slyyf: how "readable" was it exactly without changing the code? 01.22.06 # Very 01.22.13 # It told me there was no battery power 01.22.28 # Maybe this doc I read that told me the lcd resoltion was wrong.. 01.22.41 # ? 01.22.43 # nope, its right 01.23.13 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-0eba24094a8f99b3) 01.23.16 # atm it looks like..youknow the old crt monitors when you would put them into an improper resolution..like that 01.26.00 # whats 0x3bf as an int.. 01.26.24 # google "0x3bf in decimal" 01.28.43 # kugel: you done any more work on the custom vp patch? 01.29.33 # not recently, no 01.29.37 # woo 3 more builds! 01.29.39 Quit tvelocity[a] (Success) 01.31.34 # lol whens the release 01.35.21 # JdGordon: what builds? 01.35.42 # the phillips player 01.36.05 # what does lcd_update_rect do? 01.36.27 Quit tvelocity[away] (Connection timed out) 01.37.13 # Updates a portion of the LCD instead of the whole LCD 01.37.47 # JdGordon: ah it was added to the build table, I didn't notice 01.38.19 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) 01.41.27 Quit jhMikeS (Nick collision from services.) 01.41.33 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 01.52.36 Quit Acksaw (Read error: 110 (Connection timed out)) 01.53.24 *** Saving seen data "./dancer.seen" 01.55.42 Part akur 01.56.43 Quit QuickStart (Remote closed the connection) 02.03.16 Quit casainho ("ChatZilla 0.9.84 [Firefox 3.0.5/2008121622]") 02.10.34 Quit ender` (" They could trim up the framework by treating System.DBNull the same as String.Empty, ala Oracle-style...") 02.15.37 Join parafin [0] (n=operator@paraf.in) 02.15.37 Quit parafin (Remote closed the connection) 02.22.34 # kugel: It appears to need to fiddle with the bpp value, allthough I will have to digup a datasheet for the controller 02.26.10 Quit T0paz (Read error: 60 (Operation timed out)) 02.32.17 Quit kugel (Read error: 110 (Connection timed out)) 02.32.38 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 02.33.12 # T0paz (logs): I'll be having exams, so I won't be around the next 3 days or so 02.36.20 Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) 02.37.21 Join goffa [0] (n=goffa@216.220.23.105) 02.38.10 Quit mcuelenaere () 02.40.34 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 02.42.40 Quit BigBambi (Remote closed the connection) 02.43.05 Quit SirFunk (Remote closed the connection) 02.43.30 Quit culture (Read error: 110 (Connection timed out)) 02.43.50 Join parafin [0] (i=parafin@paraf.in) 02.44.25 # I hate datasheet hunting 02.45.12 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 02.45.46 Quit SirFunk (Remote closed the connection) 02.47.07 Join QuickStart [0] (n=QUICKSTA@pool-72-88-190-6.nwrknj.east.verizon.net) 02.47.23 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 02.47.57 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 02.52.38 Join MethoS [0] (n=lem@dyndsl-085-016-167-190.ewe-ip-backbone.de) 02.54.46 Join akur [0] (n=akur@bl5-224-196.dsl.telepac.pt) 02.54.57 Part akur 02.55.06 Join tvelocity [0] (n=tony@adsl22-80.her.forthnet.gr) 02.55.28 Join gromit` [0] (n=gromit@ALagny-154-1-5-156.w83-112.abo.wanadoo.fr) 02.57.31 # I think I found it 02.57.43 Quit efyx (Remote closed the connection) 03.00.00 Quit QuickStart (Read error: 104 (Connection reset by peer)) 03.00.03 Quit MethoS (Remote closed the connection) 03.03.30 # Ohh, this one has an onboard controller 03.03.45 Quit gromit`` (Read error: 110 (Connection timed out)) 03.09.49 Join kugel [0] (n=kugel@e178080021.adsl.alicedsl.de) 03.10.13 Quit low_light ("CGI:IRC 0.5.9 (2006/06/06)") 03.10.48 # Unhelpful: I think I can finally test pf here 03.13.29 Join kugel__ [0] (n=kugel@e178080021.adsl.alicedsl.de) 03.13.41 Quit kugel (Nick collision from services.) 03.13.42 # i hope you have some tall covers like me, that will pop over the gap :D 03.13.43 Nick kugel__ is now known as kugel (n=kugel@e178080021.adsl.alicedsl.de) 03.15.23 Join phinze [0] (n=phinze@173-19-89-233.client.mchsi.com) 03.16.05 # Unhelpful: well, the database doesn't initialize 03.16.40 # gah, what? the DB worked on the sim... 03.16.43 Quit tyfoo (Read error: 104 (Connection reset by peer)) 03.17.47 # have you used DB before on clip? 03.18.28 # meh 03.18.42 # I have the feeling that my clip is broken.. 03.18.47 # I just can't get a working FS 03.20.18 # fsck perhaps? 03.21.20 Join toffe82_ [0] (n=chatzill@71.154.234.29) 03.21.23 # I just formatted several times 03.21.56 # heh, if it's still hosed after a format, yes, you may have a real problem :/ 03.22.28 Join tvelocity[a] [0] (n=tony@adsl8-242.her.forthnet.gr) 03.26.34 # is it possible, that storage doesn't work with fat32, but only fat? 03.27.06 # the sansa OF uses fat, but I need to format to fat32 to make rockbox work 03.27.27 # I'll try to enable fat16 support in rockbox, and let the OF format, later 03.28.51 Quit toffe82 (Read error: 145 (Connection timed out)) 03.30.33 Join tvelocity[away] [0] (n=tony@194.219.255.36) 03.32.54 Quit BigBambi (Remote closed the connection) 03.35.16 Quit tvelocity[away] (Remote closed the connection) 03.35.50 Join Buri [0] (i=twilit_p@adsl-71-130-223-153.dsl.irvnca.pacbell.net) 03.35.57 Quit tvelocity (Connection timed out) 03.37.09 Join QuickStart [0] (n=QUICKSTA@pool-72-88-190-6.nwrknj.east.verizon.net) 03.42.26 Quit PaulJam (".") 03.42.34 Part Buri 03.45.05 Quit tvelocity[a] (Connection timed out) 03.45.15 Join barrywardell [0] (n=barrywar@79.97.89.191) 03.48.49 Quit phinze ("leaving") 03.49.05 Join phinze [0] (n=phinze@173-19-89-233.client.mchsi.com) 03.53.10 Quit Nico_P (Remote closed the connection) 03.53.25 *** Saving seen data "./dancer.seen" 03.54.16 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 03.55.13 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 04.00.49 Quit QuickStart (Read error: 104 (Connection reset by peer)) 04.06.48 Join Barahir_ [0] (n=jonathan@BAI0910.bai.pppool.de) 04.09.23 Quit Strife89 ("Bed.") 04.10.13 Quit yhuang (Read error: 60 (Operation timed out)) 04.15.05 Join blkhawk- [0] (n=blkhawk@g226128002.adsl.alicedsl.de) 04.17.47 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 04.20.39 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 04.22.37 Quit Barahir (Read error: 110 (Connection timed out)) 04.27.28 Join Zembla [0] (n=zembla@91.180.199.194) 04.30.19 # hi 04.30.39 # I was wondering, is it feasible to install rockbox on a non-formatted iPod? 04.31.10 # The Rockbox installation requires a working iPod first. 04.31.30 # right, so then that it's filled to the brim with music is not a hindrance? 04.32.12 # As long as there's space for the Rockbox files. 04.32.24 Quit blkhawk (Read error: 110 (Connection timed out)) 04.32.42 # ok, will it recognise the music files already present in my iPod? 04.33.03 Nick blkhawk- is now known as blkhawk (n=blkhawk@g226128002.adsl.alicedsl.de) 04.33.15 # and if so, will it arrange/sort them like the original firmware would? 04.33.24 # just a matter of hitting the ground running :) 04.33.39 # Zembla: that rather depends what format they are in. the answer you are probably looking for is that it will play all files the ipod OF plays, except DRMed ones (iiuc) 04.34.40 # righto, then installing rockbox will change nothing to the usual way of using the ipod (in the sense that I can always boot into the OF), it won't disrupt itunes or any of that? 04.35.26 # am I correct in understanding that it's basically a dual boot system for my ipod, and that either interfaces won't interfere with the basic system functions of the others (to put it vaguely) 04.39.08 Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) 04.46.49 # Zembla: that's the theory at least. i don't have an ipod so i hesitate to answer with any kind of assurance. 04.47.06 # but the theory holds up for the specific device you use it on? 04.48.33 # Zembla: yes (e200). although i barely use the OF, they don't interfere with each other 04.49.16 # Zembla, it is a dual-boot system. rockbox will not affect the functioning of the apple firmware 04.49.27 # ok 04.57.21 Quit Thundercloud (Read error: 104 (Connection reset by peer)) 05.03.41 # right, well, thanks for all the help, trying it right now 05.03.43 # c ya later 05.03.48 Quit Zembla ("For great justice!") 05.11.13 Join midkay [0] (n=midkay@rockbox/developer/midkay) 05.12.39 # *grumbles* telechips decided to password there downloads section 05.12.43 # I need the datasheet 05.16.39 # Found one for the TC76.may help 05.30.08 Join Darksair [0] (n=user@221.221.155.112) 05.41.46 Quit XavierGr () 05.49.20 # Does aybody have a copy of the tcc78x datasheet? 05.49.21 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 05.49.58 Part Aurix_Lexico 05.52.24 Join caveman26 [0] (n=caveman@c-71-59-172-124.hsd1.wa.comcast.net) 05.53.16 Quit Makuseru (Read error: 104 (Connection reset by peer)) 05.53.28 *** Saving seen data "./dancer.seen" 05.53.56 # any info on a rockbox build for the samsung t9? 05.57.14 # caveman26: none thus far 05.58.01 # caveman26, there is a thread about the t9 but it is not supported yet 06.02.46 Quit Zoxc () 06.05.03 # darn 06.05.06 # ok 06.06.49 # well I was just curious.. I had a sansa c200 with rockbox.. the os was nice but the sansa had terrible audio outputs.. the t9 has truly good sound and, but a crappy OS that plays ogg files, but crashed at that crashes at the end of some of the songs 06.07.17 # brb 06.14.12 # caveman26, the sansa fuze and clip can play ogg vorbis with the sansa firmware and rockbox is being worked on for both of them and they have better sound quality compared the PP based sansa.. there is c200v2 and e200v2 that uses the same chip as the clip and fuze.. there is a v2 clip and v2 fuze, but i am not sure how far they are compared to the v1 clip and v1 fuze 06.21.30 # anybody understand this bitwise: LCDC_HTIME1 = (0x2d<<16) | 0x3bf; 06.31.57 # slyyf: you might want to specify which you're asking: (what does it do/why does it do it/what do the numbers mean/why isn't it doing something else) 06.32.57 # I figured it out 06.33.11 # its the problem I have been hunting down for the past four hours 06.33.20 # er..or more 06.33.21 # ah, congrats :) 06.34.15 # 3bf=((width of screen*3)/width of pixel)-1 06.36.56 # advcomp2019: do you know what FS bug is playback on fuze? 06.38.11 # tmzt, nope 06.38.22 # whats the battery life like on this new sansa's 06.39.26 # I know the battery in my c200 seemed like it would go on forever... if i could deal with crappy anlog section long enough 06.40.56 # as a matter of fact i never once ran it completely dead, unless I forgot to turn it off 06.41.49 # so I do give sansa credit for one hell of a good battery 06.48.58 # caveman26, the clips is about 13 hours.. i have not checked how long with rockbox for sure.. the fuze from what i heard is about 20 hours.. i do have a fuze but i have not test rockbox on it because it is v2 fuze 06.49.50 # advcomp2019: audio playback works on clip in rockbox? 06.51.07 # I have V01.01.11T, after installing rockbox bootloader made with mkams using that version 06.51.16 # I assume that means it's a v1? 06.51.32 # fuze 06.52.01 # there is still playback issues on the clip 06.52.18 # yea you have v1 fuze 06.52.35 # slyyf: are you serious about that last part? 06.53.33 # my fuze doesn't playback at all (mp3 or wav at least) and freezes when trying, current svn, the divide by zero change didn't affect it 06.56.58 Join pronto [0] (n=pronto@pool-173-69-168-151.bltmmd.fios.verizon.net) 06.59.30 Part toffe82_ 07.00.18 Join yhuang [0] (n=yhuang@nat01-voorhees-ext.rutgers.edu) 07.10.04 Join CaptainKwel [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 07.12.52 # tmzt: which part? 07.13.09 # tmzt: that math? yes, I checked the datasheet 07.14.36 # I mean what it means, 3*the width part 07.14.51 # 3bf=((width of screen*3)/width of pixel)-1 07.15.17 # tmzt: Yes, but I just now nottices thats the same as width in pixels*3 07.15.32 # talk about overcomplicating things 07.15.52 # I think... 07.17.05 # I haven't read the datasheet for this device, it's just commonly used to set certain bits 07.22.42 # ah, no, your right 07.22.43 # BUT 07.22.50 # I was tyring to figure out why it was setting taht 07.22.58 # and thats what the value its setting in is 07.23.01 # not the operation it preforms 07.23.54 Quit caveman26 (Remote closed the connection) 07.23.56 # you mean it's a packed 24-bit display? 07.25.05 # Ya, I believe so 07.25.43 # Now I am just trying to figure out why it thinks its twice as wide as it is and puts everything wider then it should thus cropping it 07.27.51 Quit CaptainKewl (Read error: 110 (Connection timed out)) 07.30.05 Quit CaptainKwel (Read error: 110 (Connection timed out)) 07.52.40 Quit phinze (Read error: 110 (Connection timed out)) 07.53.31 *** Saving seen data "./dancer.seen" 07.56.03 Quit JdGordon (Remote closed the connection) 07.59.08 Quit Darksair ("Emacs = ESC-Meta-Alt-Ctrl-Shift") 08.07.02 Quit suom1 (Read error: 104 (Connection reset by peer)) 08.07.40 Join JdGordon [0] (n=Miranda@123-243-140-31.static.tpgi.com.au) 08.08.16 Join suom1 [0] (i=markus@viitamaki.net) 08.16.47 Join romain_ [0] (n=romain@peerfuse.org) 08.16.47 Quit romain (Read error: 104 (Connection reset by peer)) 08.26.43 Quit rocko ("Leaving") 08.49.13 Join at0m [0] (n=a548c80b@gateway/web/cgi-irc/labb.contactor.se/x-ed331d773666bf95) 08.58.39 Join Rob2223 [0] (n=Miranda@p4FDCE306.dip.t-dialin.net) 09.01.10 Part pronto 09.09.01 Join n1s [0] (n=nils@rockbox/developer/n1s) 09.10.54 Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) 09.13.54 Join fyrestorm [0] (n=fyre@cpe-68-173-234-24.nyc.res.rr.com) 09.21.01 Quit markun (Remote closed the connection) 09.22.01 Quit slyyf (Read error: 110 (Connection timed out)) 09.29.17 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.45.02 Join ranol [0] (n=ranol@p3EE3C5B7.dip.t-dialin.net) 09.48.34 Part ranol 09.53.35 *** Saving seen data "./dancer.seen" 09.53.55 Join markun [50] (n=markun@rockbox/developer/markun) 10.21.26 Join flydutch [0] (n=flydutch@host5-154-dynamic.14-87-r.retail.telecomitalia.it) 10.27.51 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.28.40 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) 10.42.15 Quit at0m ("CGI:IRC") 10.43.05 Quit JdGordon (Read error: 104 (Connection reset by peer)) 10.43.39 Quit Acky (Connection timed out) 10.45.30 Join JdGordon [0] (n=jonno@123-243-140-31.static.tpgi.com.au) 10.47.56 Quit Horschti ("Verlassend") 10.56.03 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 11.00.20 Join casainho [0] (n=chatzill@89.180.98.234) 11.00.54 # hello :-) 11.01.06 # I am getting this error: /home/cas/Documentos/rockbox_player/rockbox/build/apps/action.o: In function `get_action_worker': 11.01.08 # action.c:(.text+0x2b8): undefined reference to `get_context_mapping' 11.01.27 # look in the apps/keymaps/keymap-* files 11.02.08 # I am trying to build the firmware... and that error and others happens on linker stage, right on the end of the building... 11.02.16 # look in the apps/keymaps/keymap-* files 11.03.11 # are you sure? because I am getting other erros like: 11.03.33 # rockbox_player/rockbox/build/firmware/libfirmware.a(pcm.o): In function `pcm_play_data_start': 11.03.35 # pcm.c:(.text+0x274): undefined reference to `pcm_play_dma_start' 11.03.57 # they are two completly different problems 11.05.55 # please look here: http://pastebin.com/md720ff 11.06.00 # casainho, link errors like that are to be expected for subsystems that are not implemented yet. What was done for the clip, was creating "stubs" for those functions. 11.07.46 # stubs? empty functions? 11.08.01 # a stub (at least that's how I call it) is indeed an empty function 11.08.39 # :-) 11.10.42 # so, do I have to creat a keymap-*.c for my target? is tere any wiki page explaining what I have to do, on this stage? 11.10.56 Join culture [0] (n=none@cpc2-bele3-0-0-cust89.belf.cable.ntl.com) 11.12.28 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 11.13.56 # casainho, I don't know about the keymap-*.c file, but I think there's no wiki page to explain it. You'll probably just have to look at files for other targets to get an idea on how to implement it. 11.14.18 Join Mirra [0] (n=michael@p57B2E1A4.dip.t-dialin.net) 11.14.34 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 11.14.38 # okok - luckly someone put on source a "keymap-newtarget.c" with some explanations ;-) 11.15.00 Join gregzx [0] (n=chatzill@drx15.neoplus.adsl.tpnet.pl) 11.15.09 # Bagder: the build-info file now has a release section, but that is empty. Can you check that? 11.15.14 # hm.. so rockbox will not work on my nano 3rd generation?! 11.15.28 # Mirra: thats what the front page says.. 11.16.42 # yeah, but maybe there has been some development, which made it possible..? *littlehope* 11.17.00 # no 11.17.15 # is it actually possible? 11.17.20 # Mirra: scroll down. Then: Page was last modified "Jan 9 2009" 11.17.23 # I mean from a technical poin of view 11.17.50 # Mirra: it sure isnt possible when no one is working on it 11.17.53 # if you figure how to break into the encryption system and figure the hardware itself, ... 11.18.40 # I guess we're not talking about the itunes.db file (wit the SHA-hashs of the songs) 11.18.50 # no 11.19.01 # :/ 11.21.37 Quit Mirra (Read error: 60 (Operation timed out)) 11.23.17 Join Mirra [0] (n=michael@p57B2E1A4.dip.t-dialin.net) 11.25.09 # Unhelpful: I don't fully get your reply re. action contexts in PF. My statement was just a suggestion to only have one or two generic PLA contexts at all that make sense and scrap all the others. If you need more or something else than that, let your plugin use its own button or action definitions, don't "connect" it to others with using PLA. In pf I think that such a generic one (like I described) could work, that's all. 11.25.38 Part Mirra ("Konversation terminated!") 11.27.15 Join tyfoo [0] (n=tyfoo@77-20-31-238-dynip.superkabel.de) 11.28.19 # in its current form, the vertical list browsing is broken on e.g. the c200 anyways 11.36.17 Join {phoenix} [0] (n=dirk@p54B4588D.dip.t-dialin.net) 11.53.36 *** Saving seen data "./dancer.seen" 11.56.20 # - 11.58.44 Join PaulJam [0] (i=Paule@vpn-3022.gwdg.de) 12.03.47 Quit barrywardell () 12.12.33 Join MethoS [0] (n=lem@host-091-096-215-118.ewe-ip-backbone.de) 12.15.16 Join ender` [0] (i=krneki@foo.eternallybored.org) 12.21.10 Join faemir [0] (n=daniel@88-106-244-173.dynamic.dsl.as9105.com) 12.28.40 Join gregzx_ [0] (n=chatzill@dst64.neoplus.adsl.tpnet.pl) 12.29.55 Quit gregzx_ (Client Quit) 12.32.08 Quit gregzx (Read error: 104 (Connection reset by peer)) 12.35.34 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.36.46 Quit robin0800 (Read error: 54 (Connection reset by peer)) 12.37.32 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.39.55 Quit robin0800 (Remote closed the connection) 12.39.58 Join pyro_maniac [0] (n=jens@77-21-68-46-dynip.superkabel.de) 12.40.05 Join wpyh [0] (n=william@123.114.170.122) 12.41.22 # Unhelpful: ping 12.49.31 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.50.48 Quit robin0800 (Remote closed the connection) 12.52.40 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.52.52 Quit MethoS (Remote closed the connection) 12.53.13 Join MethoS [0] (n=lem@host-091-096-215-118.ewe-ip-backbone.de) 12.57.14 Quit MethoS (Remote closed the connection) 12.58.49 Quit robin0800 (Remote closed the connection) 12.59.02 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.59.31 Join tvelocity [0] (n=tony@adsl22-52.her.forthnet.gr) 13.10.38 Quit casainho ("ChatZilla 0.9.84 [Firefox 3.0.5/2008121622]") 13.12.13 Quit {phoenix} (Remote closed the connection) 13.21.45 Join MethoS [0] (n=lem@host-091-096-215-118.ewe-ip-backbone.de) 13.24.39 # bluebrother: http://download.rockbox.org/daily/build-info is now meant to get the release info 13.25.04 # due to a little mistake of mine it doesn't yet, but it should get there in the next update 13.26.20 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 13.32.48 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 13.33.39 # Bagder: ok. I guess next update means next daily build? 13.33.49 # exactly 13.35.40 # ok. I'll finish rbutil and test tomorrow then. Now the only thing I'd like to get a good solution for is to retrieve the latest rbutil version 13.36.07 # symlink on the download server to the newest one? 13.36.13 # so that we have a fixed url 13.36.27 # possibly a text file holding the version number too 13.36.39 Quit bertrik (Read error: 113 (No route to host)) 13.37.39 # yep, I want to retrieve the latest version number. My idea is to have a menu entry Help / Check for update which displays something "new version 1.0.10 available" 13.39.04 Join miepchen^schlaf [0] (n=miepel@p579ECC07.dip.t-dialin.net) 13.39.07 # ok, let me know how you'd like such a meta-data file to look like and I'll make it available 13.39.49 # ok, I'll think about it -- we should be able to have different versions for different OS 13.40.06 # yes, and make sure 32bit and 64bit linux can differ too 13.41.06 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 13.51.20 Join nplus [0] (n=nplus@243.131.Globcom.Net) 13.52.52 # Hmm. I need opinions... 13.53.20 # I want to unify the colour handling of the mono/greyscale target screendump and simulator ui 13.53.39 *** Saving seen data "./dancer.seen" 13.53.49 # But there's the special case called Clip. 13.54.22 # How important is the simulation of the gap between the two different coloured parts? 13.54.56 # Simulating the gap causes quite some extra work 13.54.56 # my guess would be not terribly important, but I've never used a clip so I can't tell for sure 13.58.11 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 13.58.15 Join gregzx [0] (n=chatzill@dst64.neoplus.adsl.tpnet.pl) 13.59.43 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 14.06.21 Join slyyf [0] (n=slyf@142.46.8.26) 14.14.34 # PaulJam: what's up? 14.14.59 # resizing produces weird colour on coldfire (H300) 14.15.03 Quit robin0800 (Remote closed the connection) 14.15.15 Join kugel [0] (n=kugel@e178088180.adsl.alicedsl.de) 14.15.39 # hrm... since the resize-uses-emac commit, probably? 14.15.56 # yes. one revision earlier shows up fine 14.17.18 Quit EspeonEefi ("さよなら") 14.17.23 # resize-use-emac? 14.17.27 # is it in pictureflow, or other places as well? PF does some funny things that core scaling doesn't 14.18.06 # kugel: it uses 32x32->64 C multiplies on ARM. coldfire lacks an instruction for that, but the emac can provide 32x32->40, which is enough. 14.18.08 Quit Horscht (Read error: 110 (Connection timed out)) 14.18.21 # what's "the emac"? 14.18.26 # Unhelpful: i first noticed it in sliding-puzzle, but it happens in the WPS too. i haven't tried pictureflow. 14.19.11 Join nibbler [0] (n=Nibbler@pD9E33F4D.dip.t-dialin.net) 14.21.35 Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) 14.21.55 # kugel: a multiply-accumulate unit that coldfire has. it can do 40-bit integer operations, and also has some support for specific operations to accelerate high-precision fixed-point math 14.22.20 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 14.23.21 # ah, thanks for the clarification 14.23.34 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 14.23.41 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.23.58 # should I expect something weird on greyscale coldfire too? 14.25.45 # the scaler is essentially fixed-divisor rational math until the output stage, it's calculating values that are N times the actual pixel value. it uses 8.32 fixed-point division to scale these back to the 0-255 range. 14.25.51 # pixelma: possibly. :/ 14.26.18 # PaulJam: is it any particular parts of images that have trouble? very bright or dark areas? 14.28.54 Quit slyyf (Read error: 110 (Connection timed out)) 14.33.20 # Unhelpful: i made some screendumps. on the left side is how it should look like: http://img300.imageshack.us/img300/7861/resizeny6.png 14.34.13 # but on most other covers the errors are less visible. 14.34.16 # excellent! are the color blocks in the bottom set full brightness? 14.35.24 # blue is missing, red and green are swapped? 14.35.40 Quit solexx_ ("leaving") 14.36.28 # hrm, but, in the yellow block, the bad pixels are bright red, only their green is missing 14.37.05 # sorry, I was wrong, I'll leave this to the experts 14.37.10 # Manual people, is there a list of the \opt{} options anywhere? 14.37.10 # i'm not sure what you mean with full brightness. i made the image in paint using only colours that have only 255 or 0 in the fields for RGB. 14.37.30 # this is all quite strange, the emac asm should be doing exactly what the 64-bit C version does 14.38.22 # PaulJam: that's exactly what i meant. are these images scaled up, or down? 14.39.12 # the cover.bmp is 150x150 and the WPS uses 75x75. 14.44.54 # hrm... so the downscaler will be adding up exactly four input pixels... and they're being mutiplied by 75*75, and then the final asm step divides by 22500. i really can't understand how neighboring output pixxels that should be the same color are not, unless my asm is bad, and there's junk being left in %acc0 14.46.02 # amiconn: I would tihnk that simulating the gap would make it much better... but if its too much of a PITA then probably not worth the effort.... 14.47.44 # Unhelpful: could this happen because of the dithering? 14.49.05 # Is the Gigabeat T believed to be a flash-drive version of the Gigabeat S? Or is it likely completely different hardware? 14.49.26 # shows what i know, first thing in the morning. didn't even think of that, but yes, the dithering could easily be responsible... 14.49.57 # soap: if it has the same restore process, i can think of a very quick, dirty way to find out... assuming we really mean *entirely* the same hardware. 14.53.36 # JdGordon: Atm the sim does that, but with quite some extra effort. 14.54.03 # My unification idea would become quite a bit simpler if it wouldn't have to simulate the gap 14.54.09 # rasher (or other lang people) - If I want to change a string (as it is wrong), can I just edit it? i.e. LANG_DISC_FULL has "e200*,c200: "The disk is full. Press UP to continue."" but for c200 it should be "Press LEFT" 14.54.11 # Also, do we want the gap in screenshots? 14.54.19 # or does that cause issues? 14.54.32 # rasher: the automated invalidate doesn't seem to work in my case 14.55.06 # amiconn: well.. If we can assume that its the only target that will ever have that gap then a few extra #ifdefs might not be so bad? 14.55.17 # and screenshots should obviously mimick the real display as much as possible 14.55.19 # BigBambi: meh, button translations are nasty imo 14.55.31 # I'm encoutering a similar problem right now 14.56.08 # It's not just a few extra ifdefs. The gap needs to be added in some way at output time, as the framebuffer doesn't contain it 14.56.20 # BigBambi: but, LEFT should be PREV, the other strings to PREV as well 14.57.17 # s/to/do/ 14.58.06 # Either the sdl surface needs to be blitted in two parts, or it needs to contain those extra lines, which moves the problem to the simulated lcd_update[_rect]() 14.58.46 # I'd say keep it in the sdl surface part 14.59.48 # My idea for unification is that screendumps and the sim will always use a 128 colour palette, regardless whether it's an 1-bit or 2-bit target, and whether the greylib is running or not 15.00.12 # It will lead to larger screendump files, but less ifdefing in the code 15.00.27 # The clip would then duplicate the palette 15.00.53 # is there a problem with the current code? I mean it seems to work fine and there are things which could do with work which are probably more important? 15.01.11 # There are several problems. 15.01.41 # ok :) 15.01.59 # Screendump colours don't match the display, lots of ifdefing in the sim, inverse display of the greylib (fixed for mr100, but still existing for the clip) 15.02.15 # oh is this for the on target screenshots also? 15.02.58 # of course 15.03.07 # Otherwise it wouldn't make sense 15.03.25 # oh ok... I thought only sims which is why I was asking if it was worth it 15.04.53 # Try a screendump on the clip... and btw, the screendump function is the same for target & sim, and is quite unrelated to the actual sim display 15.04.57 Join MethoS- [0] (n=lem@host-091-097-243-141.ewe-ip-backbone.de) 15.05.31 # (with the exception of the Player, which has no screendump on target) 15.05.49 # I dont have a clip, but ok 15.05.59 # Then use a clip sim.... 15.07.44 # * amiconn needs good macro names for the LCD colours 15.09.03 # The sim uses UI_LCD_BGCOLOR[LIGHT] and UI_LCD_FGCOLOR[LIGHT], where the ..LIGHT versions mean with backlight, and FG/BG mean pixel set/not set 15.09.16 # ah I see what you're talking about.... pretty useless on the clip :) 15.09.42 # PaulJam: i can band-aid the problem for now... do you have any feel for how fast scaling was on the h300 before that commit? 15.10.27 # But I want to change this, so that one colour is always dark, the other is always bright, with a separate macro indicating an inverse display 15.11.22 # But _DARK, _BRIGHT, _DARKLIGHT, and _BRIGHTLIGHT sound silly... 15.11.45 # Unhelpful: sorry, i have no idea how fast scaling was. 15.12.59 # Perhaps I should put an optional BL_ part in the middle 15.13.19 # yeah, something like that 15.13.25 # * JdGordon doesnt have any ideas on naming 15.14.00 Join Zoxc [0] (i=Zoxc@ti0128a340-dhcp0111.bb.online.no) 15.14.42 # no problem. i'll patch it up to use the same math as sh does, for now. that's more than accurate enough at reasonable sizes. i'll see about trying to fix it properly later, since there's no reason this *shouldn't* work on coldfire... 15.16.27 Quit EspeonEefi ("さよなら") 15.16.29 # by the way, i just tried pictureflow, and the zoom functionality in the settings doesn't seem to produce wrong colours. does that use a different method? 15.18.58 # there's an option to turn resizing on or off. the "zoom" just changes the distance between slides and camera 15.21.02 Quit MethoS (Read error: 113 (No route to host)) 15.23.26 # Unhelpful: Don't you need unsigned mode for scaling? 15.24.49 # isn't 0 unsigned/integer? 15.24.54 # no 15.24.59 # 0 is signed integer mode 15.25.03 # or do i have the "sense" of the sign bit backwards? 15.25.45 # And btw, you don't need to reset the mode - the next user will set it anyway 15.25.52 # s/reset/restore/ 15.26.17 # kugel: Sorry, phone. Sure, left or previous - previous might be getting a little large for the c200 screen, but either way, can I just change the string in english.lang, or will that then feck up translations etc.? 15.26.46 # even in the same thread? i thought it was generally supposed to be left "ready" for the DSP's use? 15.27.26 # BigBambi: IIUC, if you chane the source (and dest) string in english.lang, the other languages will be invalidated (since their source string doesn't match with the one in english.lang) 15.28.09 # BigBambi: PREV is as large as LEFT, isn't it? 15.28.17 # Well you never know what other part of the code might have set it. All emac code blobs I know set the mode initially 15.28.25 # kugel: Yes, sorry - PREV is what should be used 15.28.59 # A context switch saves the emac status, so you can yield() without worrying about a different mode set when the yield returns 15.29.09 # kugel: And sorry for being confused, but do I want to change both source and dest then? 15.29.23 # in english.lang you need to change both, yes 15.29.26 # hrm... ok. i'll ifdef around the emac version for now, and see about fixing it later. 15.29.59 # kugel: that's no problem - the user won't see it as long as you don't change the ID. It will still use the wrong string but it'll show as a difference to the "master" english.lang when a translater wants to update and s/he'll notice that there's something to fix 15.30.15 # Unhelpful: I'd rather try unsigned mode first. It's a quick fix 15.30.33 # kugel, pixelma OK, cheers. I'll change both in english.lang 15.30.34 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 15.30.39 # Unfortunately I don't see the effect on my h300 - it might depend on the scaling factor 15.31.00 # BigBambi: source and dest in english.lang - source will be evaluated by genlang for the translaters 15.31.42 # amiconn: i can't do that right now, but if you'd like to take a look at it, i can hold on committing the band-aid patch for now. 15.31.46 # pixelma: yep, cool 15.31.46 Join arohtar [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) 15.31.58 # pixelma: thanks for clarification 15.32.00 # pixelma: Did you see my manual question above? 15.32.03 Quit arohtar (Read error: 104 (Connection reset by peer)) 15.32.11 # i.e. is there an opt for flash? 15.32.12 # BigBambi: no 15.32.55 # as at the moment the recording section has \opt{swcodec}{\note{When you start a recording, the hard disk will spin up. etc. 15.33.08 # Test building... 15.33.09 # Which isn't true for non-hd swcodecs 15.33.53 # I couldn't spot a flash disk opt, but I figure I probably missed it :) 15.34.03 # There should be one 15.34.05 # aren't \opt{} automatically generated from features.txt= 15.34.22 # I believe there is - would have to look it up for myself. It's either a "manual" UseOption in the platform files or an automatic one from the parsed features.txt (to be found in a features.tex in a manual build folder) 15.34.23 # if yes, adding this to feature.txt should sufficient 15.34.50 # OK, I'll check features.tex 15.34.54 # flash_storage ? 15.34.55 # features.txt is also used for the language building, you can't just add something 15.35.09 # Or actually disk_storage in your case 15.35.35 # Do any of the archos disk targets record? 15.35.39 # that's why not everything is automated (e.g. the HAVE_BACKLIGHT option) 15.35.42 # the recorder perhaps? 15.35.47 # * BigBambi slaps self 15.35.48 # (i.e. you want a hypothetical flash+disk target to show this text) 15.35.59 # BigBambi: there's a reasonon they are called "Recorder"s ;) 15.36.08 # reason too 15.36.23 # pixelma: Do you know if there is a reason why theydon't get this note at the moment? 15.37.13 # Because they apply a special trick to not have to spin up the disk as long as possible 15.37.16 # this peakmeter thing? Maybe because the effect isn't as visible in the hwcodec recording system... just a guess though 15.38.02 # So I can just nest the two opts for swcodec and disk-storage? 15.38.29 # Is there a special syntax for that, or is it as simple as one after the other? 15.38.34 Join T0paz [0] (n=jonny@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) 15.38.42 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 15.39.12 # The peakmeters also don't stop on hwcodec when the disk spins up. All that happens is that they do less readings per second, in order to leave enough cpu time for the disk access 15.39.17 # yes, nesting should work 15.39.34 # OK, cheers 15.39.42 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 15.44.31 # amiconn: apparently scaling 150x150->75x75 will exposed the problem, with full brightness (255) in an color comonent: http://img300.imageshack.us/img300/7861/resizeny6.png 15.44.52 Nick romain_ is now known as romain (n=romain@peerfuse.org) 15.45.38 # but... neither factor should ever have the sign bit set, at that scale :/ 15.46.06 Join MethoS-- [0] (n=lem@host-091-096-215-228.ewe-ip-backbone.de) 15.49.43 Nick Barahir_ is now known as Barahir (n=jonathan@BAI0910.bai.pppool.de) 15.52.13 # BigBambi: you should be able to remove c200 from that string with tools/langtool, and then add a line for c200 manually 15.52.31 Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 15.53.00 Join MethoS [0] (n=lem@host-091-097-242-030.ewe-ip-backbone.de) 15.53.07 # rasher: Is that better than just manually removing c200 and adding it on its own line? 15.53.28 # BigBambi: Yes, because using langtool you can easily remove it in all langs that have it there 15.53.40 # rasher: Ah, OK 15.53.42 *** Saving seen data "./dancer.seen" 15.53.56 # kugel: shouldn't FS#9662 be closed now? 15.54.11 # I'm not sure it matters when you're adding a new one though, actually 15.54.12 # and then manually add it to english.lang only, and translators can add it to others whenever they next do 15.54.13 # Unhelpful: Looks like setting the emac to unsigned fixes the problem (tested on pixelma's M5) 15.54.14 # ? 15.54.15 # might not be worth it 15.54.22 # BigBambi: Indeed 15.54.28 # n1s: I wanted to do that right now, I just waited for the build table ;) 15.55.13 # Unhelpful: Shall I commit, or post a ptach for further testing? It's essentially a 2-line patch (one in resize.h, and one in system-target.h for coldfire) 15.56.06 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 15.59.32 # Why does e200 have * after it? i.e. e200* 15.59.33 Quit MethoS- (Read error: 110 (Connection timed out)) 15.59.52 # BigBambi: to catch e200v2 or e200r I presume 16.00.03 # That makes sense :) 16.00.12 # * BigBambi is being a bit slow today 16.02.31 Join {phoenix} [0] (n=dirk@p54B4588D.dip.t-dialin.net) 16.05.13 Quit faemir (Remote closed the connection) 16.05.25 Join faemir [0] (n=daniel@88-106-244-173.dynamic.dsl.as9105.com) 16.09.43 Quit Thundercloud (Remote closed the connection) 16.11.25 Quit Seed ("cu, Andre") 16.11.43 Quit MethoS-- (Read error: 110 (Connection timed out)) 16.11.49 Quit MethoS (Read error: 110 (Connection timed out)) 16.15.10 Quit robin0800 () 16.15.57 # rasher: Does "../../tools/langtool.pl --changetarget --from e200*,c200 --to e200* --id LANG_DISK_FULL --inplace *.lang" look correct to you? As it runs, and seems to go through all of the languages, but nothing actually changes in the lang files 16.16.56 # BigBambi: Looks correct... Odd. A bug in langtool.pl isn't out of the question - do other languages have that string in the first place? 16.17.06 # some do 16.17.16 # I'll have a look 16.17.17 Quit SirFunk (Read error: 60 (Operation timed out)) 16.17.20 # And I get a list of languages being printed to the terminal 16.17.48 # Thanks 16.17.50 # That's just printed when opening the file, so it's no guarantee that anything's being changed 16.17.51 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 16.17.56 # OK 16.20.41 Join MethoS [0] (n=lem@host-091-096-212-068.ewe-ip-backbone.de) 16.21.18 Join SirFunk [0] (n=Sir@208.15.25.145) 16.21.51 Quit T0paz (Read error: 113 (No route to host)) 16.26.42 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 16.32.07 # BigBambi: just committed a fix 16.32.47 Join fyrestorm [0] (n=fyre@cpe-68-173-234-24.nyc.res.rr.com) 16.34.23 # rasher: ta very much 16.34.25 # * rasher sees that kugel would've hit the same bug 16.34.40 # But evidently he went through more trouble to do the same thing 16.34.41 # I did it all manually :S 16.34.54 Join SirFunk_ [0] (n=Sir@208.15.25.145) 16.35.25 # kugel: don't worry, langtool.pl wouldn't have worked for you anyway (until now) 16.36.34 # rasher: I wasn't sure if it worked for my problem anyway, I didn't change strings, only which strings apply for the e200* 16.36.51 # Unhelpful: could it be that your commit in r19847 causes errors when compiling the uisim (h300) in cygwin? i get this: http://pastebin.com/m465e7800 . (the warnings were there before, but the errors at the end are new.) 16.37.01 # amiconn: if you were able to reproduce, and fix, the problem, i don't see any reason not to commit it ;) 16.37.16 # kugel: langtool can change targets - look up for BigBambi's commandline 16.37.30 # hrm... that's... odd. 16.38.23 # rasher: ah cool, I'll give it a shot the next time :) 16.38.46 # rasher: works nicely now, thanks 16.39.11 # kugel: At least you actually *did* it the manual way. Most devs are too lazy for that (understandable, really), and just let the translators bother with it 16.39.26 # Which is why I created the script 16.39.38 # well, I actually thought about doing that too :p 16.40.00 # but this was a no-brainer, and it's sunday and I have time, so I did it :P 16.40.04 # Can't say I blame you 16.41.19 Quit SirFunk (Read error: 145 (Connection timed out)) 16.41.31 # also, I noticed that it would show *wrong* translations, which would directly be *wrong instructions* on the screen in this case, instead of showing no translation 16.44.25 # PaulJam: maybe do a make reconf and make dep? i was able to build h300 sim... 16.44.28 Quit SirFunk_ (Remote closed the connection) 16.45.29 # Unhelpful: i did 'make veryclean' and '../tools/configure' before. 16.46.23 # do you use cygwin? 16.49.10 # no, i don't :/ 16.50.59 # i'm not really sure why that would even be happening, gcc-support.c includes plugin.h, which declares rb as extern... not to mention, there are piles of other pluginlib files that reference rb in the same fashion without problems :/ 16.52.08 # amiconn: if you have time, could you check if the h300 uisim builds for you (in cygwin)? maybe it's just a local problem on my end. 16.53.15 Quit nibbler (Read error: 110 (Connection timed out)) 16.56.20 # * BigBambi points people at FS#9825 and FS#9826 16.57.15 Join MethoS- [0] (n=lem@host-091-097-246-096.ewe-ip-backbone.de) 16.58.31 # pixelma: if we had one button context that offers vertical or horizontal scrolling, a select button, and a cancel or exit button, yes, i think that pictureflow could definitely get by without combining, then. 16.58.38 Quit nplus (Remote closed the connection) 17.00.20 # without combining is a must IMO, otherwise you lose control about what will happen on targets which have different actions in the combined actions on the same button (action) 17.00.35 # combined contexts, I mean 17.03.10 # it's a little tricky for things like the scrollwheel targets, which tend to use the wheel for scrolling in either direction... and confusingly, i think, for movement on one axis, while using buttons for the other 17.03.35 Join PaulJam_ [0] (i=PaulJam_@134.76.3.77) 17.06.19 Quit PaulJam (Read error: 60 (Operation timed out)) 17.09.24 Join t0mas [0] (n=tomas@rockbox/developer/t0mas) 17.11.59 Join at0m [0] (n=a548c80b@gateway/web/cgi-irc/labb.contactor.se/x-61da71d8686bc644) 17.13.21 Quit MethoS (Read error: 110 (Connection timed out)) 17.14.41 # Unhelpful, PaulJam_: I get the same error. Looks like the problem is that battery_bench.c is #ifndef SIMULATOR 17.15.16 # But it isn't excluded from SOURCES, only within the plugin itself, and the #ifndef SIMULATOR block includes PLUGIN_HEADER 17.15.16 Quit at0m (Client Quit) 17.15.52 # can anyone tell me why CONTEXT_LIST and CONTEXT_TREE are seperate? 17.15.59 # that's bizarre 17.16.32 # kugel: The tree is not simply a list, there are a few extra functions 17.16.48 # (like going directly to wps, stopping playback) 17.17.33 # amiconn: which? and why should the list not have these functions? 17.18.14 # well, I can stop playback and go to wps from both list and tree on my e200 17.18.27 # except for the id3 viewer, which drives me crazy 17.18.55 # You just need to leave the tag viewer... 17.19.18 # but I cannot do that with the button that I use everywhere in rockbox to go to the wps 17.19.29 # that one does nothing in the id3 viewer 17.20.16 # amiconn: so, battery_bench should probably be ifndef SIMULATOR in SOURCES, shouldn't it? 17.20.17 # Everywhere? Certainly not.... 17.21.58 Join nibbler [0] (n=Nibbler@pD9E32F98.dip.t-dialin.net) 17.22.40 # from filebrowser, database browser, main menu, playlist viewer, pitchscreen, settings 17.22.47 # ok, not everywhere, but almost 17.24.40 # Unhelpful: There are more than just that one... 17.24.57 # amiconn: i'll start looking, then :) 17.25.15 # Found firmware_flash and rockbox_flash so far 17.25.37 # I wonder why cygwin ld wants to link memcmp against an essentially empty object though.... 17.25.54 # wait, are you fixing these already? 17.26.07 # does anything speak against adding ACTION_TREE_WPS to CONTEXT_LIST? 17.26.32 # so that the id3 viewer is leaveable with the usual go-to-wps button? 17.27.11 # * Unhelpful notices that much of firmware_flash.c is also ifdef PLATFORM_ID 17.28.46 Join phinze [0] (n=phinze@173-19-89-233.client.mchsi.com) 17.29.18 # Plain lists shouldn't have that 17.29.42 # video.c also 17.31.48 Join T0paz [0] (n=jonny@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) 17.32.08 # amiconn: why? what's the definition of plain lists? 17.32.25 # from the user pov, everything is a plain list anyway 17.33.09 # If you add that to plain lists, everything using plain lists would need to deal with the extra event. Plugins, anything 17.34.05 # ok 17.34.28 # the other posibility is to use CONTEXT_TREE for the id3 viewer 17.34.58 # * amiconn doesn't see everything as just a list, as the behaviour is quite different in menus, browser, settings 17.35.01 Quit robin0800 (Remote closed the connection) 17.35.03 # even though, I tested that, and stop didn't do stop in the id3 viewer 17.35.12 # And it has to be like this, as their purpose is different 17.35.56 Quit CaptainKewl (Read error: 60 (Operation timed out)) 17.35.59 # but at least play exited it 17.38.19 # amiconn: anything against that? 17.38.57 # well, it doesn't sound entirely correct, but it does what I want it to do 17.39.04 # Unhelpful: Hmm, iiuc the clever multiplication-saving trick doesn't work for RGB888? Or at least not using one 32-bit int 17.39.28 # kugel: You can't just change the context, you also need to actually handle the additional events 17.40.02 # there's no additional events, except TREE_WPS an d TREE_STOP 17.40.11 # amiconn: multiplication-saving? you mean the one to do undither output with values scaled directly to 0..31/0..63? 17.41.00 # also, does this look right? i cleaned up some other unneeded ifdefs in source for things that are already handled in SOURCES, as well. http://unhelpful.pastebin.com/d313a6f25 17.41.01 Quit {phoenix} (Read error: 104 (Connection reset by peer)) 17.42.19 # if you mean the trick that pictureflow uses, then it should work *for pictureflow*, where we can (pretty much) assume that max(in_w,out_w) * max(in_h,out_h) > 63 17.42.20 # Unhelpful: I mean the one that scales an RGB value without (full) unpacking 17.42.52 # amiconn: oh! that... yes, and know. 17.42.54 # I am thinking about using such a trick for calculating the bmp palette for screenshots 17.43.04 # s/know/no/ 17.43.30 # * gevaerts tries to make sense of testing the latest patch in FS#8663 17.43.56 # Iiuc it should be possible if I just unpack into G and 0R0B 17.44.13 # you can do that, and save one multiplication, yes 17.45.07 # byte-order etc might make it hard to determine which bytes you want, if you're talking about RGB888 and not RGBX8888 17.45.46 # XRGB8888 17.45.57 # What BMP uses in its palette 17.46.54 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 17.48.18 # well, assuming we don't really care what ends up in the X byte, you can use two multiplies, after splitting a 32-bit color value c into c1=(c >> 8) & 0xff00ff and c2=c & 0xff00ff 17.48.40 # X must be 0 17.48.40 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-bf31ed3732345037) 17.49.01 # well, if it's already 0, you should be ok 17.49.52 # And I can store the input values already split, so I just have to multiply, mask and combine 17.49.55 # it's best if your scale factor is in range 0..(n^2), rather than 0..((n^2)-1), because then you can shift to divide. doing anything else while maintaining precision will get complicated. 17.49.56 Quit nibbler (Read error: 110 (Connection timed out)) 17.50.18 Join slyyf [0] (n=slyf@142.46.8.26) 17.51.04 # SWAR is not real SIMD, so even things that temporarily need >unit precision get ugly 17.51.32 # Input values are decided compile time. I think it's better to calculate the palette at runtime instead of wasting 512 bytes of constant data 17.52.04 # Does anybody have a copy of the tcc78xx datasheet lying around your harddrive from back when it was available? 17.52.10 # Of ocurse only if this calculation (+ required input values) is smaller than 512 bytes... 17.53.30 # On the clip it would ben 1024 bytes 17.53.46 *** Saving seen data "./dancer.seen" 17.56.07 # amiconn: this is for sim, right? 18.00.49 # amiconn, PaulJam: can one of you try this on cygwin? it builds for me on linux, but i don't have a cygwin environment: http://unhelpful.pastebin.com/d3dafce04 18.01.44 Quit Xerion (" ") 18.07.10 Quit T0paz (Read error: 113 (No route to host)) 18.09.55 Quit axionix (Remote closed the connection) 18.11.09 # it's a shame MMX lacks an 8x8->16 version of pmulhw/pmullw 18.11.52 # gah, pastebin sripped the @@ at start of the lines 18.12.14 # PaulJam: copy from the edit box... it's the only way :/ 18.12.22 # r = (r * rvalue) >> 5; g = (g * gvalue) >> 6; b = (b * bvalue) >> 5; 18.12.38 # can you combine the multiplies with a SWAR here? :) 18.12.38 # i did. there they are missing too. 18.12.40 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 18.13.15 # PaulJam: holy cow... that's insane. i'd think it would preserve them *there*, so that you still have the same highlights if you edit it... :/ 18.13.18 Join {phoenix} [0] (n=dirk@p54B4588D.dip.t-dialin.net) 18.13.45 # Zoxc: if rvalue==bvalue==gvalue 18.14.21 # SWAR is not true SIMD. if you have true SIMD with separate fields, things like that are possible. 18.15.26 # better get some AVR32 DAP :D 18.17.54 # true SIMD would be troublesome for this case, also, though... in my experience, available field sizes are 8, 16, 32 or 64 bits 18.18.07 Join toffe82 [0] (n=chatzill@adsl-71-154-234-29.dsl.frs2ca.sbcglobal.net) 18.18.45 # You would use RGB888 with an OLED screen in the ideal AVR32 world :) 18.20.46 # and mixing SIMD with non-SIMD operations on the same data *murders* your efficiency 18.22.17 Join Darksair [0] (n=user@221.221.156.123) 18.25.40 # Any idea how I could tell if an LCD is TFT or not? 18.30.50 Join BigBambi_ [0] (n=quassel@168.189.72-86.rev.gaoland.net) 18.30.52 Join Aristad [0] (n=Aristad@p579DE0E9.dip.t-dialin.net) 18.33.35 Quit BigBambi ("Please insert girder") 18.45.45 # does it look better or worse in the sun? 18.46.17 Quit faemir ("Lost terminal") 18.49.48 Join gartral1 [0] (n=Gartral@adsl-75-33-69-121.dsl.bcvloh.sbcglobal.net) 18.49.59 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 18.52.55 Join TheSphinX^ [0] (n=cold@p54A5C16A.dip.t-dialin.net) 18.53.56 # Unhelpful: the uisim compiles with the patch. 18.54.15 Quit TheSphinX^ (Remote closed the connection) 18.54.34 Join TheSphinX^ [0] (n=cold@p54A5C16A.dip.t-dialin.net) 18.56.12 # ok, this problem with the 000090D0 (0) abort is not just my player, my moms player has starting to have the same issue, with both the "modified" and "stock" builds, please, will someone help me with this? 18.57.03 Join MethoS-- [0] (n=lem@host-091-097-241-203.ewe-ip-backbone.de) 18.59.36 # gartral1: you'll really need to tell which player this is.. 19.01.57 # sorry, there e200s, 19.07.25 Quit phinze (Read error: 110 (Connection timed out)) 19.08.30 # the symptoms are: if you play anything, the buffers all fill under 30 seconds, then it aborts at address 000090D0 (0), this is with OGG, MP3, WAV, WavePack, and ACC, i haven't tested anything else, though its most likely to reproduce it, and it seems to be related to who last edited the trunk., though this is only speculation 19.09.48 # Unhelpful: Both target and sim 19.10.34 # no, cant reproduce in sim 19.10.59 # but the fact that both players are doing it, at the same address is what gets me 19.11.03 Quit MethoS- (Read error: 110 (Connection timed out)) 19.11.20 # gartral1: have you filed a bug report? 19.12.00 # * gevaerts would try to reproduce this, but his e200 is currently busy trying to reproduce another issue 19.13.08 # PaulJam_: Does r19853 fix the wrong colours on scaled bitmaps for you? 19.13.33 # yes, thanks for fixing. 19.13.42 # not yet, ive asked here before, but i can't get enough info to file a bug report, ide really like to know what goes into that address, but my system wont produce a readable map file, and less cuts it short over tty 19.14.04 # 000090D0 isn't in the map file 19.14.18 # goodie 19.14.37 # ok, then whats going on here? 19.15.19 # invalid pointer? 19.15.50 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 19.15.58 Part LinusN 19.16.03 # hm, I seem to misremember things... 19.17.23 # 000090D0 is somewhere in buffering.c if I read things right 19.18.31 # PaulJam_: thanks, i'll commit it, then. 19.19.19 # gartral1, this happens with latest svn? i can try on my e200 19.19.48 # hmm, ive been having this issue since just before the new year... my moms player hasnt been updated since about november of last year, and i just brough both up too 19852 19.20.04 # so "yes"? 19.20.15 # gartral1: is the address always the same? 19.20.35 # yes, across all codecs, both DAPs 19.21.04 # Also across revisions and builds? 19.21.09 # and sometimes it does, sometimes it dont 19.21.14 # no 19.21.21 # only specific builds do it 19.22.09 # last one was 19844, before that, 19832 19.22.10 # What's the full message? Data abort? 19.22.44 # * gevaerts would like to have a rockbox.elf and matching exact message 19.22.46 # Data Abort at 000090D0 (0) 19.23.02 # how do i produce that? 19.23.21 # ohh, wait, its right in the build dir, one moment 19.23.34 Quit mcuelenaere () 19.25.01 Quit kugel (Read error: 60 (Operation timed out)) 19.25.30 # that file is huge >.> it's on JD's system, unless i can have him FTP it, were gonna have to wait 19.25.59 # gartral1: how big is it? 19.26.17 # * gartral1 needs too remember scp is in BYTES not KB! 19.26.23 # :) 19.26.35 # There's also a rockbox.map next to it. Maybe get that as well 19.27.01 # * krazykit cannot reproduce that behavior in r19853, but will check 19844 19.27.09 # im looking at "1,045,063" but it dosent designate byte/kb 19.27.15 Join kugel [0] (n=kugel@e178088180.adsl.alicedsl.de) 19.27.31 # well, 19852 does it, as well 19.28.19 # well, i'm playing both mp3 and vorbis just fine 19.28.33 # gartral1: do you use the eq? 19.28.47 # yes i do, and dithering 19.29.20 Quit kugel (Read error: 60 (Operation timed out)) 19.29.23 # * gevaerts waits for the files before he asks further questions 19.29.49 # gartral1: maybe open a bug report and attach those files, together with the exact address you get with that same build 19.30.34 # wait, i was only aware i needed rockbox.elf... what other file do you need? 19.30.53 # yes. If possible the rockbox.map that's in the same directory 19.31.20 # its alot smaller than the ELF, np 19.31.30 Join kugel [0] (n=kugel@78.52.70.178) 19.32.09 # gevaerts, speaking of SD - what is your take on the latest comments to FS#8663? 19.32.26 # soap: testing that as we speak 19.33.15 # I mean in theory. What he did is out of my depth. I was just curious on why that would have an effect. 19.33.41 Join Barahir_ [0] (n=jonathan@X86b0.x.pppool.de) 19.34.25 Join nibbler [0] (n=Nibbler@pD9E31188.dip.t-dialin.net) 19.34.42 # soap: this UNKNOWN register is unknown, so it could well have undiscovered results :) 19.38.53 # ok, where waiting on my slow upstream to give the files too FS 19.39.19 # http://www.rockbox.org/tracker/task/9827 19.39.41 Quit Darksair ("Use the Force, Luke!") 19.40.40 # please excuse my poor garmmar 19.40.49 # that's a curious yellow on clip sim... looks like fnarfbargle might be responsible? 19.44.36 Quit Barahir (Read error: 110 (Connection timed out)) 19.47.11 # gevaerts: please ping me if/when you find anything 19.47.46 # gartral1: I think it's definitely in buffering.c, but I'll have to leave it to people who are actually at home in there 19.49.26 # well, whats a quick fix? last time, i cleaned the database and it fixed the issue till i updated today, i tryed the database clear again, and nada 19.49.35 Nick Barahir_ is now known as Barahir (n=jonathan@X86b0.x.pppool.de) 19.50.24 # can someone test a quickscreen patch? 19.53.45 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 19.53.50 *** Saving seen data "./dancer.seen" 19.54.23 # kugel: where is, whats it do? 19.55.13 Join MethoS- [0] (n=lem@host-091-097-245-248.ewe-ip-backbone.de) 19.55.44 # gartral1: http://www.rockbox.org/tracker/task/9828 19.58.26 Join faemir [0] (n=daniel@88-106-244-173.dynamic.dsl.as9105.com) 20.00.34 Quit nibbler ("Ex-Chat") 20.01.20 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 20.03.07 Quit rocko ("Leaving") 20.03.17 Quit BigBambi_ (Remote closed the connection) 20.04.57 Join tex [0] (n=4cfae06c@gateway/web/cgi-irc/labb.contactor.se/x-1dc5432ed6cd4d45) 20.05.25 # patch says that the files to be patched dont exist... 20.07.15 # gartral1: I don't think so 20.07.38 # gartral1: you're probably doing it wrong then 20.07.54 # hello room. I'm having trouble with version 3.1 on an 80GB 5.5 and couldn't find any bug reports on the web 20.08.08 Join akur [0] (n=akur@bl5-224-196.dsl.telepac.pt) 20.08.12 Part akur 20.09.30 # I upgraded from an older version, put a new ipodwidgets theme on it 20.09.58 # tex: just saying, it would be helpful if you told what your problem is 20.10.06 # and now it starts to play and then pauses for a second or two after playing only a couple seconds 20.10.18 # sorry, was looking up the theme name 20.11.02 Quit wpyh (Read error: 110 (Connection timed out)) 20.12.44 # t/win 4 20.13.24 # I saw one reference to "resume playback on startup" and ChanServ playback resume on hard drive scan bug 9719 20.13.30 # slyyf: hey! how's your progress? 20.13.52 # do you think I should reset my cfg to defaults and see if that helps? 20.13.58 Join BigBambi [0] (n=Alex@168.189.72-86.rev.gaoland.net) 20.13.58 # kugel: its goin...soso 20.14.10 # kugel: I have it displaying stuff on the screen better 20.14.15 # however 20.14.26 # stuff is shifted, so one of my values is wrong 20.14.34 # shifted? 20.14.38 # how much? 20.14.42 # 1/2 20.14.48 # maybe less 20.15.12 # I think I am just not sending a correct value for the bpp or something 20.15.37 # Bitwise whats &~? 20.15.45 Quit TheSphinX^ ("XChat@Linux") 20.15.50 # tex: that's always worth trying 20.16.04 # but, then if I pause playback for a few seconds and resume, it won't continue to skip every two seconds 20.16.12 Quit MethoS-- (Read error: 113 (No route to host)) 20.16.13 Join dockimble [0] (n=dockimbl@77.227.1.24) 20.16.15 # k, I'll give it a whirl and see what happens 20.16.28 # kugel: also apparently the power management is different too, because it always comes up that the battery is dead, no matter what Mv value I set for Critical 20.16.30 # slyyf: & ~ is bit clear 20.16.39 Join __lifeless [0] (n=lifeless@94.50.176.204) 20.16.51 # mcuelenaere: thanks 20.17.03 Quit dockimble (Client Quit) 20.18.46 Join dockimble [0] (n=dockimbl@77.227.1.24) 20.19.03 # slyyf: I looked very shortly into the driver 20.19.13 Quit mcuelenaere () 20.19.13 Quit miepchen^schlaf () 20.19.22 # there's 1 which I'm curious about 20.19.26 # 1 number 20.19.47 # hm? 20.19.49 # 0x103 (which is 259) 20.20.10 Quit HBK (Read error: 54 (Connection reset by peer)) 20.20.23 # What line specificically did you see that on? 20.20.49 # kugel: 20.20.51 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 20.20.54 # what I know from the fuze lcd driver, there's a xoffset, which is by default 20, and in one command you write LCD_WIDTH + xoffset 20.21.20 # Ohhh...Maybe..where is that though? 20.21.23 # line 190 20.21.54 # of lcd-cowond2.d? 20.21.54 Quit tex ("CGI:IRC (EOF)") 20.22.06 # you may try changing that line to LCD_HEIGHT-1 + 30 (or LCD_WIDTH-1 - 50) 20.22.14 # slyyf: yes 20.22.50 # you can also take a look into the lcd driver of the fuze, there's some general similarities it seems 20.22.55 # lemme grab the svn copy... 20.25.19 # what makes you think 259 has any baring on it? 20.28.27 # darn, nope, didnt change anything 20.28.39 # slyyf: well, you were talking of things being shifted. I know that behaivor from the fuze, when you didn't apply the xoffset 20.29.06 # ah but, how do you know which of those lines is the xoffset? 20.31.27 Quit _lifeless (Read error: 110 (Connection timed out)) 20.32.06 Quit BigBambi (Read error: 113 (No route to host)) 20.33.50 # ohh, I see, lemme take a closer look at what the fuse is doing there 20.37.23 Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) 20.39.11 # slyyf: btw, maybe this will be useful: The e200v2 and fuze driver are quite similar, but the e200v2 one doesn't always put the lcd dimensions with LCD_WIDHT/_HEIGHT, but with immediate numbers (like the d2 one) 20.41.52 # also, the e200v2 doesn't have this xoffset, while the fuze one does (and the e200v2 display is basically just rotated vs the fuze's display 20.41.54 # ) 20.42.35 # whats "caption backlight" do? its not documented... 20.43.13 # http://download.rockbox.org/manual/rockbox-h100/rockbox-buildch8.html#x11-1300008.4 20.43.21 Quit rocko ("Leaving") 20.43.26 # looks documented to me 20.43.28 Quit MethoS- (Remote closed the connection) 20.49.39 Join miepchen^schlaf [0] (n=miepel@p579ECC07.dip.t-dialin.net) 20.56.15 Join BigBambi [0] (n=Alex@168.189.72-86.rev.gaoland.net) 20.59.56 Quit dockimble ("Ex-Chat") 21.05.37 Join T0paz [0] (n=jonny@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) 21.10.38 Quit Aurix_Lexico (Remote closed the connection) 21.10.59 # amiconn: Yeah, I'd need the __div0 stub but not an entry in the API structures. In system-arm.c an swi_handler which some formal method of using it should be defined if it proves useful for anything else later. 21.11.50 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 21.19.36 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 21.21.22 # lol, can we disallow sid user to file bug reports? :) 21.21.31 # (debian sid, that is) 21.23.03 # Why would that be? 21.23.49 # kugel: why shouldn't I be able to file bug reports? :) 21.24.01 # * rasher would dislike that as well 21.24.36 # 1) I was kidding 2) see latest comments at http://www.rockbox.org/tracker/task/9236 21.25.23 # At that rate, we'd have banned Windows users years ago 21.26.32 # * bluebrother doesn't understand what's so special about the comments in that task 21.27.15 # bluebrother: the one has reported USB problems, however the last comment is "The USB failure I'm experiencing would be connecting to a box running Debian Sid with a 2.6.26 kernel." 21.27.40 # kugel: so? You should be glad to get details 21.27.51 # I am :) 21.28.15 # surely you'd ban gentoo users first? 21.28.39 # seems like some people took this joke too serious :/ 21.29.12 # Guys 21.29.13 # qn 21.29.31 # Ok, so the normal P2 firmware displays everything upright... 21.29.38 # like, tall rather then wide 21.29.41 # anybody know if the apple line-out dock works w/ rockbox? 21.29.42 # kugel: I think you misunderstood what he's saying. He isn't saying (afaict) "This is just Debian's fault" - he's saying "These are the details of how the error happens" 21.29.42 # slyyf: Please use whole, real words. I have no idea what "qn" means. 21.29.45 # kugel: well, at least he gives details which is a *great* thing. The wording might be a bit weird, but well ... plus, stating the OS he's trying to connect to might give a hint about an OS issue (if there was some known. As that is not the case this is still a Rockbox issue unfortunately) 21.30.24 # rphillips: There's a page on the wiki showing known iPod accessories and how they work or don't. I don't know the exact page though, you'll have to search. 21.30.33 Join Tim3128 [0] (n=timmy@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) 21.30.54 # rasher: I read that as "the usb problems could be connected (related) to my debian sid system" 21.31.00 # Ok, guys I have a question, The normal P2 firmware displays everything vertical rather then horizontal (Unless your playing movies)...however the Rockbox is displaying Hozizontally..could that be the source of my problem, possibly? (seems to be shifted off screen almost) 21.31.32 # if so, how can I make rockbox display vertically 21.32.16 Join tvelocity[a] [0] (n=tony@194.219.255.107) 21.32.50 Quit tvelocity[a] (Client Quit) 21.33.04 # bluebrother: sure, I agree 21.34.20 # slyyf: well, rockbox should use the same display as the OF, right? 21.35.10 # kugel: No, apparently, Samsung must have rotated all of there images 90deg..but that makes no sence because they must render text at some point... 21.35.13 # slyyf: what did you define exactly? LCD_HEIGHT should be the bigger resolution I suppose 21.35.31 # I do that and it wont compile 21.35.32 # kugel: Rockbox, generally, will expect the LCD to not have been rotated. 21.35.46 # Sometimes the LCD is physically rotated. Basically, the OF displays at 90 degrees from the LCD's actual orientation. 21.35.57 # ya, exactly 21.36.17 # I am trying to identify the source of this darned issue and I cant come up with anything 21.36.18 # "it wont compile"? how that? 21.36.32 # Something about rockbox logo not being defined 21.36.34 Quit faemir ("Lost terminal") 21.37.03 # It must try to get a logo that fits the resolution 21.37.13 # yes, that's right 21.37.23 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 21.37.44 Quit tvelocity (Read error: 60 (Operation timed out)) 21.37.45 Join faemir [0] (n=daniel@88-106-244-173.dynamic.dsl.as9105.com) 21.37.49 # T0paz: have you read the logs? 21.38.10 # kugel: out of curiosity, which targets had you tested pictureflow on? all of mine are portrait... 21.38.16 # slyyf: for the logo see: apps\bitmaps\native\SOURCES 21.38.24 Quit Xerion (Read error: 110 (Connection timed out)) 21.38.50 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 21.38.52 # Unhelpful: I haven't tested it recently 21.39.10 # but sometime ago, it ran on my fuze and e200 (fuze: landscape, e200: portrait) 21.39.20 # either way, setting the height larger then the widthmakes it fail 21.39.24 # mcuelenaere, aha, hi 21.39.29 # i got the link to the BSP 21.39.33 # thanks 21.39.37 # ok good 21.39.42 # i've been having fun messing about 21.39.43 # and to get the rotated display correct, you probably have to change the lcd-driver and swap x and y. ( ithe lcd hardware doesnt have a rotate 90° option) 21.39.45 Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) 21.39.51 # well, the other thing I said was that I won't be available the next days due to exams 21.39.56 # slyyf: well, for now, you can probably just take a existing logo, renamed to fit your resolution 21.40.06 # ah, hope they go well 21.40.52 # i've been having fun messing about 21.41.02 # the BSP you mean? 21.41.08 # found the code which updates the volume control register (DACVOLUME) 21.41.18 # yeah, I read something like that 21.41.20 # in the firmware, using the BSP header files as a guide 21.41.23 # so you got code working? 21.41.37 # well, i modified the firmware to stop the fade-out in one channel ;) 21.41.39 Join pinkey [0] (n=chris@adsl-065-005-223-219.sip.chs.bellsouth.net) 21.41.44 # slightly pointless, but demonstrates it working 21.41.52 # :) 21.42.00 # i've been function-hunting in the assembly 21.42.08 # found a few of the basics, memcpy, memset, abs 21.42.18 # ah, about that 21.42.25 # the kernel Creative uses is Nucleus 21.42.30 # ah yes, i read that 21.42.31 # there's some source code on the internet, google 21.42.36 # i was pondering blagging the evaluation version 21.42.37 # aha 21.42.47 # and I've documented the init function a bit 21.42.47 # header files containing structures would be extremely useful 21.42.50 # ooh 21.42.56 # well documented, I've talked about it with somebody 21.43.09 # but unfortunately it's in dutch, so I'll have to redo that :) 21.43.13 # heh ;) 21.43.13 # kugel: ok... some of the changes we've talked about with regard to picking a size for images have worked out not-great for c200, apparently... it's a bit *wider* than some other landscape targets, though... 21.43.17 # the problem is that's it been a while.. 21.43.39 # a few other things confuse me 21.43.58 # the code makes occasional BLs to addresses in 0x3fffxxxx 21.44.06 # which is below where the main binary sits 21.44.46 # hmm perhaps there's a memory relocation switch? 21.44.57 # have you seen anything like that in the BSP headers, 21.44.58 # ?* 21.45.16 # well, a few things i did discover 21.45.28 # you were looking for IO accesses in 0xF0060000 (the LCD registers) 21.45.43 # there are no accesses anywhere to anything in 0xFxxxxxxx 21.45.48 # but plenty to 0x8xxxxxxx 21.46.07 # Hi, in the FAQ list of available supported hardware, it appears "none" are currently in production. Is the FAQ out of date, or is true there no real option for me becoming a rockbox user if I'm just now entering the market? 21.46.14 # and according to the BSP headers, 0xf... is for virtual mode, 0x8... for real mode 21.46.44 # so i found various things like i2c init functions 21.46.57 # pinkey: there is still ebay... 21.47.01 # pinkey: there are some in progress ports with hardware currently in production 21.47.09 # virtual/real mode? you mean physical and virtual adresses? 21.47.15 # ah yes, that 21.47.17 Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 21.47.18 # the sansa fuze/clip/e200 series 21.47.27 # pinkey: one option is to buy used/refreshed players 21.47.29 # this is my first foray into ARM assembly 21.47.39 # * mcuelenaere can't seem to find that chat he was talking about 21.47.49 # Unhelpful: how do you mean that? 21.48.04 # ah in that case have you seen the ARM register instruction sheet? 21.48.04 # thanks. 21.48.08 # it's quite handy at times 21.48.24 # i've got the intro lecture from the 'ARM university program' 21.48.24 # (and if you're using IDA, it has a function to explain instructions) 21.48.28 # which is actually really good 21.48.39 # (summarises the entirety of ARM assembly pretty well in 46 slides) 21.49.06 # http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf 21.49.22 # i'll take a look 21.49.30 # regarding memory relocation, do you mean something using the MMU? 21.49.38 # yes, probably 21.49.52 # ah no, that's what I meant with the virtual/physical addresses 21.50.00 # ah 21.50.24 # i guess there's a possibility that it turns on the MMU and maps stuff info 0x3f... 21.50.25 # about memory relocation, I know at some SoC's there's a switch where some part of the physical addresses can get different virtual addresses 21.50.34 # without using the MMU AFAIK 21.50.39 # kugel: pixelma had some issues with how it looks on c200 these days... and i'm inclined to agree 21.50.55 # hmm 21.51.07 # Unhelpful: well, remeber that I just proposed LCD_HEIGHT/2 21.51.09 # what purpose would that serve? making the addresses nearer? 21.51.12 # you changed it further ;) 21.51.39 # kugel: not really, that's what we were still using. and 40x40 is *darn* tiny on c200 21.51.54 # I think LCD_HEIGHT/2 looks just about perfect (at least on my targets) 21.52.21 # mcuelenaere, btw, do you know where the entry point is? it would seem not to be 0x40000000 21.52.35 # Unhelpful: haven your made it bigger? like LCD_HEIGHT-REFLECTION_HEIGHT 21.52.40 # nope, that's SoC/architecture specific 21.52.45 # although, on ARM it should be on 0x0 21.52.52 # that's the reset vector 21.53.04 # kugel: that's didn't change anything for square covers, only tall ones 21.53.07 # ah ok, so the bootstrap code at the start must be responsible 21.53.30 # well, the code at 0x0 is almost always a branch to some other place 21.53.36 # as there's not much space in that spot 21.53.38 # mcuelenaere: 0x30000000 works good on ams sansas, and watchdog resets properly 21.53.51 *** Saving seen data "./dancer.seen" 21.53.56 # kugel: you mean 0x30000000 is the reset vector on AMS? 21.54.09 # it loads the pc from further down and hops off to 0xdbd4 21.54.32 Quit yhuang ("Leaving") 21.54.33 # is this all separate from the rescue mode? 21.54.43 # mcuelenaere: not sure, but the datasheet specifies to map SDRAM to 0x30000000 21.54.46 Join mcuelenaere_ [0] (n=mcuelena@rockbox/developer/mcuelenaere) 21.54.53 # mcuelenaere: not sure, but the datasheet specifies to map SDRAM to 0x30000000 21.55.06 # oh, I thought you disced 21.55.10 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 21.55.14 # T0paz: yes, this is all separate from the rescue mode 21.55.28 # cool, so there's another bootloader above this? 21.55.48 # kugel: but what's the initial memory address the CPU looks at when it starts? 21.56.06 # the rom bootloader loads 0x0 21.56.10 # T0paz: yes, the booting chain (on the ZVM) is like this: FBOOT -> FRESCUE/main FW 21.56.20 # ah 21.56.21 # with FBOOT in NOR and FRESCUE/main FW on HDD 21.56.27 # and I suspect this is similar on the Zen 21.56.29 # that's where our bootloader is (that's iram) 21.56.33 # I know it has FBOOT somewhere 21.56.43 Join MunkieMan [0] (n=29b132e2@gateway/web/cgi-irc/labb.contactor.se/x-c35ceaec3b245c5b) 21.57.00 # hi 21.57.12 # but it isn't in the nk.bin package 21.57.40 # What the.....How is this even working..this code is connecting to the LTV250QV..which is NOT the lcd that the P2 has 21.57.53 # do they often connect the same way? 21.57.54 Quit miepchen^schlaf (Connection timed out) 21.58.28 # slyyf: what do you mean with 'the code connecting to the LCD'? 21.59.12 # mcuelenaere_: I meen the code that sends the raw commands to the lcd "lcd_write_reg" 21.59.44 # its not for the lcd I am working with, and yet, somehow it worksish 21.59.58 # well, it could have the same LCD IC 22.00.07 # or it could have a similar instruction set 22.00.42 # i have a suggestion. i own the ipod video 30gig and i obviously have rockbox on it. i just find it slightly irritating when im listening to music and i want to change the song. when you press the menu button on the ipod, it takes you back to the main menu. i think it would be better if it took you to back to the last screen you were at before you started listening to your music. ie. your playlist. 22.00.49 # the datasheet doesnt have any content about that 22.01.16 # MunkieMan: what does select do? it's doing what you want on my sansa e200 22.01.26 # * mcuelenaere_ wonders which datasheet is 'the' 22.01.27 # MunkieMan: that's not the way Rockbox works. Use Select to return to the browser. 22.01.33 # ah 22.01.55 # the Menu button does what its writing says: go to the menu. 22.03.00 # oh wow i feel stupid now. thanks for the help 22.03.17 # mcuelenaere_: the datasheet for this lcd 22.03.55 # slyyf: then if you have the datasheet, why send it the LTV250QV commands? 22.03.58 # slyyf: you need to seperate the lcd from the "logic that connects the lcd to the soc" though 22.04.25 # Llorean: thanks for the tip... 22.04.33 # Ok so, at the moment all that is there is the code from the D2 22.04.36 # yes, in generally it's like this: SoC lcd driver -> LCD IC -> actual LCD 22.05.02 # Right now it is connecting to three pins 22.05.18 # T0paz: it seems as that Nucleus source code is offline, perhaps I can upload my downloaded version 22.05.29 # ah, that would be very useful 22.06.04 # mcuelenaere_: Right now it is connecting to three pins called "/* GPIO A pins for LCD panel SDI interface */" 22.06.42 # T0paz: the code I have is a bit less than the one I was referring to, I think I don't have that one anymore 22.06.48 # but it's still the Nucleus kerne 22.06.49 # l 22.06.50 # ah 22.08.11 Quit pinkey ("Leaving") 22.08.59 # mcuelenaere_: whats "GPIO A pins LCD panel SDI interface" 22.09.17 # GPIO means General Purpose Input/Output 22.09.26 # and SDI? 22.09.44 # I don't know, does the P2 also run the TMS320DM320? 22.09.51 # is it possible to control the lcd while in diskmode? (on the ipod) 22.10.16 # mcuelenaere_: I couldnt find any docs to say if it did or did not 22.10.51 # slyyf: aren't there any pictures taken of the inner of the P2? 22.11.08 # none good quality that I know of 22.11.38 # oh wait, is this the samsung P2 port? 22.12.03 # its a modded cowond codebase 22.12.06 # to work on the p2 22.12.15 # that at the moment almost has the lcd screen working 22.12.15 # * mcuelenaere_ wonders why there's no wikipage of the P2 22.12.23 # there is 22.12.31 # http://www.rockbox.org/twiki/bin/view/Main/SamsungP2Port 22.12.31 Quit mcuelenaere (Read error: 110 (Connection timed out)) 22.12.39 # does it have its own forum thread? 22.12.42 Nick mcuelenaere_ is now known as mcuelenaere (n=mcuelena@rockbox/developer/mcuelenaere) 22.12.46 # SOmewhere..a bad one 22.13.59 # oh, I was a bit confused 22.14.17 # I thought, as the D2 has the same LCD as the ZVM, that it runs the same chipset; but these are TeleChips 22.14.17 # I found something 22.14.28 # http://image.segadget.com/en/3ee2dffa-5609-4232-a8e9-17a3d76be525_IMGs.jpg 22.14.43 # slyyf: then SDI should be explained in the datasheet 22.14.54 # k 22.14.58 # will it refer to it as an SDI? 22.15.45 # look for LCD (interface) 22.16.37 # It has a list of registers 22.16.42 Join n3hima [0] (n=n3hima@unaffiliated/n3hima) 22.16.59 # where might I find documentation for plugin.h? 22.17.28 # n3hima: plugin.h *is* the documentation, to a certain extent... but what exactly are you trying to do? 22.17.55 # n3hima: the source is the documentation for the various functions that are exported to plugins basically 22.18.01 # right... 22.18.13 # slyyf: SDI seems to be specific to the LCD, not the SoC 22.18.20 # so the ticks argument of the sleep function is what, exactly? 22.18.28 # mcuelenaere: oh wow..this datasheet is a draft.. 22.18.34 # mcuelenaere, do you know whether nucleus starts at 0x00000000 (well, after the jump), or whether they tacked on some code before nucleus starts? 22.18.46 # T0paz: yes, that was what I was looking for 22.18.54 # I have it written down *somewhere* 22.19.08 # nucleus starts by setting a state register to 1 ;) 22.19.09 # I do remember that the actual init has about 10-13 BL's 22.19.12 # that'll be easy to find... 22.19.13 # ah 22.19.18 # oh and look for strings 22.19.22 # ah yes 22.19.31 # one of those BL's only reference a string 22.19.48 # i've been making an HTML version of the disassembly (since i don't have IDA) 22.19.55 # you can click the links to see where they go ;) 22.20.08 # see inc.c 22.20.34 # I believe someone did the same with a script, I think it's committed to SVN 22.20.44 # ah yeah 22.20.53 # you'll recognize INC_Initialize() 22.20.56 # i'm considering making it colour-code interesting bits (like hardware accesses) 22.21.03 # look for a license string, that's LIC_License_Information() 22.21.45 # ah yes 22.22.44 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 22.23.17 Join EspeonEefi [0] (i=eefi@STRATTON-SIX-FOURTY-SIX.MIT.EDU) 22.24.10 # T0paz: whenever you've found INC_Initialize(), Application_Initialize() is the Creative custom code 22.24.16 # that's when the real RE starts :) 22.24.16 # ah, cool 22.24.22 # ah yes ;) 22.24.26 # i'll get the hang of this one day 22.24.28 # one of the first calls in that one, is drivers_init() 22.25.15 # I once had quite a lot of all this disassembled, but lost it during a crash.. 22.25.19 Part n3hima 22.25.22 # ah, doh 22.25.39 # T0paz: the string is '"Accelerated Technology Internal Use Only - Serial Number: NP0000' 22.25.47 # ah yes, i just found that 22.25.48 # pixelma: when you get a chance, would you mind removing your .rockbox/rocks/demos/pictureflow.cfg and trying this patch? http://pastie.org/370512 22.25.58 # (I found a Zen X-Fi IDA database I had laying around) 22.26.00 # i haven't disassembled the 40200000 block 22.26.02 # maybe i should 22.26.10 # (it's in there) 22.26.30 # i think it improves things greatly on c200 sim... and it looks nice on several other portrait and landscape sims that i tried. 22.27.59 # T0paz: ah yes, look for lcd0 22.28.00 Quit MunkieMan ("CGI:IRC (EOF)") 22.28.05 # that's the internal LCD driver name 22.28.11 # there are more of these names 22.28.14 # like codec0 etc 22.28.21 # BigBambi: your patch could potentially apply to the e200 too 22.28.39 # I'm gonna test disk full cases later and report back 22.28.52 # kugel: The PREV not UP one you mean? 22.28.59 # yep 22.29.02 # hmm this doesn't look good, it seems as the Zen also has mcu0 22.29.04 # I can test too, one mo 22.29.12 # I just need to find my e200 :) 22.29.36 # ah :) 22.30.44 # BigBambi: no matter of that, I think "PLAY" is the "naming convention" of the up button (the database says play) 22.31.02 # kugel: yes, that's true 22.31.25 # T0paz: ahh, the main thread is added in Application_Initialize() 22.31.33 # so there won't be a branch in it 22.31.49 # Unhelpful: just came back, will test in a bit - on c200 I assume? 22.32.47 # kugel: That appears to be the only instance of UP 22.32.58 # I'll verify it then change it accordingly 22.33.09 # yea, rockbox-wide even 22.33.11 # ok, i've found the license function 22.33.40 Quit t0mas ("good night") 22.34.05 # i've found all the BLs 22.35.14 # BigBambi: hm, I actually think we shouldn't even try to translate buttons. just say what's printed (i.e. not PREV, but |<< in case of the sansas) 22.36.08 # translating buttons is nasty, since it's basically never what's actually printed on the buttons, and is always difficult if the button mapping changes 22.36.13 # kugel: I'm not so sure 22.36.21 # That could get difficult though 22.36.31 # pixelma: yes, i've kept the reflections the same height, but allowed images to be wider - they should be about 50x50 for square covers now, on c200 22.36.34 # And << does mean PREV pretty much 22.37.17 # kugel: I think that'd need wider consultation - this is just getting it correct/consisytent to what is there now - a wider shange can then be discussed 22.37.28 # possibly, but I don't see what's wrong with just saying the same that's printed on the button 22.37.39 # kugel: How would you say what's printed on the lower button on an e200? 22.37.50 # "a long horizontal line above 3 shorter ones" 22.37.56 # kugel: It i sometimes not clear what is printed 22.38.00 # *is 22.38.09 # rasher: yea, that's what I just noticed to be problematic too :/ 22.38.14 # hmmm, my e200 is refusing to connect 22.38.16 # kugel: Let alone the center button "" 22.38.35 # well, obviously, if there's nothing printed we need to give it a name 22.39.27 # BigBambi: Don't get me wrong, I didn't mean to change that just now (especially not in your patch), I just wanted to mention it 22.39.39 # kugel: sure 22.39.40 # sure it needs wider consultation 22.40.02 # As soon as my sodding e200 decides to connect to my laptop, I can test it 22.41.03 # BigBambi: are you using the quickscreen? :> 22.42.08 # T0paz: do you also have at about 0x400BE0A4 a string 'system'? 22.43.33 # i do at 0x4004FB20 22.43.52 # kugel: On the e200? I'm not doing anything except swearing at it 22.44.20 # well, lots of times infact 22.44.28 # but not near there 22.44.45 # T0paz: yes, I know but at that position in the zen x-fi file is the drivers_init() func 22.44.53 # ah 22.44.56 # how does the function look like above directly that string? 22.45.18 # s/(above) (directly)/\2 \1/ 22.46.31 # BigBambi: no, any target 22.46.33 Join QuickStart [0] (n=QUICKSTA@pool-72-88-146-62.nwrknj.east.verizon.net) 22.46.46 # kugel: Yes, from time to time 22.47.12 # a couple of bl, a couple of blx 22.47.41 # just that? 22.47.54 # BigBambi: I have 2 patches which could need testing: http://www.rockbox.org/tracker/task/9828 and http://www.rockbox.org/tracker/task/9706 22.47.57 # and an ADR Rx, aSystem? 22.48.00 Join miepchen^schlaf [0] (n=miepel@p579ECC07.dip.t-dialin.net) 22.48.10 # about 8 BL's 22.48.29 # ah, the one above that has more BLs 22.48.37 # i really should make it easier to find string literals 22.48.44 # at the moment i'm finding them in a text editor first 22.48.49 # er, hex editor 22.48.53 # are there more BL's in the first BL? :) 22.49.26 # ah and one of the BL's reference a 'flash' string 22.49.27 # 9? 22.49.41 # kugel: I think that lang file must have got changed - I just tried on my e200 running a very old version (r18something) and it says press left 22.49.44 # I have about 7 very close to each other 22.49.47 # heh, i'm lost now 22.50.07 # Unfortunately, as I cannot currently connect my e200 to my laptop, I can't update and check now 22.50.31 # well the 'flash' reference is in a BL under the main function (the one with 8 BL's) 22.50.36 Join MethoS- [0] (n=lem@host-091-097-240-133.ewe-ip-backbone.de) 22.50.46 # BigBambi: hm, but the key hasn't changed? 22.50.54 # looks like a buggy commit to me then 22.51.09 # kugel: I'll have a look in the keymap, but can't check on target 22.51.34 # seems like one of those functions is also a ATA_DMA driver init 22.53.00 # hmm it seems like it's easy to spot register_irq() calls 22.53.16 # they all start with setting a string in R0 containg the name of the IRQ 22.53.21 # containing* 22.53.23 # kugel: ACTION_STD_CANCEL is BUTTON_LEFT still 22.54.00 # it looks like in fact that I shouldn't be splitting the c200 out, but changing both c200 and e200 to PREV 22.54.22 # indeed 22.54.24 # kugel: Do you know what the e200v2 uses for cancel? 22.54.29 # left 22.54.43 # mcuelenaere, the name being things like 'lcd0' ? 22.54.52 # nope, that's something else 22.54.57 # * kugel asks svn blame 22.55.02 # this seems like STMP37xx specific 22.55.06 # or it's SDK 22.55.08 # its* 22.55.21 # OK, so I'll change that patch to replace UP with PREV instead 22.55.23 Quit bmbl ("Woah!") 22.55.34 # strings like ATA_DMA, AUDIOOUT, MCU_HISR, SSP2_DMA, SSP1_DMA 22.55.40 # ah 22.56.40 # those with lcd0 are mostly either driver_register() or driver_query() calls 22.56.58 # (those names are invented) 22.57.24 # rasher: So if I am in fact changing a string, rather than changing target then adding another one, do I just edit english.lang then leave the others? 22.58.41 # although, a lot of langs seem to leave the "UP" or "POWER" untranslated, so I could just change them 22.59.46 # not all however 23.00.06 # T0paz: about those weird 0x4xxx references, Creative mapped/copied quite some data before calling the Nucleus init on the ZVM 23.00.14 # kugel: In reply to the patche, I can't right now but I'll try and have a look tomorrow 23.00.14 # I presume this is also true for the Zen, only SoC specific 23.00.28 # hmm, neither ATA_DMA or MCU_HISR are directly referenced by address 23.00.38 # (from anywhere) 23.00.42 # so you could try looking what happens at 0x0 (lookup how the ARM MMU works) 23.00.53 # BigBambi: no problem, no need to hurry :) 23.00.58 # ah 23.01.40 # oh or these addresses could also be set up by FBOOT 23.01.57 # let's hope they aren't, because it isn't in nk.bin 23.02.06 Quit {phoenix} (Remote closed the connection) 23.02.16 # + FBOOT is partly encrypted by RSA 23.02.20 # they were at 0x3fff.... (just below the main code) 23.02.22 # which seemed strange 23.02.23 # ah 23.02.38 # by some sigmatel-proprietary key? 23.02.55 # no, I'm talking about the ZVM 23.03.00 # with a Creative-key :) 23.03.01 # ah 23.03.10 # though is the key in firmware? 23.03.13 # Creative likes to do everything as they wish 23.03.15 # yes it is 23.03.33 # so they've probably also rewritten the actual bootloader 23.04.12 # but you shouldn't worry about this RSA-stuff, it's in FBOOT and currently there's no way to access it :) 23.04.24 # BigBambi: actually, c200 is more interesting for me anyway, since i can test on the e200 myself 23.04.27 # i wonder why they bother 23.04.37 # to do all this encryption? 23.04.43 # unless that has the WMA DRM keys in it or something 23.04.53 # yes, it's probably something like that 23.05.14 # although there are several layers of encryption 23.05.30 # i guess it's just a deterrent 23.06.01 # (unless there is RO memory inside the SoC) 23.06.27 Quit MTee (Connection timed out) 23.07.17 Join PaulJam [0] (n=PaulJam_@vpn-3040.gwdg.de) 23.07.33 # BigBambi: Yeah, just editing english.lang (both source and dest) should do it 23.07.38 Join AndyI [0] (i=AndyI@212.14.205.32) 23.08.04 # rasher: Thanks - will it then get marked as needing attention for the other languages by your page? 23.08.13 Quit QuickStart (Remote closed the connection) 23.08.23 # * mcuelenaere wonders as Sigmatel seems to be taken over by Freescale whether they would provide more information 23.08.54 # BigBambi: It should 23.09.03 # Cool, thanks 23.09.16 # BigBambi: it depends on whether the part of english lang is different from the in the translation (which it will be) 23.09.42 # rasher: Ah, OK. I'm slowly starting to get it :) 23.10.54 # rasher: but until a translater bothers enough, the langs will be wrong or show the source string? 23.11.43 # Show the old string I imagine 23.12.03 Quit Zoxc () 23.13.57 # mcuelenaere, do you know what the 'AHB to APBX Bridge' does? 23.14.09 Quit PaulJam_ (Read error: 145 (Connection timed out)) 23.14.12 # I recognize AHB 23.14.31 # it's probably a generic term, it's also used in TMS320DM320 23.14.42 # i think that's ARM related 23.14.55 # ah, it is AMBA 23.15.00 Quit pixelma (Read error: 110 (Connection timed out)) 23.15.06 # OK, 9826 updated. Look at the complexity of that patch! :P 23.15.24 # so presumably allows the core to talk to APBX, whatever that is 23.15.51 Join pixelma [0] (n=pixelma@rockbox/staff/pixelma) 23.16.01 # yes, probably 23.16.02 # the second call in Application_Initialize sets/clears SFTRST and then clears CLKGATE (of the APBX control register) 23.16.10 # an ARM926-EJS has an AHB 23.16.24 Quit pyro_maniac ("Leaving.") 23.16.28 # BigBambi: impressive! :) 23.16.37 Quit amiconn (Read error: 110 (Connection timed out)) 23.16.40 # T0paz: are you deriving this from the BSP? 23.17.02 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 23.17.03 # (clearing CLKGATE probably means disabling the clock for APBX, so disabling it) 23.17.18 # or it could be the opposite 23.17.21 # ;) 23.17.25 Join tvelocity [0] (n=tony@adsl21-6.her.forthnet.gr) 23.17.34 # kugel: seeing as a lot of the other langs doen't translate UP etc, I'm going to change those too 23.17.47 # yeah, the BSP 23.18.57 # kugel: The translation will show the english string, which is better than a wrong string 23.19.06 # aren't there any drivers in that? (on which you can base yourself) 23.19.08 # the call after does the same thing to the APBH interface 23.19.10 # rasher: I agree 23.19.19 # At least if I understand the question 23.19.25 # i can't find any SMTP drivers in the BSP except for the IDE one 23.19.27 # which isn't very helpful 23.19.40 # er, STMP 23.19.46 # hmm that's weird 23.20.22 # oh, and a serial debug driver 23.21.19 # kernel2.6.16\linux-2.6\arch\arm\mach-stmp36xx\stmp36xx.c handles the interrupts 23.21.57 Join MTee [0] (n=mtee@41.236.177.169) 23.22.28 # hmm it'll probably be easier to do a diff against linux 2.6.16 23.23.38 Quit bluebrother (Nick collision from services.) 23.23.43 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 23.24.43 # STMP progress? i have one of those... but there are so very many devices :/ 23.25.04 # BigBambi: that's what I did too today. I think if it's easy, that one should change as many langs as possible 23.25.10 # still stabbing in the dark... 23.25.24 # s/that/then 23.25.54 # kugel: Yes, I've just finished. If the lang hadn't previously translated UP, POWER, PREV etc then I have just swapped UP and PREV by hand 23.29.07 # seems like archive.org has a backup of linux.sigmatel: http://web.archive.org/web/*/http://linux.sigmatel.com 23.29.45 Join MethoS-- [0] (n=lem@host-091-096-209-131.ewe-ip-backbone.de) 23.30.48 Quit MethoS-- (Client Quit) 23.31.00 Join MethoS-- [0] (n=lem@host-091-096-209-131.ewe-ip-backbone.de) 23.31.03 Quit MethoS-- (Remote closed the connection) 23.31.23 Join MethoS-- [0] (n=lem@host-091-096-209-131.ewe-ip-backbone.de) 23.31.23 Quit MethoS-- (Remote closed the connection) 23.34.59 # * mcuelenaere is off to bed 23.36.20 # night 23.36.28 # i think i'll improve my disassembler 23.38.45 # T0paz: you know of http://svn.rockbox.org/viewvc.cgi/trunk/utils/disassembler/arm/ ? 23.39.01 # i did spot that 23.39.22 # i'm using objdump for the actual disassembly 23.39.25 # Unhelpful: ping 23.39.46 # just wrapping it in HTML with clickable addresses and demarcations of subroutines and things 23.39.47 # yes? 23.40.42 # yes, I think vitja has done the same 23.41.06 Join PaulJam_ [0] (n=PaulJam_@vpn-3039.gwdg.de) 23.42.16 # Unhelpful: http://www.rockbox.org/tracker/task/9777 <-- I'm inclinded to close this, as I'm fairly sure it's "not a bug" (and the reporter doesn't answer our questions). what would you say? 23.42.27 Quit bluebrother ("leaving") 23.42.34 # I think it's the usual stop shortly to resize album art 23.43.21 # It seems like the sansa SD bug may be gone soon 23.44.00 # \o/ 23.44.24 # gevaerts: should I test too? I guess more tests are appreciated 23.44.48 # gevaerts: awesome - has someone worked some magic? 23.44.53 # gevaerts: woo 23.44.55 # kugel: I guess more tests are certainly welcome. See FS#8663 23.45.21 # gevaerts: how would I test? copy some gigabytes and diff or md5 the files? 23.45.31 Quit mcuelenaere () 23.45.56 # kugel: that's what I did. Unmount in between to make sure the reading back actually comes from the device and not from an OS cache 23.46.27 # gevaerts: did you use full or highspeed usb? 23.46.40 Quit MethoS- (Read error: 113 (No route to host)) 23.46.55 # I always use highspeed. It shouldn't matter though 23.47.10 # * gevaerts can't imagine filling up his e280 on full speed 23.48.14 Join PaulJam__ [0] (i=PaulJam_@vpn-3016.gwdg.de) 23.50.41 Quit n1s () 23.51.22 # gevaerts: ok, how to enable usb again? 23.51.42 # kugel: define USE_ROCKBOX_USB somewhere. 23.52.00 # Hey guys, I am going to take a break from the LCD for a bit, any idea how I would turn on/off the three LED rings on the P2? 23.52.08 # * gevaerts sets EXTRA_DEFINES=-DUSE_ROCKBOX_USB 23.52.25 # Is the one way of figuring that out dissasembly? 23.53.34 # gevaerts: The patch in #8663 is more of a workaround at the cost of speed than a true fix 23.53.54 *** Saving seen data "./dancer.seen" 23.54.00 # slyyf: yes, or read the data sheet if you have one 23.54.49 # There's some PP register we don't know yet. The transfer involves a fifo, which should allow reading and writing at maximum speed as long as we don't over-/underflow it. 23.56.02 # I have an optimised write transfer routine that makes the bug hit immediately. This is quite strange and poits to some missing write timing setting, because the problem doesn't happen on read, even though reading is fully optimised. 23.58.07 # * gevaerts is confused 23.58.27 # The description doesn't really match the patch...