--- Log for 07.01.109 Server: niven.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 29 days and 15 hours ago 00.05.22 Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") 00.06.57 Join AndyI [0] (i=AndyI@212.14.205.32) 00.08.41 Join jeffronius [0] (n=kvirc@69.12.221.210) 00.10.08 Join nernie [0] (n=chatzill@75.118.202.0) 00.10.45 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 00.11.44 # I have an iPod Classic (80GB) and would like to install Rockbox on it. Would I use the iPod Video 60/80GB installer? 00.12.08 # nernie: nope, the classic is not supported by rockbox 00.12.47 # Bagder: Doh, ok. Thank you very much! 00.12.57 Join ameyer [0] (n=ameyer17@adsl-75-57-201-238.dsl.emhril.sbcglobal.net) 00.13.19 Quit Thundercloud (Remote closed the connection) 00.13.30 Part nernie 00.14.20 Quit blahrus ("Ex-Chat") 00.19.09 Quit timc ("Leaving") 00.21.37 Quit bertrik (Remote closed the connection) 00.22.20 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 00.26.26 Join _Auron_ [0] (n=DarkAuro@ppp-70-249-156-112.dsl.rcsntx.swbell.net) 00.26.29 Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) 00.36.22 Quit bluebrother ("leaving") 00.41.35 Join domonoky1 [0] (n=Domonoky@g229069011.adsl.alicedsl.de) 00.41.35 Quit domonoky (Read error: 104 (Connection reset by peer)) 00.41.49 Join MarcGuay [0] (n=chatzill@ip216-239-89-154.vif.net) 00.43.10 Quit MethoS- (Remote closed the connection) 00.43.13 # Remove the warning about mingwm10.dll? 00.44.38 # kugel: you have multivolume issues related to RaaA? 00.46.43 # gevaerts: well, it doesn't have mutlivolume defined 00.47.15 # and I get errors that some structs in fat.c don't have drive/volume element 00.47.32 # * jhMikeS pongs the pingers 00.47.47 # Why does it even have fat.c? 00.48.33 # jhMikeS: I updated http://www.rockbox.org/tracker/task/9724, I think it's good now 00.48.52 # gevaerts: I don't know, shouldn't it? 00.49.02 # probably not if you say that ;) 00.49.40 # kugel: if you're using files from the host system, which I thought is about half of the point of it, you're not going to handle FAT at all 00.50.00 # hm, makes sense 00.50.25 *** Saving seen data "./dancer.seen" 00.50.27 # anyway, I enabled those for the raaa, and still had filesystem access w/o problems 00.50.59 # but ok, thanks for the info, then it's building it for some reason 00.51.22 # MarcGuay: Maybe better to say something like "or upgrade to v1.0.9" (for now) ? 00.51.42 # I think it's probably a good idea to make sure it doesn't compile fat.c and hunt down all places wanting to use it 00.51.52 # v1.0.9 doesn't appear for me on the download server I'm connecting to though... 00.56.32 # BACKLIGHT_FADING_TARGET == not controllable? :) 01.00.40 # domonoky1: Looking at the RockboxUtility wiki page (specifically the OS X bug for Sansa/Ipod), is there a reason rbutil installs the bootloader first? The manual install instructions generally say to install Rockbox first, then the bootloader, so the bootloader always has something to run when it boots. 01.01.43 # linuxstb: no real reason i think. 01.02.10 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-a68e7f3d2ba6bf28) 01.06.52 # kugel: Why does BACKLIGHT_FADING_TARGET imply HAVE_BACKLIGHT_FADING_BOOL_SETTING? 01.07.56 # shouldn't it? 01.08.06 # I understood it from what you were saying 01.09.23 # you said your define is basically only needed for the setting 01.09.32 # imho, target-specific implementations imply no particular setting type. The beast is just one example of such an implementation that happens to use bool. 01.10.27 # well, bool is the only one that works for _TARGET anyway 01.10.54 # if you use int, you'll likely have different int settings for different target specific backlight fading 01.11.05 # s/have/need/ 01.11.10 # You mean it wont work if some target selects INT and TARGET? 01.12.11 # I have my doubts, since I imagine that different target specific implementations cannot use the same int settings (kinda by definition) 01.12.52 # linuxstb: the iAudio7 has FIRMWARE_OFFSET_FILE_CRC as 0 and FIRMWARE_OFFSET_FILE_DATA as 8... This seems off from the TC file format...? 01.12.55 # I was thinking the setting type #define should only select the strings and settings code and be independent. 01.13.00 # in that case _TARGET isn't sufficient 01.13.10 # domonoky1: Another question - does rbutil have 7zip support? 01.14.47 # linuxstb: i dont think so i uses zlib 01.15.27 # domonoky1: Ah, OK. It's just that the original firmware for the Beast is available in .cab format inside a .exe inside a .iso inside a .zip from Toshiba's website. 7zip can hande all those formats... 01.16.11 # jhMikeS: the strings are dependant on the settings so that doesn't quite work too (at least not in the way I thought it to work) 01.17.35 # you mean the list in settings_list.c? That can be variable. 01.17.46 # linuxstb: if really needed, i dont think it would be much of a problem to replace zlib with a 7z lib in rbutil. :-) 01.18.11 # It would make normal installs slightly faster... 01.18.44 # * linuxstb realises the .7z files aren't actually available... 01.19.51 # jhMikeS: so you would do "#if defined(HAVE_BACKLIGHT_FADING_INT_SETTING) && defined(MY_TARGET)"? 01.20.45 # anyway, I thought apps/ should only see INT_SETTING and BOOL_SETTING, but those aren't sufficient if you plan to have TARGET be usable for both 01.22.45 # I was thinking about simply turning the cfg value list into a single #define for the int setting. 01.23.54 # Of course we can just not worry about it until it comes up. I doubt it's on the horizon at all. 01.25.33 # that was my impression too 01.27.00 # and a target specific fading is going to be directly in the driver, and thus probably not configurable 01.28.37 # linuxstb: If we used .7z as our main archive format for it instead of .zip (as in, not just what the util downloaded) we'd at least force MacOS users to explicitly download an archive handler that wouldn't be problematic like the OS-native one is. I'm not sure if forcing them to acquire software is good, but forcing them not to use bad software might be. 01.29.59 # Even Gigabeat F would be a bool since it's technically closest to SW fading. 01.31.14 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-f7c23ab8d9ab4c80) 01.33.01 # linuxstb: for what its worth, I don't think the 7zip lib can extract the nk.bin, looking at it I think its 7zip only, and that the 7zip Windows GUI probably uses some other libraries to handle extracting exe files 01.33.25 # but that was only from a quick glance at the linux library source so i may have missed something 01.37.37 # hrm, switching to .7z to make mac users to download 7zip would also force linux and windows users to download 7zip 01.38.00 # ameyer: Well, most people *should* be using the utility anyway 01.38.04 # although you guys might be able to include the binary with rbutil or something along those lines 01.38.10 # So, in general, we won't be forcing anyone actually following the directions to download anything new. 01.38.44 # that works, and making hackers download 7zip isn't that big of an additional barrier to entry 01.39.38 Quit Seed (Read error: 145 (Connection timed out)) 01.39.56 # i think recovering the nk.bin makes more sense, since it can be done more or less automatically whenever we correct the broken firmware partition 01.40.00 # the linux 7z also does iso and whatever exe archiving it uses - i extracted with it. 01.40.05 Quit DerDome ("Leaving.") 01.40.10 Join Dauron [0] (n=DarkAuro@ppp-70-249-156-112.dsl.rcsntx.swbell.net) 01.40.10 # the command line too? 01.40.18 Quit _Auron_ (Read error: 54 (Connection reset by peer)) 01.40.27 Nick Dauron is now known as _Auron_ (n=DarkAuro@ppp-70-249-156-112.dsl.rcsntx.swbell.net) 01.40.29 # yes, that's all i tried 01.40.31 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 01.40.37 # sorry mean tool, good to know 01.42.56 Quit efyx_ (Remote closed the connection) 01.44.37 Part toffe82 01.45.41 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 01.46.11 Part domonoky1 01.46.28 Quit culture (Read error: 60 (Operation timed out)) 01.48.00 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 01.48.27 # saratoga: Yes, I agree using your idea to recover the nk.bin is a nicer solution - it has the advantage of also making sure we keep the identical version nk.bin to the one the user was previously running. 01.49.03 # saratoga: I'm not sure if it's a good idea, but writing a Rockbox plugin to do that recovery would be relatively easy. 01.51.53 Quit JdGordon|zzz (Read error: 54 (Connection reset by peer)) 01.52.48 Quit Seed (Read error: 60 (Operation timed out)) 01.53.05 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 01.53.32 Join JdGordon|zzz [0] (n=jonno@123-243-140-31.static.tpgi.com.au) 01.53.45 # saratoga: I'm not sure what you mean by "whenever we correct the broken firmware partition" though... 01.54.03 # * linuxstb needs to sleep and resigns himself to never being online the same time as saratoga... 01.55.06 Join culture [0] (n=none@cpc2-bele3-0-0-cust89.belf.cable.ntl.com) 01.57.19 # are pictures of a "real" v2 Sansa C250 still needed? 01.57.19 # I made some scans of mine because I couldn't find them anywhere on the net, but I don't know if that's because they already exist somewhere, or because they're not needed. 01.58.24 Quit ameyer ("leaving") 02.04.17 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.5/2008121623]") 02.04.39 # kerwood: Have you checked the c200v2 wiki page at rockbox.org? 02.04.41 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-427dc6c1c639bdea) 02.07.08 Join AndyIL [0] (i=AndyI@212.14.205.32) 02.08.42 Quit itcheg (Client Quit) 02.10.50 Quit AndyIL (Read error: 54 (Connection reset by peer)) 02.11.49 Quit AndyI (Read error: 104 (Connection reset by peer)) 02.13.14 # MarcGuay: yes, which is what made me wonder... 02.13.33 # If there are none on that page it can't hurt to add some. 02.17.45 Part XavierGr 02.17.51 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 02.18.54 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 02.19.47 # In that event I should like rockbox.org wiki write permssion, name: MarshallJose 02.20.18 # anyone know how to build rbutil release on the mac? is it just svn up + make? 02.21.01 Quit culture (Read error: 110 (Connection timed out)) 02.25.16 # kerwood: added 02.25.37 # wa 02.30.10 # linuxstb: the Beast comes with an invalid firmware partition that bothers the linux driver 02.30.36 # the windows one doesn't seem to mind however, so technically its only needed if the user intends to use linux 02.30.47 # actually the data partition may have it too 02.31.16 # since i couldn't seem to mount it in windows, but i'm not the best one to to ask about that since i've intentionally not changed my partitions at all on the beast 02.32.00 Quit saratoga ("CGI:IRC (EOF)") 02.42.07 Join AndyI [0] (i=AndyI@212.14.205.32) 02.46.55 Join Darksair [0] (n=user@125.33.197.248) 02.50.27 *** Saving seen data "./dancer.seen" 02.54.21 Quit MarcGuay ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") 02.55.03 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 03.00.04 Join Dauron [0] (n=DarkAuro@ppp-70-249-156-112.dsl.rcsntx.swbell.net) 03.05.02 Quit _Auron_ (Read error: 60 (Operation timed out)) 03.05.02 Nick Dauron is now known as _Auron_ (n=DarkAuro@ppp-70-249-156-112.dsl.rcsntx.swbell.net) 03.07.58 Quit AndyI (Read error: 104 (Connection reset by peer)) 03.11.33 Quit Darksair ("Use the Force, Luke!") 03.12.14 Join toffe82 [0] (n=chatzill@99.149.49.3) 03.22.51 Quit PaulJam (".") 03.23.23 Quit robin0800 (Remote closed the connection) 03.33.58 Join Darksair [0] (n=user@125.33.197.248) 03.41.21 Join Willwolfe [0] (n=chatzill@net35-14.netkaster.ca) 03.46.34 Quit blithe ("Lost terminal") 03.46.45 Join blithe [0] (n=blithe@stiletto.djblithe.com) 03.57.21 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-dbf290b98c7f8c32) 04.01.12 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 04.03.12 Quit robin0800 (Client Quit) 04.03.29 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 04.05.06 Join blkhawk- [0] (n=blkhawk@g226131166.adsl.alicedsl.de) 04.12.50 Quit tvelocity (Remote closed the connection) 04.15.19 Join Barahir_ [0] (n=jonathan@Xa2a3.x.pppool.de) 04.20.23 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 04.21.00 Quit blkhawk (Read error: 110 (Connection timed out)) 04.21.04 Nick blkhawk- is now known as blkhawk (n=blkhawk@g226131166.adsl.alicedsl.de) 04.28.50 Quit robin0800 ("Leaving") 04.29.12 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 04.29.15 Join robin0800 [0] (n=quassel@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 04.30.52 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 04.32.21 Quit Barahir (Read error: 113 (No route to host)) 04.35.56 Quit miepchen^schlaf (Connection timed out) 04.36.56 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-cbe1566472ade9da) 04.39.52 Quit robin0800 (Remote closed the connection) 04.40.10 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 04.41.25 Quit advcomp2019 (Read error: 104 (Connection reset by peer)) 04.41.45 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 04.47.21 Quit kadoban (Read error: 113 (No route to host)) 04.50.32 *** Saving seen data "./dancer.seen" 04.56.14 Nick Bensawsome is now known as BensJammin (n=Bensawso@unaffiliated/bensawsome) 04.59.53 Quit robin0800 (Read error: 60 (Operation timed out)) 05.03.47 Join plutonian [0] (n=plutonia@c-67-183-155-218.hsd1.wa.comcast.net) 05.04.30 Join AndyI [0] (i=AndyI@212.14.205.32) 05.04.44 Nick BensJammin is now known as Bensawsome (n=Bensawso@unaffiliated/bensawsome) 05.05.36 Quit plutonian (Client Quit) 05.05.49 Quit Seed ("cu, Andre") 05.10.54 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 05.26.50 Quit jfc (Read error: 104 (Connection reset by peer)) 05.27.18 Join jfc [0] (n=john@dpc691978010.direcpc.com) 05.27.27 Join Rob2223 [0] (n=Miranda@p4FDCCC79.dip.t-dialin.net) 05.27.36 Join midkay_ [0] (n=midkay@75-172-104-240.tukw.qwest.net) 05.27.38 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 05.28.05 Join toffe82_ [0] (n=chatzill@99.149.49.3) 05.36.07 Quit Willwolfe ("ChatZilla 0.9.84 [Firefox 3.0.1/2008070208]") 05.38.41 Quit Nibbler (Remote closed the connection) 05.38.46 Join fyrestorm [0] (n=fyre@cpe-68-173-235-77.nyc.res.rr.com) 05.43.09 Quit toffe82 (Read error: 110 (Connection timed out)) 05.44.20 Part toffe82_ 05.44.41 Quit midkay (Read error: 110 (Connection timed out)) 05.57.03 Quit amiconn (Nick collision from services.) 05.57.06 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 06.01.14 Join wmw1900 [0] (n=chatzill@c-68-47-244-186.hsd1.tn.comcast.net) 06.01.50 Nick wmw1900 is now known as Walter (n=chatzill@c-68-47-244-186.hsd1.tn.comcast.net) 06.02.13 Quit Walter (Client Quit) 06.08.02 Quit aurix_lexico ("Leaving.") 06.14.53 Quit pixelma (Read error: 110 (Connection timed out)) 06.17.48 Join gartral1 [0] (n=Gartral@75.33.82.151) 06.20.53 # r19702m has a bug: the backlight turns off, then, back on 06.24.53 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.41.26 # saratoga: if i recall correctly, the data partition is normal, but that doesn't matter, since linux refuses to expose any of the partitions if it doesn't like the table 06.45.06 # * lucent reads backlog 06.48.53 Part gartral1 06.50.36 *** Saving seen data "./dancer.seen" 06.59.11 Join midkay [0] (n=midkay@rockbox/developer/midkay) 07.02.03 Quit midkay_ (Read error: 60 (Operation timed out)) 07.18.07 Quit jhulst (Remote closed the connection) 07.26.29 Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 07.59.09 # do many people break their players when testing the early versions of rockbox? 07.59.36 # it depends on the device 08.00.04 Quit BHSPitLappy (Remote closed the connection) 08.01.37 # regardless of player I'd still say the count of dead players because of rockbox is pretty damn small 08.02.55 # lucent sent me rockbox for the sansa fuze, with so many warnings it's scary!! 08.05.06 # rockbox is not yet deemed ready for public consumption for that device yet...while there may be little chance of it permanently doing something harmful to your device, you should be aware that the port is mainly for developers to...well...develop at this stage and that the port is unsupported at this point 08.06.07 # I want to help with the tests, not just using it 08.09.16 Join GodEater_ [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-f56327cf33fe5231) 08.11.35 Join Willwolfe [0] (n=chatzill@net35-14.netkaster.ca) 08.18.56 Join kugel [0] (n=chatzill@unaffiliated/kugel) 08.24.52 Quit JdGordon (Remote closed the connection) 08.26.57 Quit Acksaw (Connection reset by peer) 08.27.10 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 08.28.13 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.30.08 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 08.32.08 Join Rob2222 [0] (n=Miranda@p4FDCE3B5.dip.t-dialin.net) 08.32.31 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 08.33.00 Part _Auron_ 08.35.15 Quit BigBambi (Read error: 113 (No route to host)) 08.43.16 Join timc [0] (n=aoeu@124.93.243.83) 08.46.20 # anyone wanna test a quick patch which fixes up the debug menu wierdness? (and changes the simplelist handling a bit which is what actually needs testing) 08.46.26 # Unhelpful: I bet you won't be surprised by me saying I don't think 576 bytes saving is worth the hassle. 08.46.55 # Zagor: no, i suppose i'm not shocked. :) 08.49.09 Quit Anges ("Leaving.") 08.49.33 # would using #define open rb->open be more acceptable? it leaves a good deal less mess in the core file than API() does. 08.50.05 # i just don't really like increasing the core binsize, without any new features, on some of the targets with the least memory 08.50.23 # as amiconn said #define open will break on sims, since they already do that 08.50.27 # without any new *core* features, sorry. 08.50.36 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.50.39 *** Saving seen data "./dancer.seen" 08.51.21 # hrm. but, plugins on sim are surely still expected to use the plugin_api? 08.52.14 # indeed. I need to look at that. 08.52.20 Join LinusN [0] (n=linus@gateway/web/cgi-irc/labb.contactor.se/x-c833e4da1e64a216) 08.52.58 # if that is indeed the case, since such a macro would only happen when the file is compiled as a plugin, it should still be safe. 08.57.40 # i could "just try it"... but i should probably ask somebody who knows how the sim works ;) 08.58.05 # it ought to work. open() is redefined in firmware/include/file.h, which is never included in plugins 08.58.23 # yeah, try it 08.58.54 # even if so, as long as plugins are still supposed to call via the API, i can undef it, first. 08.59.06 # true 08.59.18 # yeah, i'll save the hack-job for scaling support in-core to a branch, in case we really need to go that way 08.59.46 # sim plugins are definitely supposed to go via the api 09.00.24 Join pixelma [0] (n=pixelma@p54BD450B.dip.t-dialin.net) 09.00.45 # good deal... i think the plugin-only x_init function and plugin_api pointer should just go into the wrapper file, as well... 09.01.08 # yes 09.01.12 # are the archos targets the ones where we have non-square pixels? 09.01.31 # I don't know 09.03.02 # Unhelpful: Yes, although the iAudio remotes also have (slightly) non-square pixels 09.03.13 # That fact is ignored by rockbox atm 09.03.34 Join Anges [0] (n=agnes@lns-bzn-49f-62-147-173-3.adsl.proxad.net) 09.03.44 # amiconn: there's no scaler output for remotes at present, though a format plugin could provide it. 09.04.13 # Well, the M3 uses the remote as its main display 09.04.19 # right :/ 09.04.59 # then i already have *somewhere* that i need to do AR compensation. do we have accurate PAR values for the displays? 09.05.13 Quit Willwolfe ("ChatZilla 0.9.84 [Firefox 3.0.1/2008070208]") 09.05.27 # Unhelpful: open() and friends are prefixed with 'sim_' in the sims. Check the PREFIX() business in plugin.[ch] 09.05.50 # AR? 09.06.04 # aspect ratio, sorry. and Pixel aspect ratio. 09.06.06 # amiconn: hmm, why are we doing that? 09.07.32 # Because plain open() etc are the host's functions which we have to call. Hence our own functions (which are wrappers for the host functions) need to be named differently 09.08.01 # amiconn: but the plugin functions are just pointers in a struct. why do they have to be renamed? 09.08.01 # Unhelpful: Archos pixels are taller than wide, w=0.8*h 09.08.43 # i *think* that if we just apply an appropriate multiplier to each of the input dimensions before calculating the output dimensions, it will be fine 09.09.45 # so, on sim, the call should be rb->sim_open? 09.10.04 # The iAudio remote pixles are wider than tall, but only a little bit. I measured AR some time but didn't document it :\ 09.10.09 # Unhelpful: Archos display pixels are 80% of their height wide - example: the chessboard in th plugin is 80x64 to compensate that and looks square on the display 09.10.22 # * pixelma too slow 09.12.45 # Zagor: I don't remember the reason, but there was one. Needs a little digging into history 09.13.06 # i think i can make the math work, as long as i have the actual pixel dimensions. the only issue i sees is the constraints, and i think that pretty much needs to be left up to the plugin developer - it seems more sane to ask them to use a non-square region to get a square image on archos than to ask them to deal with scaled bitmaps on archos actually being larger or smaller than the requested size. 09.13.08 # hmm, it was done by bagder nearly four years ago 09.13.29 Join wjx [0] (n=debc0a28@gateway/web/cgi-irc/labb.contactor.se/x-62c40665727c1d42) 09.14.09 # Unhelpful: Does the scaler keep aspect, or is that something the caller needs to do? 09.14.55 Join ender` [0] (i=krneki@foo.eternallybored.org) 09.14.59 # amiconn: the scaler keeps aspect if the caller asks it to. basically, a flag determines whether the specified rectangle is the desired size of the output, or a constraint for that size. 09.15.35 Join btbr [0] (n=79eb3100@gateway/web/cgi-irc/labb.contactor.se/x-ace27b43411316b6) 09.16.45 # So I don't see the problem. If it is asked to keep aspect, it can take a non-square pixel aspect into account 09.17.20 # And if it's not, there's nothing the scaler can do and the caller needs to handle it 09.17.36 # well, the question is whether the constraining rectangle is in display pixels. i think it pretty much has to be, for things to be sane. 09.18.55 Quit wjx ("CGI:IRC (Ping timeout)") 09.19.12 Join wjx [0] (n=debc0a28@gateway/web/cgi-irc/labb.contactor.se/x-7cac2ebc0f088541) 09.19.29 # I'm in 09.19.55 # say something,Wrong! 09.20.30 # you idiot 09.21.08 # Hey,guys,dit M6 progect alive? 09.21.36 # wpqy? 09.22.50 # the info about ports-in-progress is generally in the wiki or an appropriated forum thread. you should look there instead of asking for status updates here. 09.23.24 # Yes 09.23.28 # especially since developers work on what interests them, and on hardware they actually have... so there may very well be nobody in here who knows anything about a particular device at the moment. 09.23.33 # I know it 09.24.43 # It's a great job for rockbox members 09.25.30 # Your name is so intersting 09.25.37 # "Unhelpful" 09.30.40 Nick Barahir_ is now known as Barahir (n=jonathan@Xa2a3.x.pppool.de) 09.33.38 # hmm... now resizing AA is in, should I remove the AA size in the info screen? 09.34.33 # well, we do still do the check for "prescaled" AA... something else that it might be a good idea to remove, at this point. 09.37.38 # amiconn: as far as I can see the only reason is that we have poor #include control in plugins. this should be fixed. 09.44.10 # I especially "like" that codecs.h have prefix around some of the file functions, but not others. open, but not close etc. 09.44.21 # does anyone know what the difference between gwps.c and gwps-common.c is? 09.47.38 Quit btbr ("CGI:IRC (Ping timeout)") 09.49.20 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 09.50.05 Quit wjx ("CGI:IRC (EOF)") 09.51.47 Quit axionix (Read error: 104 (Connection reset by peer)) 09.53.32 # so, button_get(true) basically no longer works for waiting for a button press... but it looks like it should be enough to check the return value and loop? 09.54.37 # the greylib scaler test plugin needs fixed for this... and i think ppmviewer, as well, since that's what i borrowed the method from. 09.55.07 Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) 09.55.51 # Unhelpful: no.. it was changed back to how it should work... 09.55.58 # so it will block properly again 09.56.00 # oh! i missed that, then :) 09.57.39 # eek. what is the purpose of intptr_t? 09.58.04 # Zagor: it's an integer the same size as a pointer. 09.58.06 # 64bit builds... 09.58.37 # is using linked lists much slower than a simple array? 09.59.03 # I see what it is, but when is it needed? 09.59.04 # JdGordon: depends on the operation being performed. 09.59.37 # Zagor: when you need to do operations other than simple addition/subtraction on pointers, or at least that's the main use i know of 09.59.54 Quit bertrik ("Leaving") 09.59.55 # Unhelpful: replacing a for loop with lots in the middle with a LL 10.00.04 # iterating a LL is going to be pretty fast. 10.01.01 # insert/delete are of course much faster than an array. looking up an arbitrary value is much slower, and you'll probably want some more advanced structure instead of a "pure" LL 10.02.12 # not really... it would only be used with iterating and searching (one direction), adding will always be at the end... the reason would be to use that instead of a static array so the count isnt limited 10.02.15 # "insert/delete are of course much faster than an array" how that? 10.02.35 # kugel: if you need to insert in the middle 10.02.41 # fixing pointers instead of memcpy/memcpy 10.02.48 # kugel: if you insert, not merely modify, a value in the middle of an array, you have to move the other values. 10.03.47 # in a LL, you just make a new node, change the next pointer for the node it's being inserted after, and set its next pointer to the node that belongs after it. 10.04.23 Join Bagderr [0] (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-c0e92795660a57fb) 10.04.50 # JdGordon: if you're never doing inserts in the middle, why not an array that you expand the allocation of? dynamic size is going to require *some* kind of dynamic allocation... 10.05.36 # why is queue_event using intptr_t rather than long for data? surely not many systems have a smaller long than int* 10.06.01 # it seems this is the cause of most other uses of intptr_t 10.06.14 # is intptr_t causing problems? 10.06.34 # new types are bad 10.07.17 # Unhelpful: thinking about mem mamangement in the wps... considering using a LL for the tokens instead of a static buffer... its size is unknown at the start so a LL makes sense.. but im thinking maybe its not worth the effort 10.07.49 # and besides, yes it does cause problems since files need to be included for its' use. 10.08.13 # and that causes #include ballooning 10.08.15 # i guess i'm just saying, if you can allocate space for new LL nodes, you can allocate space for a larger array. and the array will use less memory. 10.09.25 # r11818 jhmikes. "Convert queues to use intptr_t for event data and return values as most of the time pointer are not passed and it should make some things a bit cleaner." 10.09.38 # is it too late to say "I disagree?" ;-) 10.10.39 # I agree void* was not ideal. but long would be better than a new type. 10.11.14 # would a simple intptr_t -> long patch work with 64bit sims? 10.11.25 # and by work, i mean not cause annoying warnings 10.11.48 # JdGordon: since everything is casted to intptr_t today, I would think so 10.12.13 Nick Bagderr is now known as B4gder (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-c0e92795660a57fb) 10.22.50 # Unhelpful: oh yea, I wasn't thinking of inserting in the middle (I had queue in mind) 10.31.00 Quit Thundercloud (Remote closed the connection) 10.31.16 Quit XavierGr () 10.31.44 Quit GodEater_ ("http://www.mibbit.com ajax IRC Client") 10.33.20 Quit kachna (Read error: 113 (No route to host)) 10.34.05 Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) 10.36.45 # ok, API is gone :) 10.37.00 # Unhelpful: sim prefix removal patch coming up soon 10.37.34 # ok, i've got other things to do here, so i'll hold on to this cleanup for now 10.41.55 # where shold the .map be? I cant seem to find it 10.43.54 # JdGordon: for the core bin? it should be in the same dir as .bin and .elf 10.44.06 # i.e. the root 10.44.27 # is it not generated for the sim maybe? 10.44.34 # an, no 10.44.48 # ok 10.50.40 *** Saving seen data "./dancer.seen" 10.54.25 # if the wps is the while playing screen... what should the actual drawing code be called? theme_engine or something? 10.55.02 # or keep that as wps and use now_playing or something for the actual screen logic 11.05.41 # have you all forgotten the name is the most important part???! 11.06.24 # wps is rivaling playback for hot-potato-ness :-) 11.08.04 # I suppose if the drawing code is used globally, something with "theme" would be appropriate 11.09.15 # I'd prefer still calling the actual screen wps as the S is for screen 11.09.29 # Zagor: Why remove the prefixes? The method is proven to be reliable 11.09.52 # amiconn: reliable? why should the code become less reliable without the prefix? 11.10.33 # I removed them because they don't belong there. the prefix is a simulator implementation issue, not an plugin api issue. 11.11.36 # as it was, it had even infected the implementation of plugins 11.12.53 # B4gder: who runs the obo.gotdns.org build server? it is throwing odd warnings: "htobe16" redefined 11.12.56 # No, but open is mapped to sim_open by a macro for the sims, and depending on how you write the rb->open call, it may or may not get replaced by sim_open, depending on what headers are (recursively) included 11.13.08 # amiconn: not any more 11.13.14 # * scorche assumes obo 11.13.18 # I remember having run into this issue in the past. Just having the prefix everywhere avoids it. 11.13.24 # * B4gder hands scorche 10 points 11.14.17 # amiconn: that was a kludge. my commit is a fix. 11.14.21 # oh um, could I bug someone to sponsor a commit on FS #9647 ? 11.16.43 # lucent: rasher has grabbed it. bug him :-) 11.16.54 # when i open and close a menu in a plugin, the screen gets offset downward by the size of the status bar (even after redraws). is that known about, or should i add a bug or something? 11.17.34 # Zagor: his last comment on the task was a question about freeze 11.17.39 # I don't know the answer 11.17.41 # do you? 11.18.03 # lucent: well the freeze is over ... 11.18.12 Join merbzt [0] (n=benlar@193.13.246.198) 11.18.17 Quit kugel (Remote closed the connection) 11.18.52 # kadoban: what revision nummber? I hopefully fix that one 11.19.29 # JdGordon: one today. i think it was 19702. i can check in the most recent one 11.19.46 # check the most recent 11.19.51 # i tihnk my last commit fixed that 11.20.03 # JdGordon: oh nice, i'll check then 11.20.55 Quit plus_M (Remote closed the connection) 11.21.12 # rasher: ping w/re FS#9647 11.21.50 Quit blithe (Remote closed the connection) 11.22.18 Join plus_M [0] (i=plus@li26-205.members.linode.com) 11.26.24 Join PaulJam [0] (i=PaulJam_@vpn-3087.gwdg.de) 11.27.03 Join blithe [0] (n=blithe@stiletto.djblithe.com) 11.27.13 # JdGordon: yeah, it does seem to be fixed in the most recent. good job :) 11.31.05 Join kachna [0] (n=kachna@r3g248.net.upc.cz) 11.32.20 # hi, are there any known problems when compiling the uisim under cygwin? i get some warnings (warning: -ffunction-sectio 11.32.20 # ns may affect debugging on some targets) and when it compiles doom some errors. (i did make veryclean and ran configure before compiling.) 11.40.39 Join culture [0] (n=none@cpc2-bele3-0-0-cust89.belf.cable.ntl.com) 11.52.40 Join flydutch [0] (n=flydutch@host159-157-dynamic.1-79-r.retail.telecomitalia.it) 11.56.41 # Zagor: that box is running libc6-dev v 2.9 - I don't know yet if that change is from upstream or a distro patch (kubuntu) 11.58.25 Join moos [0] (i=Mustapha@rockbox/staff/moos) 12.00.27 # Zagor: How is intptr_t a new type? It was there from the start, isn't exactly an obscure one and ensures it's correct for integral and pointer data. 12.02.49 Join kugel [0] (n=chatzill@unaffiliated/kugel) 12.09.14 # jhMikeS: what does it do that a long doesn't? 12.14.47 # As long as long can always fit a pointer in every case, nothing. Otherwise it's trouble for sure. 12.16.13 Quit JdGordon (Remote closed the connection) 12.16.18 # as I said earlier, I know of no systems where sizeof(int*) > sizeof(long) 12.17.11 # sure, it's part of C99. but I dislike the use if it for the same reason I dislike using uint32_t where it isn't strictly necessary 12.17.48 # win64 does have 32bit longs but 64bit pointers... 12.17.55 # Actually, in Windows 64-bit a pointer is bigger than a long 12.18.07 # * jhMikeS got beaten 12.18.22 # windows saves the day again... :-) 12.18.35 # ok, I give in 12.19.42 # how do you declare a "system" int on win64? 12.19.55 # long long? 12.20.05 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 12.20.26 # a "system" int is still int, isn't it? 12.20.28 # (U)LONG_PTR 12.20.29 Join MTee [0] (n=mtee@41.236.177.63) 12.20.54 # B4gder: so int is larger than long? isn't that forbidden? 12.20.56 Join JdGordon_ [0] (n=jonno@rockbox/developer/JdGordon) 12.21.18 # Zagor: no int is 32 bit 12.21.20 # Hi all 12.21.26 # but so it is on most *nixes on 64bit as well 12.21.52 # I don't get what you mean with "system" int 12.21.53 Quit JdGordon_ (Client Quit) 12.21.56 # B4gder: i believe he means, how do you declare a 64 bit integer? long long should work, right? 12.22.12 # B4gder: I mean register width 12.22.13 # yes, long long should work afaik 12.22.52 # they use the type jhMikeS mentioned 12.23.00 # they as in Microsoft 12.23.16 # "The _PTR suffix means that the integer has the same size as a native pointer." 12.23.54 # that seems odd. if i saw those, i'd assume they were actual pointers 12.24.15 # I agree, it's a weird name 12.24.37 # in microsoft land, the type is shown in the variable name rather than the type name ;-) 12.24.57 # oh yeah, i forgot. hungarian notation...that stuff sucks 12.24.58 # * Zagor wanders off to #rockbox-community 12.25.25 Join BdN3504 [0] (n=55b23f9e@gateway/web/cgi-irc/labb.contactor.se/x-41aa9ab9a1574404) 12.26.25 Quit JdGordon (Remote closed the connection) 12.27.57 Quit gevaerts (Nick collision from services.) 12.28.12 Quit fyrestorm (niven.freenode.net irc.freenode.net) 12.28.12 NSplit niven.freenode.net irc.freenode.net 12.28.12 Quit Darksair (niven.freenode.net irc.freenode.net) 12.28.12 Quit jeffronius (niven.freenode.net irc.freenode.net) 12.28.12 Quit Anges (niven.freenode.net irc.freenode.net) 12.28.12 Quit sbhsu (niven.freenode.net irc.freenode.net) 12.28.12 Quit sarixe (niven.freenode.net irc.freenode.net) 12.28.12 Quit GodEater (niven.freenode.net irc.freenode.net) 12.28.12 Quit rasher (niven.freenode.net irc.freenode.net) 12.28.12 Quit PaulJam (niven.freenode.net irc.freenode.net) 12.28.12 Quit markun (niven.freenode.net irc.freenode.net) 12.28.12 Quit SUSaiyan (niven.freenode.net irc.freenode.net) 12.28.12 Quit crashd (niven.freenode.net irc.freenode.net) 12.28.12 Quit ch4os (niven.freenode.net irc.freenode.net) 12.28.12 Quit goffa (niven.freenode.net irc.freenode.net) 12.28.12 Quit courtc (niven.freenode.net irc.freenode.net) 12.28.12 Quit larstobi (niven.freenode.net irc.freenode.net) 12.28.12 Quit GodEater_ (niven.freenode.net irc.freenode.net) 12.28.12 Quit AndyI (niven.freenode.net irc.freenode.net) 12.28.12 Quit japc (niven.freenode.net irc.freenode.net) 12.28.12 Quit scorche (niven.freenode.net irc.freenode.net) 12.28.12 Quit CaptainKwel (niven.freenode.net irc.freenode.net) 12.28.12 Quit jon-kha (niven.freenode.net irc.freenode.net) 12.28.12 Quit Slasheri (niven.freenode.net irc.freenode.net) 12.28.12 Quit desowin_ (niven.freenode.net irc.freenode.net) 12.28.12 Quit J-23 (niven.freenode.net irc.freenode.net) 12.28.12 Quit parafin (niven.freenode.net irc.freenode.net) 12.28.12 Quit freqmod_qu (niven.freenode.net irc.freenode.net) 12.28.12 Quit BdN3504 (niven.freenode.net irc.freenode.net) 12.28.12 Quit pixelma (niven.freenode.net irc.freenode.net) 12.28.12 Quit amiconn (niven.freenode.net irc.freenode.net) 12.28.12 Quit n17ikh|Lappy (niven.freenode.net irc.freenode.net) 12.28.12 Quit Bagder (niven.freenode.net irc.freenode.net) 12.28.12 Quit amigan_ (niven.freenode.net irc.freenode.net) 12.28.12 Quit write__erase (niven.freenode.net irc.freenode.net) 12.28.12 Quit unstable (niven.freenode.net irc.freenode.net) 12.28.12 Quit crwl (niven.freenode.net irc.freenode.net) 12.28.12 Quit lastebil (niven.freenode.net irc.freenode.net) 12.28.12 Quit Hadaka (niven.freenode.net irc.freenode.net) 12.28.12 Quit BlakeJohnson86 (niven.freenode.net irc.freenode.net) 12.28.12 Quit moos (niven.freenode.net irc.freenode.net) 12.28.12 Quit culture (niven.freenode.net irc.freenode.net) 12.28.12 Quit jhMikeS (niven.freenode.net irc.freenode.net) 12.28.12 Quit trisiak (niven.freenode.net irc.freenode.net) 12.28.12 Quit thegeek (niven.freenode.net irc.freenode.net) 12.28.12 Quit flux (niven.freenode.net irc.freenode.net) 12.28.12 Quit loswillios (niven.freenode.net irc.freenode.net) 12.28.12 Quit fred_2 (niven.freenode.net irc.freenode.net) 12.28.12 Quit pabs (niven.freenode.net irc.freenode.net) 12.28.12 Quit soap (niven.freenode.net irc.freenode.net) 12.28.12 Quit Neovanglist (niven.freenode.net irc.freenode.net) 12.28.12 Quit TMM (niven.freenode.net irc.freenode.net) 12.28.12 Quit reacocard (niven.freenode.net irc.freenode.net) 12.28.12 Quit timc (niven.freenode.net irc.freenode.net) 12.28.12 Quit midkay (niven.freenode.net irc.freenode.net) 12.28.12 Quit obo (niven.freenode.net irc.freenode.net) 12.28.12 Quit Beta2K (niven.freenode.net irc.freenode.net) 12.28.12 Quit merbzt (niven.freenode.net irc.freenode.net) 12.28.12 Quit Zagor (niven.freenode.net irc.freenode.net) 12.28.12 Quit Rob2222 (niven.freenode.net irc.freenode.net) 12.28.12 Quit jfc (niven.freenode.net irc.freenode.net) 12.28.12 Quit blkhawk (niven.freenode.net irc.freenode.net) 12.28.26 Quit HBK (niven.freenode.net irc.freenode.net) 12.28.26 Quit HellDragon (niven.freenode.net irc.freenode.net) 12.28.26 Quit linuxstb (niven.freenode.net irc.freenode.net) 12.28.26 Quit alexbobp (niven.freenode.net irc.freenode.net) 12.28.26 Quit feisar (niven.freenode.net irc.freenode.net) 12.28.26 Quit plus_M (niven.freenode.net irc.freenode.net) 12.28.26 Quit axionix (niven.freenode.net irc.freenode.net) 12.28.26 Quit ender` (niven.freenode.net irc.freenode.net) 12.28.26 Quit Acksaw (niven.freenode.net irc.freenode.net) 12.28.26 Quit kerwood (niven.freenode.net irc.freenode.net) 12.28.26 Quit ajb` (niven.freenode.net irc.freenode.net) 12.28.26 Quit dionoea (niven.freenode.net irc.freenode.net) 12.28.26 Quit martian67 (niven.freenode.net irc.freenode.net) 12.28.26 Quit Unhelpful (niven.freenode.net irc.freenode.net) 12.28.26 Quit synergist (niven.freenode.net irc.freenode.net) 12.28.26 Quit balou (niven.freenode.net irc.freenode.net) 12.28.26 Quit suom1 (niven.freenode.net irc.freenode.net) 12.28.26 Quit LinusN (niven.freenode.net irc.freenode.net) 12.28.26 Quit lostlogic (niven.freenode.net irc.freenode.net) 12.28.26 Quit liiwi (niven.freenode.net irc.freenode.net) 12.28.26 Quit Dieterbe (niven.freenode.net irc.freenode.net) 12.28.26 Quit shodanX (niven.freenode.net irc.freenode.net) 12.28.26 Quit preglow (niven.freenode.net irc.freenode.net) 12.28.26 Quit DaCapn (niven.freenode.net irc.freenode.net) 12.28.26 Quit Zambezi (niven.freenode.net irc.freenode.net) 12.28.26 Quit tim__b (niven.freenode.net irc.freenode.net) 12.28.26 Quit Kopfgeldjaeger (niven.freenode.net irc.freenode.net) 12.28.26 Quit Tuplanolla (niven.freenode.net irc.freenode.net) 12.28.26 Quit agaffney (niven.freenode.net irc.freenode.net) 12.28.26 Quit kachna (niven.freenode.net irc.freenode.net) 12.28.26 Quit advcomp2019 (niven.freenode.net irc.freenode.net) 12.28.26 Quit Lss (niven.freenode.net irc.freenode.net) 12.28.26 Quit lucent (niven.freenode.net irc.freenode.net) 12.28.26 Quit esthar (niven.freenode.net irc.freenode.net) 12.28.26 Quit DataGhost (niven.freenode.net irc.freenode.net) 12.28.26 Quit B4gder (niven.freenode.net irc.freenode.net) 12.28.26 Quit Xerion (niven.freenode.net irc.freenode.net) 12.28.26 Quit shadearg (niven.freenode.net irc.freenode.net) 12.28.26 Quit avacore (niven.freenode.net irc.freenode.net) 12.28.26 Quit ChanServ (niven.freenode.net irc.freenode.net) 12.28.26 Quit Barahir (niven.freenode.net irc.freenode.net) 12.28.26 Quit Bensawsome (niven.freenode.net irc.freenode.net) 12.28.26 Quit gromit`` (niven.freenode.net irc.freenode.net) 12.28.26 Quit troy___ (niven.freenode.net irc.freenode.net) 12.28.26 Quit scorche|sh (niven.freenode.net irc.freenode.net) 12.28.26 Quit tchan (niven.freenode.net irc.freenode.net) 12.28.26 Quit fxb__ (niven.freenode.net irc.freenode.net) 12.28.26 Quit killan (niven.freenode.net irc.freenode.net) 12.28.26 Quit Galois (niven.freenode.net irc.freenode.net) 12.28.26 Quit romain (niven.freenode.net irc.freenode.net) 12.28.26 Quit offset (niven.freenode.net irc.freenode.net) 12.28.26 Quit hobbs (niven.freenode.net irc.freenode.net) 12.28.26 Quit flydutch (niven.freenode.net irc.freenode.net) 12.28.26 Quit kadoban (niven.freenode.net irc.freenode.net) 12.28.26 Quit Slack_ (niven.freenode.net irc.freenode.net) 12.28.26 Quit yosafbridge (niven.freenode.net irc.freenode.net) 12.28.26 Quit Llorean (niven.freenode.net irc.freenode.net) 12.28.26 Quit krazykit (niven.freenode.net irc.freenode.net) 12.28.27 Quit tmzt (niven.freenode.net irc.freenode.net) 12.28.27 Quit Tristan (niven.freenode.net irc.freenode.net) 12.30.12 NHeal niven.freenode.net irc.freenode.net 12.30.12 NJoin ChanServ [0] (ChanServ@services.) 12.30.12 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 12.30.12 NJoin BdN3504 [0] (n=55b23f9e@gateway/web/cgi-irc/labb.contactor.se/x-41aa9ab9a1574404) 12.30.12 NJoin moos [0] (i=Mustapha@rockbox/staff/moos) 12.30.12 NJoin flydutch [0] (n=flydutch@host159-157-dynamic.1-79-r.retail.telecomitalia.it) 12.30.12 NJoin culture [0] (n=none@cpc2-bele3-0-0-cust89.belf.cable.ntl.com) 12.30.12 NJoin kachna [0] (n=kachna@r3g248.net.upc.cz) 12.30.12 NJoin PaulJam [0] (i=PaulJam_@vpn-3087.gwdg.de) 12.30.12 NJoin plus_M [0] (i=plus@li26-205.members.linode.com) 12.30.12 NJoin merbzt [0] (n=benlar@193.13.246.198) 12.30.12 NJoin GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) 12.30.12 NJoin B4gder [0] (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-c0e92795660a57fb) 12.30.12 NJoin axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) 12.30.12 NJoin ender` [0] (i=krneki@foo.eternallybored.org) 12.30.12 NJoin Anges [0] (n=agnes@lns-bzn-49f-62-147-173-3.adsl.proxad.net) 12.30.12 Join pixelma [0] (n=pixelma@rockbox/staff/pixelma) 12.30.12 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 12.30.12 NJoin timc [0] (n=aoeu@124.93.243.83) 12.30.12 NJoin Zagor [0] (n=bjorn@rockbox/developer/Zagor) 12.30.12 NJoin Rob2222 [0] (n=Miranda@p4FDCE3B5.dip.t-dialin.net) 12.30.12 NJoin Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 12.30.12 NJoin kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 12.30.12 NJoin midkay [0] (n=midkay@rockbox/developer/midkay) 12.30.12 NJoin amiconn [50] (n=jens@rockbox/developer/amiconn) 12.30.12 NJoin fyrestorm [0] (n=fyre@cpe-68-173-235-77.nyc.res.rr.com) 12.30.12 NJoin jfc [0] (n=john@dpc691978010.direcpc.com) 12.30.12 NJoin AndyI [0] (i=AndyI@212.14.205.32) 12.30.12 NJoin advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 12.30.12 NJoin sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 12.30.12 NJoin Barahir [0] (n=jonathan@Xa2a3.x.pppool.de) 12.30.12 NJoin blkhawk [0] (n=blkhawk@g226131166.adsl.alicedsl.de) 12.30.12 NJoin Darksair [0] (n=user@125.33.197.248) 12.30.12 NJoin n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) 12.30.12 NJoin jeffronius [0] (n=kvirc@69.12.221.210) 12.30.12 NJoin Lss [0] (n=Lss@cm97.delta89.maxonline.com.sg) 12.30.12 NJoin japc [0] (n=japc@bl7-247-89.dsl.telepac.pt) 12.30.12 NJoin jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 12.30.12 NJoin Slack_ [0] (n=brett@12-218-63-169.client.mchsi.com) 12.30.12 NJoin parafin [0] (i=parafin@paraf.in) 12.30.12 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) 12.30.12 NJoin Bagder [241] (n=daniel@rockbox/developer/bagder) 12.30.12 NJoin markun [50] (n=markun@rockbox/developer/markun) 12.30.12 NJoin scorche [0] (i=Blah@rockbox/administrator/scorche) 12.30.12 NJoin lucent [0] (i=lucent@silenceisdefeat.com) 12.30.12 NJoin kerwood [0] (n=Marshall@c-69-250-35-141.hsd1.md.comcast.net) 12.30.12 NJoin gromit`` [0] (n=gromit@ALagny-154-1-54-214.w81-249.abo.wanadoo.fr) 12.30.12 NJoin CaptainKwel [0] (n=jason@cpe-68-173-40-122.nyc.res.rr.com) 12.30.12 NJoin yosafbridge [0] (n=yosafbri@ludios.net) 12.30.12 Mode "#rockbox +o ChanServ " by irc.freenode.net 12.30.12 NJoin troy___ [0] (n=toppy@78.147.197.163) 12.30.12 NJoin esthar [0] (n=esthar@student165-92.hampshire.edu) 12.30.12 NJoin sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) 12.30.12 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 12.30.12 NJoin HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 12.30.12 NJoin GodEater [0] (n=ge@rockbox/staff/GodEater) 12.30.12 NJoin agaffney [0] (n=agaffney@gentoo/developer/agaffney) 12.30.12 NJoin Neovanglist [0] (i=Neovangl@69.31.129.33) 12.30.12 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 12.30.12 NJoin larstobi [0] (n=larstobi@195.139.173.50) 12.30.12 NJoin desowin_ [0] (n=desowin@72.37.225.164) 12.30.12 NJoin fred_2 [0] (i=fred@hpc-cluster.hamburgnet.de) 12.30.12 NJoin lastebil [0] (n=truck@cube.lomal.la) 12.30.12 NJoin flux [0] (i=flux@jolt.modeemi.cs.tut.fi) 12.30.12 NJoin crashd [0] (i=foobar@lostnode.org) 12.30.12 NJoin amigan_ [0] (i=dcp1990@ip68-226-92-253.ri.ri.cox.net) 12.30.12 NJoin freqmod_qu [0] (i=quassel@2001:700:300:1430:213:d3ff:fee9:5ed0) 12.30.12 NJoin rasher [50] (n=rasher@rockbox/developer/rasher) 12.30.12 NJoin courtc [0] (n=court@unaffiliated/courtc) 12.30.12 NJoin trisiak [0] (n=tree@chello089078243195.chello.pl) 12.30.12 NJoin loswillios [0] (n=jan@unaffiliated/loswillios) 12.30.12 NJoin Hadaka [0] (i=naked@naked.iki.fi) 12.30.12 NJoin pabs [0] (n=pabs@xor.pablotron.org) 12.30.12 NJoin goffa [0] (n=goffa@216.220.23.105) 12.30.12 NJoin BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 12.30.12 NJoin reacocard [0] (i=reacocar@66.111.62.173) 12.30.12 NJoin ch4os [0] (n=ch4os@gentoo/user/ch4os) 12.30.12 NJoin write__erase [0] (n=write__e@royale.aixmarseille.com) 12.30.12 NJoin soap [50] (n=soap@rockbox/staff/soap) 12.30.12 NJoin J-23 [0] (n=zelazko@unix.net.pl) 12.30.12 NJoin thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 12.30.12 NJoin unstable [0] (i=unstable@tor/regular/sid) 12.30.12 NJoin SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) 12.30.12 NJoin TMM [0] (n=hp@5ED10264.cable.ziggo.nl) 12.30.12 NJoin crwl [0] (n=crawlie@a91-154-18-71.elisa-laajakaista.fi) 12.30.12 NJoin DataGhost [0] (i=dataghos@unaffiliated/dataghost) 12.30.12 NJoin ajb` [0] (n=user@cpc2-cmbg5-0-0-cust252.cmbg.cable.ntl.com) 12.30.12 Join obo [0] (n=obo@rockbox/developer/obo) 12.30.12 Join Llorean [0] (n=DarkkOne@rockbox/administrator/Llorean) 12.30.12 Join HellDragon [0] (n=jd@Wikipedia/HellDragon) 12.30.12 NJoin krazykit [0] (n=kkit@adsl-76-240-198-230.dsl.ipltin.sbcglobal.net) 12.30.12 NJoin Beta2K [0] (n=beta@d36-78-228.home1.cgocable.net) 12.30.12 NJoin Dieterbe [0] (n=Dieterbe@213.219.168.87.adsl.dyn.edpnet.net) 12.30.12 Join dionoea [0] (n=dionoea@videolan/developer/dionoea) 12.30.12 NJoin tmzt [0] (n=tmzt@76.211.12.137) 12.30.12 NJoin Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 12.30.12 NJoin martian67 [0] (i=lol3izer@about/linux/regular/martian67) 12.30.12 NJoin scorche|sh [50] (n=scorche@rockbox/administrator/scorche) 12.30.12 NJoin alexbobp [0] (n=alex@69.149.25.200) 12.30.12 NJoin feisar [0] (i=jljhook@tarjoo.mulle.olut.gr) 12.30.12 NJoin linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 12.30.12 NJoin Unhelpful [0] (n=Militant@rockbox/developer/Unhelpful) 12.30.12 NJoin synergist [0] (i=christop@cant.be-arsed.co.uk) 12.30.12 NJoin tim__b [0] (i=tim__b@the-ascii-scene.doesntexist.org) 12.30.12 NJoin shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 12.30.12 NJoin DaCapn [0] (i=dacapn@using.your.wireless-inter.net) 12.30.12 NJoin preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) 12.30.12 NJoin liiwi [0] (i=liiwi@idle.fi) 12.30.12 NJoin lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) 12.30.12 NJoin Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 12.30.12 NJoin balou [0] (i=balou@cl-1844.ham-01.de.sixxs.net) 12.30.12 NJoin suom1 [0] (i=markus@2001:4c40:1:0:0:0:0:11) 12.30.12 NJoin Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 12.30.12 NJoin Zambezi [0] (i=stolgfor@bnc.fran.dotbnc.se) 12.30.12 NJoin shadearg [0] (i=arg@ipv4.panoptix.net) 12.30.12 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 12.30.12 NJoin offset [0] (n=zero@ool-44c0032d.dyn.optonline.net) 12.30.12 NJoin avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 12.30.12 NJoin fxb__ [0] (n=felixbru@h1252615.stratoserver.net) 12.30.12 NJoin killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) 12.30.12 NJoin Galois [0] (i=djao@efnet-math.org) 12.30.12 NJoin romain [0] (n=romain@peerfuse.org) 12.30.12 NJoin Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 12.30.12 NJoin hobbs [0] (n=nandrew@p3m/member/hobbs) 12.31.05 Quit japc (Read error: 145 (Connection timed out)) 12.31.18 # %mo is not in official Rockbox 12.31.57 Ctcp Version from freenode-connect!freenode@freenode/bot/connect 12.32.01 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 12.33.45 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.34.13 Quit JdGordon (Client Quit) 12.35.23 Join JdGordon [0] (n=jonno@123-243-140-31.static.tpgi.com.au) 12.39.34 Quit JdGordon (Remote closed the connection) 12.40.58 # hm, ok then i'll just use the %mv tag... 12.41.00 Join JdGordon [0] (n=Miranda@123-243-140-31.static.tpgi.com.au) 12.43.06 # Ok, it seems the m4a crash address I'm seeing is in mad_main_data. Any ideas why? 12.43.43 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 12.43.52 # 8 bytes into it to be precise 12.46.09 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 12.48.22 # ajb`: stack corruption? 12.49.51 # I assume init_mad is the entry point of the codec when an m4a gets queded up to play 12.50.44 *** Saving seen data "./dancer.seen" 12.50.47 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.53.29 # ajb`: no, codec_main is the entry. init_mad() is called from there. 12.54.29 # * ajb` tests the stack corruption theory 12.55.12 # the ipod video is a duel core machine right? Core 0 being menu core 1 decode? 12.59.15 # Well adding 128 bytes of space into IBSS moved the undefined instruction up 128 bytes which would seem to confirm the stack corruption idea 12.59.54 # init_mad sounds like a function in a codec that isn't used at all for m4a 13.00.34 # hmm 13.01.25 # I think you checked the wrong .map 13.01.47 # actually I take that back, the crash address has moved but the map makes the address somewhere different 13.02.01 # 40018928 is in: 13.02.03 # .ibss 0x0000000040018924 0x4 /home/alex/src/rockbox/ipod.build/apps/codecs/libmad.a(synth_full_arm.o) 13.02.03 # 0x0000000040018928 . = ALIGN (0x4) 13.02.03 # 0x0000000040018928 iend = . 13.02.06 # 13.03.16 Quit JdGordon (Read error: 54 (Connection reset by peer)) 13.04.25 # ajb`: shouldn't you rather be looking in aac.map? 13.04.43 # can someone please move the new rbutil mac build from http://jdgordon.info/~domonoky/rbutilqt-v1.0.9.dmg to the download server ? 13.05.19 # Zagor: I looked for maps that contained the address and that's what it pointed to... 13.05.24 # * ajb` tries v3 13.05.53 # ajb`: all codec maps use the same addresses. but only symbol start addresses are listed. 13.05.57 Join herefornow [0] (n=45df5a8b@gateway/web/cgi-irc/labb.contactor.se/x-fee54735897c7a7d) 13.06.50 # Ok so this crash is 40017fA4 13.07.37 # Doing a grep of the .maps for 40017 gives me: 13.07.59 # ajb`: you can't grep. all codecs use the same memory. 13.08.06 # mpa.map, flac.map (not that) and packbox.map (no idea what that is) 13.08.21 # Zagor: ahh, I misunderstood 13.08.41 # you simply have to look in the .map of the codec you are running. 13.08.45 # Zagor: So to translate from the reported address to where in the codec I do what? 13.08.56 # For m4a that will be? 13.09.03 Quit herefornow (Client Quit) 13.10.18 # aac.map 13.11.13 # Zagor: The end of aac.map is: 13.11.19 # 0x0000000040016818 iend = . 13.11.19 # 13.12.15 # the ibss section of filtbank.c 13.12.17 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 13.12.34 # what does the crash message say? 13.12.46 Join tvelocity [0] (n=tony@adsl1-102.her.forthnet.gr) 13.13.01 # Undefined Instruction at 40017FA4 (0) 13.13.32 # (see FS #9745 for other crashes) 13.14.37 # you've established that there is no code there so that crash message is to be expected. now the question is why does it call there. 13.14.51 # I notice is crashes before the mp3 before it finishes. I assume the mp3 codec is out of the way by this point? 13.14.57 # indeed 13.15.05 # see if the sim crashes too 13.15.15 # Zagor: it doesn't 13.15.34 # I could really do with a backtrace on the device! 13.15.36 # * ajb` wishes 13.15.42 # then it's time to explore logf over usb-serial :-) 13.17.06 # there's a huge karma bonus to be collected for he who creates a gdb stub for usb-over-serial. nudge nudge ;-) 13.17.36 # Zagor: any pointers? 13.18.39 # Currently pluging in USB resets the ipod to flash firmware 13.18.48 # ajb`: Just a question, as I've just dropped in. Are you using an up-to-date bootloader? 13.18.56 Join n1s [0] (n=nils@rockbox/developer/n1s) 13.19.09 # could the crash be in metadata? (just a suggestion...) 13.19.31 Quit MTee ("Java user signed off") 13.19.44 # I seem to recall addresses like that showing up with using recent builds and older bootloaders on PP targets. 13.20.16 # Llorean: define upto date? I haven't touched the bootcode since rbutil set up rockbox for me about a month or so ago 13.21.23 # ajb`: That ought to be up to date. And it's just "the bootloader". Using other terms can cause confusion if you talk with other people about it. 13.22.23 # Llorean: noted. 13.22.38 # Llorean: can I check easily? 13.22.52 # The boot partition is special and hidden isn't it? 13.22.52 # ajb`: if you're interested in getting your paws muddy, http://sourceware.org/rda/ is one place to start digging 13.23.46 # there's something at http://sourceforge.net/projects/gdbstubs too. I haven't checked the status of either, other than seen that both are rather old. 13.23.50 # Zagor: do we already have working serial for the USB on iPod or does that need doing as well? 13.24.09 # linuxstb: can you tell me more about the something still not right re. beast svg/pdf? Does it "only" not look right or did you have some other trouble? I'm just curious because I could imagine two possible problems and just want to know which thing is the most important to avoid... 13.24.22 # ajb`: you'd need a bootloader from over a year ago for it to be the problem I was thinking of. 13.24.25 Join TheSphinX^ [0] (n=cold@p54A5DF6E.dip.t-dialin.net) 13.24.25 # Getting logging first might be preferable to a full GDB stub for this bug 13.24.42 # ajb`: we have usb-serial working. I'm not sure what the status is on ipod specifically. 13.24.51 # ajb`: Does the same thing happen if you use our precompiled builds? 13.25.01 # It's very strange that you're the only person experiencing this, even with the same files. 13.25.20 # pixelma: what do you think about adding reset holes and battery switches to the labels in the target images in the manual? 13.25.26 # Llorean: not had the ipod that long :-) So I guess that's out. FWIW I did have working m4a's when I first tested the my other halfs un-DRMed iTunes music. It has broken since 13.25.37 # * ajb` considers a straight bisect 13.26.44 # n1s: wouldn't be very hard and could be helpful for the Gigabeat F/X installation instructions, I think 13.27.02 # maybe there are other things like that 13.27.02 # ajb`: http://www.rockbox.org/twiki/bin/view/Main/PortalPlayerUsb 13.27.04 Quit AndyI (Read error: 145 (Connection timed out)) 13.27.15 Join AndyI [0] (i=AndyI@212.14.205.32) 13.27.27 # pixelma: many iriver users have never seen the hole until someone tells them about it :) 13.28.54 # there's even a reset hole on the Iaudios but it also has a hard power off... the only time I saw someone needed to use it was when he was running the OF 13.29.09 # ajb`: About using our precompiled binaries? 13.29.29 Quit thegeek (Read error: 104 (Connection reset by peer)) 13.29.50 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 13.29.51 # n1s: but they shouldn't need to know about it ;\ 13.32.43 # pixelma: right :) 13.32.56 Join JdGordon_ [0] (n=jonno@123-243-140-31.static.tpgi.com.au) 13.33.13 # but for the gigabeast for example the batteryswittch is needed to escape the OF 13.37.34 # Llorean: Not very helpful if I want to keep developing. Besides I'd like to fix the bug for other people :-) 13.37.42 # ajb`: That doesn't answer my question. 13.37.55 Quit bmbl (Read error: 110 (Connection timed out)) 13.38.03 # If the official binary works, there may be no bug other than some quirk of your build environment. 13.38.22 # It will help us determine where to look further. 13.38.25 # Llorean: You mean for testing. Well other people have tried but failed to reproduce on other players. I'll give the official ipod build a go npw 13.38.47 # The very first thing you do when you encounter a bug like that from a self-compiled build is verify whether it's in the one we provide. 13.39.29 # It gives a much better idea of where to look. :) 13.40.34 # Llorean: you're right of course. I'd just gotten so used to working from the src tree! 13.41.51 # n1s: ok, at least adding battery switches for the two Gigabeats would be very useful then 13.42.28 # pixelma: yes, although i see no harm in adding the reset hole either 13.42.41 # gah 13.42.53 # Llorean: Yep, works OK with the official build 13.43.16 # Compiler issue? 13.43.22 # n1s, pixelma: I really think it's probably best to show every button/switch/whatever, also so people don't discover it by chance and wonder what it does. 13.44.15 Quit GodEater (Read error: 60 (Operation timed out)) 13.44.17 # ajb`: that is nasty business, could be just about anything, 13.44.31 # Bad ram for example, or overheating cpu 13.44.37 # ajb`: You used rockboxdev.sh you said, but you also have some stuff around for Palm development which is also ARM? 13.45.16 # Llorean: No palm stuff. Just what I built with rockboxdev 13.45.29 # Llorean: agreed. And it would give me the chance to do the small fix in the M5 graphic I deemed not important enough yet... 13.45.33 # I may build a fresh gcc from scratch and see what that does 13.45.39 # pixelma: Sounds good. 13.47.10 Quit TheSphinX^ ("XChat@Linux") 13.48.35 Quit JdGordon (Read error: 110 (Connection timed out)) 13.49.49 Nick JdGordon_ is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 13.50.41 # I'm off to grab lunch. I may take objdump to this sucker later 13.51.13 # that's the spirit! 13.51.23 # not the lunch part though -) 13.51.32 # * B4gder adds a : 13.56.11 Quit BdN3504 ("CGI:IRC (Ping timeout)") 14.01.39 Quit JdGordon (Remote closed the connection) 14.04.23 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 14.09.21 Quit kugel (Remote closed the connection) 14.17.25 # pixelma: I couldn't get the PDF showing the image at the right size. If I increased the size from what it is now (which is too small), then it would appear cropped. 14.19.02 # Zagor: care to svn up the web site to get my manua.pl update? 14.19.08 # sure 14.19.20 # done 14.19.56 # image messed up... 14.20.45 # Zagor, B4gder: There is still an (almost) empty cell where the gigabeat-s used to be in the current build table - http://build.rockbox.org/ - does something still need to be run there? 14.21.38 Join BdN3504 [0] (n=55b208dc@gateway/web/cgi-irc/labb.contactor.se/x-7b23f7a6ba734367) 14.21.47 # that could be our "mystery target" :-) 14.21.59 # no, the url gives it away 14.22.40 # I'll remove it 14.22.50 # hey i got another question; concerning the buffer for the wps 14.23.02 # linuxstb: hmm, then it's something else than what I thought. How did you create the pdf? 14.23.23 # i don't understand why i get a image too large for buffer error, when i'm using images that are only 39 K in size 14.24.18 # i get this error message from the wps parser: too large for buffer: 74008 14.24.25 # bytes 14.24.54 # * B4gder blames linuxstb's revert... 14.25.14 # I'll fix it 14.25.25 # but the file is only 39k big. it consists of eleven parts, and is loaded using bitmapstrips. 14.26.35 # the funny thing is, i have already created other wps's which use bigger files and the parser doesnot give out an error message with these... i'm using the sansa e200 btw 14.27.10 # Zagor: svn up the rockbox.pm file now and we'll get the rockbox logo where the beast image should be 14.27.12 # B4gder: coud you please move the new rbutil mac build to the download server ? http://jdgordon.info/~domonoky/rbutilqt-v1.0.9.dmg 14.27.40 # B4gder: ok 14.27.50 # does rockbox load uhm, bitmaps which support run length encoding and all that? the file size might not necessarily have much to do with the actual size of the buffer needed for the data, if so 14.28.18 # domonoky: transfer in progress 14.28.19 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-d9f9d5b094d773da) 14.28.19 # BdN3504: is the image wider than the lcd? 14.28.20 Quit ender` (" Python: executable pseudocode. Perl: executable line noise.") 14.28.24 # no 14.28.44 # if i remove other images it works perfectly, only not all of them together 14.29.09 # you're using too many then 14.29.14 # now the beast manual has appeared nicely on the manuals page 14.30.18 # \o/ 14.30.24 # whats up with the M3 manual? just a placeholder? 14.30.41 # B4gder: Is it almost time to break out the good beer and celebrate a new port release? :) 14.30.59 # but i'm only using five images, which total in 92.052 Byte 14.31.09 # JdGordon: I should just remove it from that table until there's something to show... 14.31.43 # LambdaCalculus37: hah, we already did once and then took it back, so we can soon do it a second time! ;-) 14.31.47 # JdGordon: IIRC it had something to do with the fact that the M3 has no LCD on the device itself, just on the remote. I think amiconn or pixelma mentioned it. 14.32.12 # B4gder: Any excuse to have a good beer. :) 14.32.22 # that's the case for M3, but since we have no manual for it, it won't have to be listed on the manuals page 14.32.23 # the LCD is not the issue - the importance of remote and main target buttons is 14.32.44 # pixelma: Ahh, okay. I was a little confused as to what the real issue was. 14.32.48 # possibly it serves to clearly show that there is no manual 14.33.33 # BdN3504: hmm... yeah you're definetly right... the e200 can hold up to 232Kb of images 14.33.51 # you havnt gone over the image count have you? i.e max 56? 14.34.02 # BdN3504: are there images loaded more than once? 14.34.26 # no only once, image count let me see 14.36.59 # i got 23 individual tokens, plus one background image plus the backdrop 14.37.23 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 14.39.20 # pixelma: I used "save as" in inkscape to save as .eps, then "ps2pdf" to convert to pdf. 14.39.56 # BdN3504: background image + backdrop? 14.40.39 # linuxstb: weird, no idea then 14.40.55 # yes, i got an individual backgraound for the wps and a backdrop for the menu 14.41.34 # was the 92K total including that background image? 14.41.53 # yes, but without the backdrop 14.41.54 # hmm... even if its not.. you're still well under 14.42.33 # I thought you were talking about the WPS only. A backdrop in the WPS shouldn't use the image buffer if it's loaded with the %X tag 14.42.36 Quit thegeek (Read error: 104 (Connection reset by peer)) 14.42.37 # 130.852 Bytes with everything 14.42.52 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 14.43.23 Quit CaptainKwel (Remote closed the connection) 14.43.52 # BdN3504: pastebin the output from rockboxui --debugwps 14.43.58 # and the wps 14.44.13 # well, it's been a while since i've done my last wps. back then i always had individual background for the wps and backdrop for the menu. i loaded the background using %X 14.44.32 # how do i pastebin? 14.44.37 # pastebin.com 14.44.54 # BdN3504: Copy your stuff here: http://pastebin.com/ 14.45.05 # Then submit and copy the link it gives you back and paste it here. 14.48.17 # http://pastebin.com/d64610f60 14.48.53 # http://pastebin.com/d6e73ae7d 14.49.02 # first is parser, second wps 14.49.23 # * GodEater_ sees a "Failed to load image" 14.50.39 # that output isnt really verbose enough :/ 14.50.45 *** Saving seen data "./dancer.seen" 14.51.08 # * JdGordon has no idea 14.51.41 Join japc [0] (n=japc@194.65.5.235) 14.51.54 # does it matter if i load a backdrop? do the wps and the menu share the same imagebuffer? 14.52.50 # no 14.53.04 # umm... they might... but thats not the issue 14.54.28 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 14.55.18 # maybe 11 tokens is too much for bitmap strips... or wait, you asked me if one image was larger thatn the screen, right? well the volume image is 638px high... but it's using bitmap strips, so the size used is 58x58. 14.55.46 # the thing i don't get is that when i comment out only one single image, everything works fine... 14.55.50 # the limitation is on the width... it can be taller than the screen.. not wider 14.56.25 # comment out the %xl|F line.. does it work? 14.57.26 # errm, which line? 14.57.39 # the 3rd line of the wps 14.57.48 # %xl|P|pla.bmp|14|18|5| 14.58.10 # but that is used in the %mv tag 14.58.27 # it will fail to load once the %xdP lines.. but if it gets that far its good enough 15.00.27 # http://pastebin.com/d3b1f7b1c 15.01.08 # jhMikeS: the reason i pinged you yesterday was to ask what (if any) effect the battery capacity setting has on charging on the beast to put it in the manual 15.01.33 # 638x58 pixel is quite large already, I mean amount of data wise, almost the same as a complete background image for an e200 15.01.33 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-9bdb81d337da7a0f) 15.02.22 # so shall i try reducing the size.... which dimensions would be reasonable ? 15.02.35 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 15.02.41 # BdN3504: also make sure you save them as 16 bit and not 24 bit bmps 15.03.24 # kk 15.03.49 # n1s: that isn't really needed, it would only reduce the space that's needed on the disk 15.03.57 # erm they are already 8 bit 15.04.04 # (or flash memory) 15.05.52 # pixelma: oh, it buffers as 16 in any case? 15.06.36 # thought so 15.08.05 # thinking about it that makes good sense so i think you are right :) 15.08.43 Quit Zambezi (Remote closed the connection) 15.10.29 # this might take a little while 15.10.49 # so if the image is 8bit, the size you stated won't be the real size it needs to buffer. I'm slowly getting confused though, thinking of mono images (I believe they are an exception but), maybe someone else who is more confident in this should answer... 15.11.32 # BdN3504: convert that image up to 16bit... see how big it is then 15.11.50 # I'm assuming that its stored as 16bit in rockbox anyway 15.12.56 # it should be double the size, no? 15.13.29 # s/double/twice 15.14.52 # well it was 39k but i already deleted it 15.14.57 Quit sarixe ("Connection reset by the motherfucking peer") 15.15.02 # i got an image that works now 15.15.14 # but it only uses six tokens 15.15.28 # so the animation doesn't look that smooth anymore... 15.16.07 # and the funny thing is, the image is also 40.424 Bytes in size 15.16.13 # i don't get it 15.16.23 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 15.17.01 # it's not the filesize that's important but rather how much memory it needs to buffer, and apparently any (colour?) bmp is buffered as 16 bit 15.20.06 # i don't understand how one file with approximately the same size and colour depths works and the other does not 15.22.00 # are you going by file size or width * height * color depth? 15.23.35 # one was 58*638 the other 58*348 15.24.46 Join Schmogel [0] (n=Miranda@essn-4db6d9da.pool.einsundeins.de) 15.27.08 # BdN3504: well, it's _possible_ it's a bug 15.34.50 # how is that approximately the same size? 15.35.51 Join EspeonEefi [0] (n=espeonee@220-130-43-250.HINET-IP.hinet.net) 15.37.50 # well they are both about 38Kb 15.38.07 # Size on disk is irrelevant 15.38.20 Quit blithe (Remote closed the connection) 15.38.30 Join blithe [0] (n=blithe@stiletto.djblithe.com) 15.39.33 # ok so here is what i found out: 16 bit colour bmp 58*638 does not work; 15.39.53 # 16 bit black & white 58*638 does not work 15.40.20 # 1 bit monochrome 58*638 does work 15.42.37 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-096-240.ewe-ip-backbone.de) 15.46.02 Quit kachna (Read error: 60 (Operation timed out)) 15.48.57 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-b7bfcc32f45d5dfe) 15.58.34 Quit EspeonEefi ("さよなら") 15.58.36 Join blahrus [0] (n=blahrus@75.150.209.185) 16.08.36 # haha 16.08.48 # * B4gder gets a synopsys data sheet viewed on their site 16.08.50 # 2 pages 16.08.59 # _that_ is not what I call a data sheet 16.10.22 Quit BdN3504 ("CGI:IRC") 16.10.42 # it looks like a product brief 16.11.27 # it seems every company has a different definition of "the document you want" 16.11.38 # user manual, reference manual, data book etc. 16.19.28 Join MethoS- [0] (n=clemens@host-091-097-243-110.ewe-ip-backbone.de) 16.25.33 Join kerwood_wk [0] (n=80f48719@gateway/web/cgi-irc/labb.contactor.se/x-f77bb156dca46de1) 16.28.16 # I mailed AMS now to see if they can help 16.31.48 Quit evilnick ("http://www.mibbit.com ajax IRC Client") 16.32.53 Quit kerwood_wk ("CGI:IRC (EOF)") 16.34.08 # B4gder: There's an image in SVN for the beast now (I committed last night) 16.34.08 Quit jhMikeS (Nick collision from services.) 16.34.14 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 16.34.27 # yes, it just has to be converted to one of them tiny ones 16.34.33 # It was... 16.34.36 # oh 16.36.53 # fixed! 16.37.22 # nice. 16.46.01 # The blind description for the beast needs a little fixing up. 16.46.40 # The bottom of the beast is actually, from left to right: battery switch, USB port, dock connector. 16.49.35 Quit suom1 (Read error: 104 (Connection reset by peer)) 16.50.47 *** Saving seen data "./dancer.seen" 16.52.49 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 16.52.59 Quit Llorean (Read error: 104 (Connection reset by peer)) 16.58.09 Join suom1 [0] (i=markus@viitamaki.net) 17.00.25 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 17.01.46 Quit Zagor ("Client exiting") 17.01.50 Join haithun [0] (n=4dbb5e1b@gateway/web/cgi-irc/labb.contactor.se/x-489ba512f4fe6b48) 17.03.48 # Anyone know the magic to get objdump to dump a codec file? Is it just a raw binary? 17.04.29 # why would you want to dump it? The source code is available for all our codecs... 17.04.53 # GodEater_: I'm seeing what the compiler has screwed up vs the official binary build 17.05.50 # oh I see 17.06.10 # * GodEater_ doesn't recall the command line required for objdump as he uses it very infrequently. 17.07.18 Quit haithun ("CGI:IRC (Ping timeout)") 17.07.37 Join haithun [0] (n=4dbb5e1b@gateway/web/cgi-irc/labb.contactor.se/x-3dc7cd568a394227) 17.10.14 Quit haithun (Client Quit) 17.14.48 Join haithun [0] (n=4dbb5e1b@gateway/web/cgi-irc/labb.contactor.se/x-6cfacd39a5b3a61b) 17.15.32 Quit haithun (Client Quit) 17.18.21 Join haithun [0] (n=4dbb5e1b@gateway/web/cgi-irc/labb.contactor.se/x-e6686221d461edfd) 17.19.04 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-32ae2bddabcaf488) 17.19.10 # Is the 5.5G iPod a LE and BE ARM? 17.19.19 # LE 17.19.36 # all current Rockbox ports on ARM are little endian 17.20.00 # ajb`: I'd objdump the .elf file if it's available 17.21.38 # gevaerts: The elf filea aren't packaged in the "official" builds. Just the final binaries 17.21.55 # gevaerts: If anyone can send me the generated files that would be great 17.22.14 Quit haithun (Client Quit) 17.23.31 Join {phoenix} [0] (n=dirk@p54B476D9.dip.t-dialin.net) 17.24.56 # * ajb` is almost there with objdump -d --target binary -m arm -EL official.r19705/codecs/aac.codec 17.25.39 # the "official" elf files aren't kept anywhere 17.25.54 # ajb`: how is your build different from the "official" one ? 17.26.06 # All you need to do is have the right tool chain set up, and then you'd be able to build it too 17.27.10 # GodEater_: Except my build breaks on m4a files and we narrowed it down to build. I want to compare the code my rockboxdev compiler spat out vs the official build 17.27.38 # ajb`: the "official" build is done on a collection of random people's servers though 17.27.59 # so one svn rev might be from one person's PC, and the next from someone completely different 17.28.48 # Well the "official" build works with m4a's mine doesn't. Until I can do a side by side dump of the codec we have no idea why 17.29.05 # * ajb` begins to suspect the .codec files aren't just raw binaries 17.29.07 # and you're using all the recommended versions of all the build tools ? 17.30.07 # GodEater_: I built my compiler with rockboxdev.sh 17.30.23 # GodEater_: And if there is a compiler bug I'd like to report it 17.31.17 # hahaha - good luck 17.31.21 # the gcc folks hate us 17.31.35 # just ask amiconn ;) 17.32.22 # ajb`: what build platform are you on? 17.32.28 # Well looking at the hexdump there is only one byte difference 17.32.28 # maybe if he doesn't say he built rockbox with it! ;-) 17.33.11 # GodEater_: 16:06 alex@danny/x86_64 [ipod.build] >arm-elf-gcc --version 17.33.11 # arm-elf-gcc (GCC) 4.0.3 17.33.11 # 17.33.35 # * ajb` looks to see how the codec files are generated 17.37.16 # ajb`: You're compiling on a 64-bit Linux host? 17.39.41 Part B4gder 17.40.05 # linuxstb: yep 17.40.39 # linuxstb: 6:31 alex@danny/x86_64 [bins] >uname -m 17.40.39 # x86_64 17.40.39 # 17.41.55 # Assuming the offset of 0x750 in the hexdump is the same as the map that says the invalidate_icache code is slightly different 17.42.17 # Unfortunatly I can't see the instructions as objdump segs (I assume on the .codec header) 17.42.46 # 16:31 alex@danny/x86_64 [bins] >diff -b my.dump off.dump 17.42.46 # 118c118 17.42.46 # < 00000750 c0 5e ea f3 18 18 01 40 18 18 01 40 18 68 01 40 |.^.....@...@.h.@| 17.42.46 DBUG Sent KICK ajb` to server 17.42.46 # --- 17.42.47 Kick (#rockbox ajb` :No flooding!) by logbot!n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-8076c4bfe14b4de1 17.42.59 Join ajb` [0] (n=user@cpc2-cmbg5-0-0-cust252.cmbg.cable.ntl.com) 17.43.10 # oops sorry, I should pastebin this stuff 17.48.54 Quit Slack_ (Connection timed out) 17.48.58 Join miepchen^schlaf [0] (n=miepel@p579ECB86.dip.t-dialin.net) 17.52.01 # Found it. Even objdump can't dissasmble this instruction 17.52.26 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 17.52.54 # is codec_start a shared function? 17.54.40 # ajb`: If you want, I can do an ipod video build, and give you some bin/elf/map etc files to compare. 17.55.28 # What memory size are you compiling for? 17.55.57 # 80 GB 5.5G iPod 64Mb 17.56.03 # linuxstb: But I have found the problem 17.56.27 # linuxstb: Although it does beg the question what was the address being reported by the UEI handler? 18.03.52 # * ajb` waits for his iPod to finish commiting the db 18.06.16 Quit miepchen^schlaf () 18.06.20 Join karashata [0] (n=karashat@69.41.192.215) 18.07.07 # Ok, that's confirmed. Copying the official aac.codec over my compiled one and I can play m4a's again. Don't know why my compiler is breaking it 18.08.43 Join ender` [0] (i=krneki@foo.eternallybored.org) 18.15.44 # * ajb` calls it a day for today 18.16.33 Join miepchen^schla [0] (n=miepel@p579ECB86.dip.t-dialin.net) 18.17.23 Quit evilnick ("http://www.mibbit.com ajax IRC Client") 18.24.28 Join TheSphinX^ [0] (n=cold@p54A5DF6E.dip.t-dialin.net) 18.24.35 Join kugel [0] (n=chatzill@unaffiliated/kugel) 18.26.37 Join fredddy [0] (n=freddy@p3E9E036D.dip0.t-ipconnect.de) 18.28.59 Quit tvelocity (Remote closed the connection) 18.29.20 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 18.43.38 Join Slack_ [0] (n=brett@12-218-60-196.client.mchsi.com) 18.46.54 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.50.51 *** Saving seen data "./dancer.seen" 18.56.10 Quit obo (Remote closed the connection) 19.01.02 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 19.02.31 Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net) 19.09.07 Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) 19.13.54 Join tessarakt [0] (n=jens@e180064244.adsl.alicedsl.de) 19.15.59 # Bagder: ping 19.17.00 # ajb`: You're building on linux-amd64, and you're using the official arm-elf-gcc 4.0.3, built using rockboxdev.sh? 19.18.25 Quit Darksair ("People who are zhuangbility want to show their niubility but only reflect their shability.") 19.19.45 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 19.19.48 # amiconn: yes? 19.20.05 # The two AMS Sansas are still missing from the binsize table 19.20.24 # yes, early ports don't tend to be as useful there 19.20.48 # you want them added? 19.20.49 # Hmm. They're the only target builds which are in the build table but not the binsize table 19.21.19 # could we also add the m200v4 main build ? 19.21.40 # domonoky: sure! 19.23.19 # And if we don't want early ports there, the Cowon D2 and the creative ZENs shouldn't be there either. 19.23.37 # But imho the two table should be kept in sync, if only to reduce confusion 19.23.39 # well, its not about "what we want" 19.23.41 # *tables 19.23.45 # it's about what's useful to anyone 19.23.51 # imho 19.25.48 # * amiconn thinks that having some lowmem swcodec ports there could be useful 19.26.34 # I've now added m200v4 normal + sim to the build table, and clip, fuze and m200v4 to the delta table 19.27.01 # * domonoky hopes that the m200v4 sim builds :-) 19.27.24 # at next commit we'll see! :-) 19.27.25 # * amiconn wonders whether we'll support all m200 versions at some point ;\\ 19.29.06 # I doubt that 19.29.07 Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) 19.29.27 # amiconn: Depends on when Mr. Someone decides to finish off the ports to the TCC m200s. 19.29.30 # m200v4-sim doesn't build here 19.29.45 # is it close to build or shall I remove it again? 19.29.53 # LambdaCalculus37: v1..v3 are all TCC? 19.29.58 # * domonoky will try to fix. 19.30.16 # its probably not much missing. 19.30.25 # amiconn: v1 and v2 are at least 19.30.26 # I think it's close, but have no details 19.31.14 # some button defines are undeclared 19.31.29 # we need a picture.. 19.32.14 # amiconn: Yes. 19.32.32 Join BigBambi [0] (n=alex@79.83.41.188) 19.32.51 # Bagder: v3 is the HARP model; that's the one I have and it's TCC based as well. It should be, anyway, it did belong to shotofadds. 19.32.57 # aha 19.33.12 # Are the differences between v1..v3 known? 19.33.15 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 19.34.06 # amiconn: v1 and v2 have NAND flash, and the v3 has an SD interface bridge, IIRC. preglow may know a little more about that. 19.34.27 # Hmm, so the v3 should be a bit easier.. 19.36.11 # ooh, nice green deltas 19.36.20 # Summer of Code 2009 will happen 19.36.25 Quit HellDragon (Read error: 104 (Connection reset by peer)) 19.37.11 # "a bit smaller (targeting ~1000 students this year) so we 19.37.11 # will likely target fewer organizations (~150). " 19.37.31 # how many was it last year? 19.38.12 # 1125 19.38.32 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 19.38.40 # 1125 organization? wow. 19.38.52 # amiconn: yes built with the rockboxdev script 19.39.14 # the number of orgs isn't stated and I can't bother to count them myself ;-) 19.39.51 # ajb`: That *is* weird then. Some build boxes used for the current builds are also running 64 bit linux (e.g. mine). 19.40.33 # we should make sure someone else's 64bit build is tested against ajb's problem 19.40.59 # I mean, it could be 64bit-related or it is ajb`-specific 19.41.03 # ajb`: What's your target? 19.42.37 # 5.5G 80Gb iPod Video 19.42.44 Nick miepchen^schla is now known as miepchen^schlaf (n=miepel@p579ECB86.dip.t-dialin.net) 19.43.18 # amiconn: It only gets a few bytes different from the official build but it's a crucial few bytes 19.43.29 # Yeah, I've read it 19.43.54 # I could provide a build built on my debian-amd64 box (the same that is providing a few of the official builds) 19.43.59 Join GodEater [0] (n=ge@rockbox/staff/GodEater) 19.46.21 # amiconn: sure. If you could just bung me the aac codec elf file I can do a better compare 19.47.01 # amiconn: whats arm-elf-gcc --version report on your box? 19.48.51 # ajb`: I've just made a 64MB ipod video build on my 32-bit Linux - do you want anything from it? 19.49.52 # linuxstb: apps/codecs/aac.elf 19.50.13 # ajb`: http://linuxstb.cream.org/rockbox/aac.zip - contains aac.elf, aac.codec and aac.map 19.50.29 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-dcd6679a4e0f33d3) 19.51.26 # ajb`: http://amiconn.dyndns.org/~jens/aac.zip contains .codec, .elf and .map, built on debian-amd64 19.51.58 # thanks 19.52.02 # * ajb` compares 19.52.31 Quit BigBambi (Remote closed the connection) 19.53.27 Quit TheSphinX^ ("XChat@Linux") 19.53.29 # i've been meaning to suggest for a while that the buffering from flash patch eventually be commited, and a special lowmem build be configured [sansa or whatever with all but 1-2MB of RAM disabled] so that we can keep an eye on low mem swcodec 19.54.04 # it'd be nice to know when people are commiting code that implicitly limits playback to >X MB of RAM 19.54.27 # Why (mis)-configure an existing target? 19.54.53 # If it's just the build table you're interested in. 19.54.58 # yes 19.55.20 # so we notice when things break 19.55.49 # I mean, why not just add a real lowmem target? 19.56.07 # i figured a stable target would be easier to compare to 19.56.14 # we have real lowmem targets now in the table :-) 19.56.15 Quit japc (Read error: 145 (Connection timed out)) 19.56.17 # Imho the flash buffering patch isn'tz ready for commit, and it isn't really needed either 19.56.18 # since the AMS targets are already quite buggy on their own 19.56.28 # interesting 19.56.46 # though i suppose if they become stable there'd be no sense in it 19.56.58 # saratoga: I agree, it's useful for testing, but you said you were talking about the build table. 19.58.37 # linuxstb: you think it'd only be useful if people actually ran the build, rather then just checking if it compiled? 19.59.37 # linuxstb: amiconn: I can't dissasemble the same bits on yours 20.00.08 # but it is a single bit difference 20.00.19 # * ajb` needs to know how to hand decode AMR 20.00.44 Quit markun (Read error: 110 (Connection timed out)) 20.02.59 Join BigBambi [0] (n=alex@188.41.83-79.rev.gaoland.net) 20.03.12 # http://rockbox.pastebin.com/m12924847 20.03.31 # oo fancy url 20.03.45 # so what ever is breaking my compiler seems to have confused my objdump too 20.03.46 # saratoga: Yes. I'm not sure what would show in the build table for a 2MB e200v1 that wouldn't show for a 2MB e200v2 or Clip. 20.04.23 # I guess remove "2MB e200v2" from that sentence... ;) 20.07.42 Quit Bagder ("*plopp*") 20.07.50 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 20.08.04 # I rather think the buffering from flash patch should be rejected 20.09.29 Quit karashata ("G'bye everyone!") 20.10.13 # Zagor: btw: I couldn't reproduce the hissing noice wiht the watermark patch on my e200v1, seems to be another ams sansa issue 20.10.32 # Zagor: how different is it then the current buffering system with a small buffer size? 20.12.36 Join Chronon [0] (n=chatzill@d23-104.uoregon.edu) 20.13.01 Join petur [50] (n=petur@rockbox/developer/petur) 20.13.49 # I just found a case of GPL violation on our wiki: http://www.rockbox.org/twiki/bin/view/Main/LogoSwapper 20.14.12 # It makes use of bmp2rb but isn't licensed in a GPL compatible way. 20.15.17 # Chronon: How do you know it's using bmp2rb? 20.15.26 # It claims so on the wiki page 20.16.02 # Where? 20.16.11 # ajb`: Weird. These constants are in the constant pool of codec_start, and I wonder how gcc managed to put a wrong constant there for you 20.16.19 Quit soap (Read error: 104 (Connection reset by peer)) 20.16.34 # Sorry. . . it claims it in the text file in the .zip: "This Windows application makes it possible to change logos contained in Rockbox binary files. 20.16.36 # A compiled version of the Rockbox tool "bmp2rb" is used for the bitmaps conversions." 20.16.46 # saratoga: well it differs massively, since buffering_flash.c is custom code to handle this particular case and ignore all others (such as MoB). and I don't see how it would gain any runtime either. memcpy isn't a big battery waster. 20.17.55 # Chronon: Does that .exe run directly, or is it an installer? (I'm on Linux, so can't run it) 20.18.14 # I guess it made its way to our wiki from this misticriver thread: http://www.misticriver.net/forums/rockbox-forums/52672-logo-swapper-windows-application.html 20.18.50 # amiconn: so it's not even code? 20.19.25 # amiconn: pop {r4, pc} is a return then? 20.19.39 # yes 20.19.46 # linuxstb: it runs directly. 20.20.08 # * ajb` wonders which constant it is then 20.20.27 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 20.20.30 # 0x03ea5ec0 is plugin_end_addr. Somehow your gcc manages to put 0xf3ea5ec0 there 20.20.39 # amiconn, ajb`: Could this not be a binutils (as/ld?) issue, rather than gcc? 20.21.48 # Ah no, it's plugin_bss_start. But in case of aac.codec, both are equal 20.21.58 # Chronon: "A compiled version of the Rockbox tool "bmp2rb" is used for the bitmaps conversions." isn't very clear, but it does sound like they've incorporated the code... 20.22.01 # That just means aac.codec has no .bss 20.22.37 # (probably everything in .ibss for performance) 20.23.12 # No it would be gcc that generates it surely? 20.23.24 # ajb`: objdump isn't really clever and tries to disassemble everything if it is located in a code segment, even if it is a constant pool 20.23.52 # I don't know of any way to contact the author for clarfication. 20.24.49 # ok that solves the objdump mystery, now as to why the address is wrong 20.24.55 # ajb`: It could very well be caused by the linker 20.25.46 Part jon-kha ("[IRSSI] the Cadillac of all clients") 20.26.11 # arm-elf-gcc -v ==> gcc-Version 4.0.3, arm-elf-ld -v ==> GNU ld version 2.16.1 20.26.39 Join jon-kha [0] (i=jon-kha@kahvi.eu.org) 20.27.54 # arm-elf-ld --version -> 2.18 20.28.00 # hmmm 20.28.43 # Chronon: I guess the first thing would be to post to that thread. 20.30.18 # Chronon: But hosting the file on our wiki seems questionable anyway, regardless of the license issues. 20.30.29 # 19:30 alex@danny/x86_64 [ipod.build] >which arm-elf-gcc 20.30.29 # /home/alex/tools/arm-elf/bin/arm-elf-gcc 20.30.29 # 20.30.35 # 19:30 alex@danny/x86_64 [ipod.build] >which arm-elf-ld 20.30.36 # /usr/bin/arm-elf-ld 20.30.37 # bingo 20.31.27 # linuxstb: I can edit the wiki to remove the download link for now. I don't have a misticriver account. Maybe someone who already has an account can pursue this? 20.32.53 # I would wait until others comment - e.g. Llorean who last edited that page. 20.34.00 # ajb`: You have a cross-linker in /usr/bin? Do you know what package it belongs to? What distro are you suing? 20.34.09 # *using 20.35.05 # amiconn: Gentoo, I suspect it's because I have a multilib binutils or some such 20.35.38 # linuxstb: Sounds good. 20.36.25 # amiconn: Unfortunatly a clean build with path tweaked to skip those still gives the wrong code 20.36.37 Join rico [0] (n=chatzill@86.98.100-84.rev.gaoland.net) 20.37.36 Join nibbler [0] (n=Nibbler@e181077188.adsl.alicedsl.de) 20.38.00 # s/code/constants 20.38.00 # ajb`: Did you re-run configure? 20.38.17 # linuxstb: just doing so now to be sure 20.38.28 # * linuxstb has a feeling the generated Makefile has the full paths 20.38.33 # It has 20.38.34 # and a ccache -C wouldn't probably hurt either 20.38.59 # That should fix it. configure puts the full paths to the tools into the Makefile, for a bit of speedup 20.39.54 # * ajb` taps fingures 20.40.33 # woot! 20.40.34 # ajb`: Do you have the other v2.18 arm binutils in /usr/bin as well? e.g. arm-elf.as ? 20.40.50 # linuxstb: yep, the whole lot 20.40.58 # OK, so it seems 2.18 is to be avoided... 20.41.15 # Mystery solved.... broken by a later binutils 20.41.24 # Well, someone would need to find out what's going wrong in 2.18 20.44.02 # * ajb` tries 2.19 20.45.32 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-dfdb2c0dff0ac213) 20.45.46 Join DerDome [0] (n=DerDome@dslb-082-083-209-177.pools.arcor-ip.net) 20.46.03 # amiconn: Whatever it was it seems fixed in 2.19 20.48.16 # What should I do with FS#9745, I guess it needs closing now? 20.49.10 # * ajb` realises other half will be home soon and needs feeding. 20.49.23 # Be back later! 20.50.53 *** Saving seen data "./dancer.seen" 20.51.18 Quit saratoga ("CGI:IRC (EOF)") 20.56.07 Quit jhulst (Read error: 60 (Operation timed out)) 20.56.42 # hello people. I need to upgrade the firmware of my samsung Q1 to enable UMS usb mode. I found a solution on internet using tcctool from rockbox site, but I have linux only on my computer. Do you know a way to upgrade my firmware on liinux ? 20.57.11 Quit Thundercloud (Read error: 104 (Connection reset by peer)) 20.57.27 # tcctool runs on linux ... 20.58.04 # ah great news :) do you know where I can find it ? I only find windows binary 20.58.19 # svn. 20.58.33 # as the complete source for Rockbox and its tools ... 20.59.33 # ok I'll try that, thx 20.59.33 Join merbanan [0] (n=banan@83.233.243.20) 21.01.25 Join Torne [0] (i=torne@lil.wolfpuppy.org.uk) 21.02.33 # hm. i seem to have done somethign to my ipod while experimenting with bootloaders 21.02.45 # it doesn't boot up at all now without a hard reset, after being shut down from rockbox 21.03.10 # just does the thing where some weird icon flashes up for a moment with no backlight, in the apple rm 21.04.19 # does anyone actually know what causes that to happen? 21.05.24 Quit miepchen^schlaf () 21.05.51 Join tvelocity [0] (n=tony@adsl1-102.her.forthnet.gr) 21.06.04 # hm, no, there it goes again working 21.06.09 # four times in a row seemed odd 21.06.15 # * Torne glares at it 21.12.41 Join miepchen^schlaf [0] (n=miepel@p579ECB86.dip.t-dialin.net) 21.13.29 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 21.14.18 # bluebrother: I find tcctool only here : http://svn.rockbox.org/viewvc.cgi/trunk/utils/tcctool/ but it is only about windows. Is there another repository ? 21.16.24 # robin0800: no it's not. checked the Makefile? 21.16.38 # rico: The linux version is there... 21.17.34 # tcctool.c ? I only have to compile that and no need other driver like windows needs ? 21.17.34 Join karashata [0] (n=karashat@69.41.192.215) 21.17.52 # checked the Makefile? You need libusb 21.17.59 Quit nibbler (Read error: 113 (No route to host)) 21.18.23 # I suggest simply running "make" ... 21.18.25 # rico: Why not do "make" seeing as there is a makefile? :) 21.18.42 Join nibbler [0] (n=Nibbler@e181077188.adsl.alicedsl.de) 21.18.43 # * bluebrother wonders why he asked if rico checked the Makefile 21.19.32 # hmm I checked but didn't really understand it ^^ I think I need libusb-dev in fact (I got some errors when I ran make) 21.20.05 # ah, it works ! thanks ;) 21.20.20 # you need the development package of libusb obviously. But that is the cause for anything you're trying to build that needs the library 21.20.49 # n1s: I guess microphone holes should be labelled then too? 21.21.03 Join tarbo [0] (n=me@unaffiliated/tarbo) 21.21.17 Quit ze ("building new system without even all the parts") 21.21.46 # yes bluebrother, I was not sure which library I needed 21.25.30 Quit reacocard (Remote closed the connection) 21.27.50 Join funman [0] (n=fun@rockbox/developer/funman) 21.31.26 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 21.31.38 # hello, i've been away for some times, could you sum up the progress on sansav2 for me ? (I noticed that basic c200v2 support was added, and still no FM radio for the clip -can't remember the FS number-, nor playback fixes) 21.34.53 # funman: playback works fairly well with FS#9703 applied, as long as you don't get the sd crash 21.36.03 Join MethoS-- [0] (n=clemens@host-091-097-243-110.ewe-ip-backbone.de) 21.38.15 Quit MethoS- (Read error: 145 (Connection timed out)) 21.38.39 Quit kachna (Remote closed the connection) 21.41.11 Quit rico ("ChatZilla 0.9.84 [Iceweasel 3.0.5/2008122010]") 21.41.14 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 21.41.46 # has someone looked at SD code yet, or is it something i could start? 21.43.02 Join Jaykay [0] (n=chatzill@p579E73DF.dip.t-dialin.net) 21.45.16 # funman: I don't think anyone is looking at it 21.45.45 Join timc`` [0] (n=aoeu@124.93.243.83) 21.46.02 Quit timc (Connection timed out) 21.46.33 Join japc [0] (n=japc@bl7-247-89.dsl.telepac.pt) 21.46.41 # i'll try to have a look at it tomorrow 21.49.21 Quit fredddy (Remote closed the connection) 21.50.33 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 21.52.20 # funman: for fm, i think we only need the correct audio routing and as3514.c using line-in2 instead of line-in1, then it should work. 21.52.50 # what's audio routing, if not selecting the correct line input ? 21.52.54 Quit karashata ("G'bye everyone!") 21.54.29 # i mean the switiching of the inputs. the code which should go into audio-as3525.c 21.55.00 Join B4gder2 [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 21.55.29 # i had thought about it, something like #ifdef CLIP || E200v2.. #define FMLINE LINE2 #elif defined(E200) #define FMLINE LINE1 #endif 21.57.20 Nick B4gder2 is now known as Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) 21.59.08 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 22.01.47 Nick Bensawsome is now known as DOMO (n=Bensawso@unaffiliated/bensawsome) 22.01.56 # n1s: the capacity setting has no effect on charging decisions on the beast 22.04.43 Quit merbanan (Remote closed the connection) 22.05.19 # is there any way to produce a diff from a single file? 22.05.37 # Jaykay: compared to what? 22.05.44 # to svn 22.05.52 # svn diff? 22.05.56 # jep 22.07.12 Nick DOMO is now known as Bensawsome (n=Bensawso@unaffiliated/bensawsome) 22.07.12 # svn diff ./my/file 22.08.34 # works, thanks! 22.15.22 Part Torne 22.17.21 Join Strife89 [0] (n=michael@204.116.245.152) 22.17.29 Join gartral1 [0] (n=Gartral@75.33.82.151) 22.24.10 Quit Strife89 ("I need to head off, I'll come back another time.") 22.25.48 Quit japc (Read error: 110 (Connection timed out)) 22.26.40 Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 22.26.56 Join Jaykay [0] (n=chatzill@p579E73DF.dip.t-dialin.net) 22.28.12 Join akur [0] (n=akur@bl9-154-178.dsl.telepac.pt) 22.28.15 Part akur 22.29.48 # I want to change "modelname" for x5, m5 and m3 in tools/configure so they match the filenames used in firmware/export/config-*. can anyone think of anything that would break? 22.30.18 # not as long as you don't touch the actual shortcut name you can select in the menu 22.30.42 # I won't 22.31.44 # * linuxstb thinks it's about time there was some model name/number cleanup... 22.32.14 # gigabeatf mismatches too. its' config file is called gigabeat.h 22.32.26 # e.g. target_id and MODEL_NUMBER 22.33.06 # model number? 22.34.10 # I think it's being used as the initialisation for the checksums in binary headers. Not sure about other uses. 22.34.27 # The scramble -add option. 22.34.45 # Which also uses a four character model identifier 22.34.53 # yay 22.35.04 # ;) 22.35.06 # why should the gigabeat F/X be "the generic gigabeat"? 22.35.33 # jhMikeS: I guess it was simply because it was the only gigabeat for a while 22.35.38 # I'll rename it 22.37.28 # Ah, is modelname used in the lang files? 22.38.11 # ah...causality 22.38.34 # ah, they are. but wrong! 22.39.22 # no, I'm confusing my changes with svn :-/ 22.39.26 # # Gigabeat Fxx gigabeatf 22.39.26 # # Gigabeat Sxx gigabeats 22.43.05 # what does the "user:" field in the lang files do? 22.43.26 Join m0f0x [0] (n=m0f0x@189.78.5.66) 22.43.28 # rasher: pping 22.43.37 # rasher: ping 22.44.33 Quit funman ("leaving") 22.46.21 # seems like funman has more time again? \o/ 22.47.17 # yay. only the reason is not the best. 22.47.26 # Just reminding about c200/e200 charging (resynced into newer powermgmt framework): http://www.rockbox.org/tracker/task/8363 22.48.35 # Zagor: so... the only thing that changes, in my API() cleanup, is that PREFIX is gone? :) 22.49.39 # jhMikeS, thanks for the resync 22.49.54 # not so much a resync, rather a rewrite I suppose 22.50.54 *** Saving seen data "./dancer.seen" 22.50.58 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 22.51.38 # I don't know. It's strictly on the powermgmt thread in the target framework sine it was done just for that sort of thing. 22.55.52 # Unhelpful: with the PREFIX gone, simple redefining of open works in sims. so that's all you have to do. 22.56.40 # I found that doom and rockboy actually already do that. Although they had to jump through hoops to bypass the PREFIX 22.57.08 # linuxstb: hi, I will get a try to document beast installation for windows in the wiki 22.57.36 # well, they're ports of non-rockbox applications... it'd be a pain without *some* kind of fixup 22.58.05 # yup 22.58.19 # * Unhelpful sees that he doesn't even need to #undef POSIX file functions any more 22.58.33 Quit miepchen^schlaf () 22.59.25 # moos: OK. Although I'm hoping I'll find time to streamline the install process a little - e.g. by combining mknkboot and sendfirm. Or we just ignore dual-booting for now... 22.59.29 # i've got the wrapper stuff defined once in apps/plugins/lib/core_wrappers.h. i still need to add declarations for resize_init and bmp_init, and then this should be ready to go :) 23.00.11 # linuxstb: nice, then maybe wait you do this first? /me no more use dualboot now :) 23.00.41 # API will be completely gone, there will still be a few checks against PLUGIN, but only where code actually needs to differ... i don't think that's a whole lot worse than what's already there for various display types. 23.00.47 # linuxstb: we don't have dualbooting either for the X5, and long time now it was suported... 23.02.01 # moos: Yes. Because we have charging and usb access on the beast, I don't consider dual-boot as vital. 23.02.38 # indeed 23.02.41 # i don't have time to bugfix if something breaks, right now, so i'll look for any comments when i get to work 23.02.41 # * Bagder agrees with linuxstb 23.02.43 # It is a bit like the F to me - pointless, as you can't use music from either RB or the OF on the other 23.02.54 # linuxstb: and faster boot 23.03.07 # and given radio too is in RB 23.03.14 Quit petur ("Zzzzz") 23.03.24 # So does the OF do anything Rockbox doesn't do? I guess USB host? 23.03.30 Join miepchen^schlaf [0] (n=miepel@p579ECB86.dip.t-dialin.net) 23.03.34 # TV out I suppose 23.03.39 # yup 23.03.41 # DRM? 23.03.45 Join miepchen^schla [0] (n=miepel@p579ECB86.dip.t-dialin.net) 23.03.46 # Unhelpful: I think you should avoid calling any file "core". it's gets rather confusing any way you do it. better to have a clarifying comment inside the file. 23.03.50 # usb host, TV out, video in newer codecs than mpeg2 23.04.08 # nothing vital 23.04.18 # (IMO, of course!) 23.04.19 # Zagor: ok, i'll look into that when i get to work, as well :) 23.04.21 # What codecs? I've never tried the beast's OF video playback... 23.04.27 # wmv 23.04.44 # Except I could never produce one that worked properly 23.05.11 # At least you know where you are with mpeg1/2... 23.05.20 # yep 23.05.30 # and it is easy to produce on all platforms 23.05.32 # iaudio X5 is a good example of bootloader rockbox only, and there was no to much complaints (even if we have a patch) 23.05.55 # But hasn't there always (or almost always) been an unofficial dual-boot bootloader? 23.06.00 Quit evilnick ("http://www.mibbit.com ajax IRC Client") 23.06.02 # yes 23.06.04 # Hence the lack of complaints. 23.06.15 # and that exists too for the S 23.06.22 # In fact, it is much more official 23.06.32 # if people want to do it 23.06.37 # But going back to the beast, I think it's fine to start with a single-boot "release" of docs/tools, and then aim to do dual-boot asap. 23.06.46 # yup 23.06.53 # linuxstb yup a dualboot patch, but we don't suport it ;) 23.07.25 # linuxstb: +1 23.07.59 # Is someone willing to make a bootloader release for the beast? i.e. compile it with a version number (1.0?), tag in svn, then give to Bagder? 23.08.06 # * linuxstb doesn't have his beast with him 23.08.09 # linuxstb: moos says you pinged me about sendfirm? 23.08.14 Join BrianRowe [0] (n=browe@pool-71-185-234-117.phlapa.fios.verizon.net) 23.08.31 # jhMikeS: I don't think so. Although do you know anything about the dll the windows version uses? 23.08.39 # linuxstb: I clearly can't do that, but I can test any 23.08.51 # yup this, I was wondering to share this to wiki 23.08.58 # IIRC it's a redistributable DLL 23.09.12 # But not open source? Meaning we can't call the windows sendfirm GPL? 23.09.40 # linuxstb: I saw this today: http://forums.rockbox.org/index.php?topic=4737.msg132797#msg132797 23.09.51 # or is it not what I'm thinking...have to look. 23.10.08 Quit Jaykay (Read error: 110 (Connection timed out)) 23.10.21 # BTW, what prevents GPL code from using a DLL that isn't open source? I wouldn't think it would be possible to GPL anything using the OS then. 23.10.37 Quit {phoenix} (Remote closed the connection) 23.10.42 Quit BrianRowe (Client Quit) 23.10.43 Quit jhulst (Read error: 110 (Connection timed out)) 23.10.56 # BigBambi: Yes, mcuelenaere said that in the source code somewhere, or maybe a README. 23.10.57 Join BrianRowe [0] (n=browe@pool-71-185-234-117.phlapa.fios.verizon.net) 23.10.58 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 23.11.14 # Did he build that DLL? 23.11.39 # That's what I was wondering 23.11.49 # The source to the DLL is in SVN, but to build it you need to link with a .lib from a MS SDK. 23.11.57 # ah, OK 23.12.02 Quit miepchen^schlaf (Connection reset by peer) 23.12.08 # indeed bad 23.12.10 # Googling it only brings up mostly rockbox info 23.12.24 # ah, ok 23.13.01 # will anything bad happen if e200 and e200r have the same MODELINFO? 23.13.20 # err, MODELNAME 23.13.30 # jhMikeS: jhMikeS the GPL allows to link to non-GPL files that are distributed with the OS or compiler, but not if you distribute them with your binary 23.14.12 # gevaerts: So you agree that the windows sendfirm can't be GPL'd? 23.14.28 # linuxstb: that's my opinion, yes. 23.14.34 # gevaerts: then don't. what about the other side? can they be ditributes separately (as in not in the same .zip)? 23.15.23 # Zagor: only bootloader install-wise iirc 23.15.36 # jhMikeS: you're really getting into grey areas then. 23.16.23 # what is being distributed with the dll? Doesn't it just call the WMDM dlls at runtime? 23.16.54 # gevearts: You bet. If they're gray areas, then someone can bother to spend their time arguing, possibly futilly. 23.17.05 # Hillshum: do you mean that something will break regarding bootloader installation, or that the modelname is only used when building the bootloader? 23.17.27 # that the only difference is BL install 23.20.33 # Hello everyone - a request from a new wiki user... 23.20.37 Quit bluebrother (Nick collision from services.) 23.20.42 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 23.20.54 # obo: Have a look inside utils/MTP 23.21.27 # I'm looking to add my findings for a CF mod for the F series, so if someone could give me write access, I'd appreciate it 23.21.49 # BrianRowe: One moment... 23.22.08 # thanks... at your convenience 23.22.11 # Done. 23.22.21 # Thanks again 23.22.30 # Zagor: BTW, is there any way that user list could be split into one line per user? diffs are not helpful... 23.23.14 Quit bmbl ("Woah!") 23.23.14 # I don't think so. twiki variables have to be on one line. :-( 23.23.18 Join japc [0] (n=japc@bl7-247-89.dsl.telepac.pt) 23.24.15 # unless there is a way to do VAR = $(VAR) + string 23.28.23 # just what is the problem here? I don't see this .lib in utils/MTP 23.28.37 # linuxstb: yup, MTP_DLL.dll... but why can't that be redistributed? It's compiled as MDd/MTd - so it only links against the WMDM libs 23.29.32 # Zagor: is there no way to continue a line by terminating it with a \ or similar? 23.29.43 # bluebrother: not that I know, no 23.29.51 # too bad 23.30.58 Join ajb`` [0] (n=user@cpc2-cmbg5-0-0-cust252.cmbg.cable.ntl.com) 23.31.10 # I quite dislike that MTP_DLL.dll (btw, why dll two times?) requires WMP10 due to the MTP stuff -- that would make rbutil require that too :/ 23.31.24 # if i change the SOURCES files in ./apps/bitmaps/native to make it use a different file for the boot image, it should work, right? 23.31.39 Join fml [0] (n=4fd3fd7e@gateway/web/cgi-irc/labb.contactor.se/x-89e8690958f37311) 23.32.07 # bluebrother: the only other way is libmtp and libusb - but aren't there issues with libusb - having to register it for each device? 23.32.27 # but there really seems to be no MTP implementation for windows except the WMP SDK :( 23.32.47 # obo: does libmtp work on windows at all? 23.32.55 # I did get libmtp to compile... 23.33.13 # Maybe we could supply rbutil on a cut down live cd :) 23.33.13 # libusb is a bit nasty on windows, but we would need that for e200r installation too 23.33.26 # but I couldn't get it to see any devices, but I'm not sure why - I think it was a libusb issue 23.33.33 # we definitely could, but how big would such a CD get? 23.34.01 # I don't know, I was pretty mch joking :) 23.34.06 # IIRC you need to install the libusb filter driver for each device you want to access. 23.34.18 # haven't looked into that for ages though 23.34.20 # no so much, with damn small linux, <100MB I think 23.34.37 # kugel: remember that you need X and Qt for Rockbox Utility 23.34.39 # Quite large a download just to install rockbox 23.34.48 # bluebrother: cli? ;) 23.34.51 # bluebrother: that's as far as I got... I decided that end users weren't likely to jump through those hoops 23.34.56 # what happened to that btw? 23.35.05 # If you have a gigabeat S and you have been using it, chances are you have MTP installed already, correct? 23.35.19 # it's part of windows media player, so yes 23.35.23 Quit Horscht ("I got raided by the FBI and all i got is this lousy quit message") 23.35.26 # to what? The cli interface? 23.35.39 # yea 23.35.57 # it sits in the tracker, waiting for cleanup and resync. 23.35.59 # jhMikeS: Good point - you need WMP10 to get music on the S OF, so I guess so 23.36.08 # what's bad about rbutil requiring software that's is installed anyway (the beast's OF requres it too I suppose) 23.36.17 # I'd like to get that in some time and bump to 1.1 or even 2.0 23.36.21 # Hello. In the RB manual, there is the macro "\reference" which produces something like "section X (page Y)" If the macro itself is placed into () then we get nested () which doesn't look good IMHO. I once made a macro that produces something like section X_Y, i.e. the page number is typeset as a subscript. Could it also be used in the RB manual? 23.36.54 # kugel: other players that don't have those requirements now getting such requirements too? I don't want WMP10 just to install Rockbox on an Ipod ... 23.37.23 # "Requires WMP for Gigabeat S installation", no word about ipod 23.37.42 # * bluebrother gives up 23.37.48 # All references in that document were typeset like that. And I quite liked it. I didn't invent it but rather saw it in a book, liked it, and took it over for my document. 23.38.30 # fml: IMO that looks quite weird -- either leave out the page number or put it a normal-sized way. Having page numbers as subscripts looks ... well, strange. 23.38.42 # songbird is gpl, this perhaps can help ? http://addons.songbirdnest.com/addon/172 23.38.48 # if i change the SOURCES files in ./apps/bitmaps/native to make it use a different file for the boot image, it should work, right, or is there something else i should change 23.38.59 # kugel: but if rbutil depends on WMP10 for the beast, it will need it installed to run.. at all 23.39.00 # but it needs wm11 installed :) 23.39.12 # kugel: rbutil 1.0.8 was linked against mingwm10.dll. The functions of that dll were never used, still it had that dependency. 23.39.25 # bluebrother: you now think it does. But once you've seen it you'll ike it, I promise! :-) 23.39.40 # fml: got an example somewhere around? 23.40.12 # hm, I thought it could load MTP stuff only if someone wants to use it with the beast, and not for other players 23.41.04 # i should also not that the sources file laks the standard rockbox header comment 23.41.05 # but what's better? not requiring wmp, or not supporting windows? 23.41.05 # And it even makes the reading flow more smooth. Since normally you only want to see (read) the section number. But, if you're also interested in the page number you can have it as well. 23.41.05 # not if you link against a library. 23.41.35 # fml: use the html manual -- that doesn't show any page numbers ;-) 23.42.24 Quit kugel (Remote closed the connection) 23.42.26 # gartral1: I recall we do something special with the filename somewhere, but I can't remember what. try it and see what breaks :-) 23.42.30 # could rbutil just call an external appropriately licenced windows sendfirm? 23.42.38 # make: *** [/home/gartral/Rockbox/trunk/build/apps/bitmaps/native/rockboxlogo.176x83x16.c] Error 1 23.42.38 # make: *** Waiting for unfinished jobs.... 23.42.38 # rm /home/gartral/Rockbox/trunk/build/apps/bitmaps/native/rockboxlogo.176x83x16.c 23.42.38 DBUG Sent KICK gartral1 to server 23.42.38 # gartral@oden:~/Rockbox/trunk/build$ 23.42.39 Kick (#rockbox gartral1 :No flooding!) by logbot!n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-8076c4bfe14b4de1 23.42.41 # ther is no way to run sendfirm with some cygwin library 23.42.42 Join kugel [0] (n=chatzill@unaffiliated/kugel) 23.43.06 # BigBambi: it could. But isn't that kinda weird? Plus, we still have the license issue 23.43.22 # Does that not escape the licence issue? 23.43.24 # unless rbutil downloads this sendfirm binary itself 23.43.32 Join gartral1 [0] (n=Gartral@75.33.82.151) 23.43.43 # oops, ment to alt tab and use pastebin, sorry 23.43.47 # and the license issue for sendfirm still remains 23.43.58 # I know it'd be nice to have a GPL win sendfirm, but I thought the bigger problem was not being to include it within rbutil 23.44.08 # did that go through, or did logbot filter it out? 23.44.16 # some of it did 23.44.22 # pastebin.ca next time please 23.44.41 # i know, i tryed, and my fingers hit the wrong keys 23.44.51 # as a last resort we can simply make rbutil present the user a link to sendfirm to download and run himself 23.45.19 # bluebrother: how can I paste an image 23.45.23 # ? 23.45.29 # yeah, not too pretty, but a damn sight better than making rbutil dependent on wmp 23.46.17 # I remember there was a pastebin-like page for images. Just need to remember the URL ... 23.46.17 # http://gar.pastebin.com/m3b0da437 23.46.28 # fml: upload it to one of the gazillion photo hosting sites? 23.46.57 # isn't there an "imagebin" also? 23.46.58 Quit ajb` (Read error: 110 (Connection timed out)) 23.47.00 # gartral1: that just says make failed because something earlier produced an error. you need to include the earlier error. 23.47.20 # thats spat at me at make 23.47.28 # found it: http://imagebin.org/ 23.47.31 # and tere is no other error 23.47.46 # theres no jobs 23.48.07 # gartral1: yes there is. make doesn't do anything by itself other than compare file dates. it pretty much cannot fail on its' own. 23.48.37 # this is with my edited file, if i revert the change, it works 23.49.06 # try make V=1 for full command lines 23.49.18 # bluebrother: here is an example: http://imagebin.org/35277 23.49.41 # fml: I agree with bluebrother. that looks very strange. 23.49.58 # it is definitely not clear that the 9 is a page number 23.50.15 # fml: it looks like a broken chemical formula or mathematical expression 23.50.39 # Zagor: in my document, there was a note about that in the beginning. We could place it where other icons are explained. 23.50.56 # I don't expect the average user reading such a note 23.51.02 # fml: having to explain the documentation is ... bad 23.51.34 # you gotta explain what you gonna explain :P 23.51.53 # http://gar.pastebin.com/m738e62c0 23.51.56 # Zagor: but the icons are still explained :-) But if you don't like it I won't insist. I just saw the nested () and thought... 23.51.59 # fml: I'm not a fan of that I'm afraid 23.53.12 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 23.53.32 # gartral1: it looks like bmp2rb doesn't like your file. and it's being rude by only reporting an error code and not printing anything... 23.53.41 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 23.53.43 # we should rather consider dropping the page numbers completely. They were introduced to allow easier searching in a printout, but who prints out the manual anyway? 23.53.58 # plus, you can rather easily search for section number. 23.54.06 # ohh, umm, sould it be that it doesnt like starting with a 16 bit color image? 23.54.18 # could* 23.54.19 # I never missed page numbers in any kind of (technical) documentation referring to section numbers 23.54.46 # gartral1: it could. I don't remember the limitations of bmp2rb but that could indeed be one. 23.54.52 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 23.55.00 # bluebrother: me neither 23.55.02 # whats "safe" 23.56.07 # hmm, fml already gone. 23.57.14 # gartral1: well whatever format the original is, I wold consider safe 23.58.10 # * gartral1 is having extreme difficulties in determining what the bit depth of the originals are 23.58.42 # * gartral1 found a clue in registered PPI