--- Log for 09.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 6 days ago 00.00.55 # pixelma: the problem is, that we as developers are too familiar with those words, so we are bad a creating good description for users.. 00.01.21 # wincent: so hopefully you'll be able to remove all fp code from performance sensitive parts of pd? 00.01.36 # i just cant image a better word for the place where your device is connected, which fits mac/linux/windows. 00.01.55 Quit jgarvey ("Leaving") 00.02.40 # flyback: my point is that if no one is working on a port to your device then it is not a good bet that there will be a port to your device 00.02.44 # unless you're planning to do it 00.03.09 # I understand that 00.03.11 # does it need to be "mount point" there too? Although I guess for bootloader installing things on the player there should be some precision... 00.03.14 # I have no problem with that :) 00.03.40 # saratogalab: It's done already. I wanted to say that the performance of one oscillator is already tested. Most likely the system is much more capable, only I have not tested it yet. 00.04.07 # wincent: so what does the floating point code actually handle? 00.04.54 # saratogalab: Control signals, like the value of frequency for an oscillator. 00.05.14 # saratogalab: In the example it is a constant. 00.05.34 # pixelma: if you think you can improve the texts, please do it :-) 00.05.51 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 00.06.07 # wincent: are you sure that doesn't impose a performance cost? likely that value would be feed into a call to cos(), which will be extremely painful on ARM 00.06.21 # or does the code implement its own fixed point trig functions? 00.06.30 # domonoky: not sure I actually can but I'm trying to keep that in mind 00.06.33 Quit barrywardell (Remote closed the connection) 00.07.24 # pixelma: i also appreciate non-code patches, just tell us the dialog/desciription and the new text :-) 00.08.59 # the German translation of "mount point" though... it was even less descriptive to me but I don't know of many "clean" German computer terms... 00.09.01 Quit LambdaCalculus37 ("This computer has gone to sleep") 00.09.51 Part flyback ("Leaving") 00.10.23 Join mt [0] (n=mt@41.233.150.185) 00.10.44 Join webguest45 [0] (n=4d152cbc@gateway/web/cgi-irc/labb.contactor.se/x-61a6c4641c81f681) 00.11.16 # saratogalab: It converts the frequency value from floating-point to fixed-point one, using a floating-point addition and a shift. The oscillator itself uses a very big cosine table. 00.11.27 Quit Zagor ("Clint excited") 00.11.49 # wincent: so basically you only do floating point when something changes? 00.11.52 Quit webguest45 (Client Quit) 00.12.11 # saratogalab: Also, I implemented a floating-point sine and cosine as polynoms. 00.12.54 # gevaerts: Yes. And it changes mostly when doing something in GUI, which is not implemented yet. 00.13.30 # * gevaerts always knew that GUIs slow things down! 00.13.57 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 00.14.08 # gevaerts: Of course! And AUIs do not! :-) 00.16.05 # yay, adc on meizu works (really easy though) 00.17.01 # bertrik: Do you mean the audio adc, or the other? 00.17.14 Quit HBK () 00.17.40 # linuxstb, the other, the one that reads battery voltages and such 00.18.33 # bertrik: if you get stuck without a nand driver, maybe the ramdisk driver can help 00.18.39 # I wonder if I should use more interrupts and less polling ... 00.19.06 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 00.19.53 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 00.20.37 # I mean simple interrupts where we go to sleep while waiting for the hardware and let the interrupt wake us up 00.20.52 Quit martian67_ (SendQ exceeded) 00.21.28 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 00.26.54 # gevaerts, I'm quite sure now that the nand/ftl will be the point to get stuck 00.28.44 Quit martian67 (Connection timed out) 00.30.01 # bertrik: if you manage to get the main rockbox binary running with usb, you can use the ramdisk driver to get a full rockbox on it to work on plugins and codecs. it needs some tricks in main.c (basically enable early USB for software USB), but it works 00.31.03 # ah, interesting idea! 00.31.47 # I've done it at some point on my ipod mini 00.31.48 # like give it 2 MB RAM for running rockbox and 14 MB for the RAM filesystem 00.32.10 # yes. I'd probably go for 8/8 or 4/12, but that's the general idea 00.33.25 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 00.33.52 Quit domonoky (Read error: 104 (Connection reset by peer)) 00.33.53 # bertrik: have you seen http://www.iphonelinux.org/index.php/Critical_Drivers#NAND_.28Partially_Done.29 ? seems they have "enough of the FTL that we can read from the filesystem"... 00.33.58 # The only problem is that it's not persistent, and it's bigger than the nor flash, so you have to fill it over usb 00.34.11 # I was also toying with the idea of replacing the RAR in the DFU image with a rockbox binary 00.34.44 # shotofadds, I knew iphones also used whimory, but didn't know they were already that far 00.35.00 Quit mcuelenaere () 00.35.01 # netiher did I, I just used the power of Google ;) 00.35.21 Quit martian67_ (Read error: 104 (Connection reset by peer)) 00.35.25 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 00.35.40 Quit ender` (" Some people like my advice so much that they frame it upon the wall instead of using it. -- Gordon R. Dickson") 00.37.04 Quit shotofadds ("Leaving") 00.37.36 # well, let's do that part last, maybe the iphone people figure out more ! :P 00.39.43 Nick Lazatar is now known as martian67 (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 00.39.47 Join AndyI [0] (i=AndyI@212.14.205.32) 00.45.00 Quit tessarakt ("Client exiting") 00.50.30 # http://rockbox.pastebin.ca/1488935 call for opinions (regarding create_numbered_filename()) 00.51.04 Part Llorean 00.51.15 Quit AndyIL (Read error: 110 (Connection timed out)) 00.52.53 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 00.54.39 *** Saving seen data "./dancer.seen" 00.54.56 # amiconn: What does it change? 00.56.23 # BTW, why is that function in firmware? hwcodec recording? 00.57.35 # It changes the behaviour so that it catches pre-existing numbers regardless of length 00.57.42 # amiconn: I think it makes sense 00.58.50 # linuxstb: things like if it's considering to write "file01.whatever" and "file1.whatever" is already there, it will go on to 2 00.59.40 # It was moved to firmware/ because screendump uses it, and was also moved to firmware/. See http://svn.rockbox.org/viewvc.cgi?view=rev&revision=19967 01.05.41 Quit krazykit (Remote closed the connection) 01.05.51 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 01.21.42 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 01.26.52 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 01.26.54 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.29.50 # New commit by 03amiconn (r21732): Numbered filename creation: Make the search for pre-existing files independent of the requested number length. This way it will also increment ... 01.31.33 Quit kachna|lappy (Read error: 104 (Connection reset by peer)) 01.31.53 Join kachna|lappy [0] (n=kachna@84.42.177.178) 01.36.16 Join JdGordon| [0] (i=ad7efd83@gateway/web/freenode/x-a95b1f07f8ee3e84) 01.39.29 Quit n00b81 ("Leaving") 01.39.36 Quit Stephen_ ("Leaving") 01.40.50 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 01.41.41 Nick n00b81 is now known as n00b81|afk (n=taylor@unaffiliated/n00b81) 01.42.44 Quit Thundercloud (Remote closed the connection) 01.45.05 # Hmm, new build system shows slightly different deltas from classic one. The deltas seem to be somewhat broken in the new system still. See e.g. ipod G3... 01.50.17 # slightly different deltas happen in the old build system as well 01.50.27 # Depending on which client built 01.50.31 # a missing delta is more worrying though 02.02.01 Quit HellDragon (Read error: 104 (Connection reset by peer)) 02.02.13 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 02.04.40 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 02.06.23 Quit AfterDeath (Remote closed the connection) 02.06.28 Join AfterDea1h [0] (n=icxcnika@freenode/weird-exception/network-troll/afterdeath) 02.10.42 Quit JdGordon| (Ping timeout: 180 seconds) 02.14.56 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 02.16.08 Quit martian67_ (SendQ exceeded) 02.17.16 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 02.19.27 Quit efyx_ (Remote closed the connection) 02.19.36 Quit martian67 (Connection timed out) 02.20.32 Nick martian67_ is now known as martian67 (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 02.21.46 Quit krazykit ("Connection reset by beer") 02.22.03 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 02.22.52 Quit robin0800 ("Leaving") 02.40.35 Join notByan [0] (n=notByan@logo.csl.mtu.edu) 02.40.55 # has anyone heard of an issue where the person has to use the official firmware for usb transfer to work? 02.42.05 # if I plug it into the USB while on rockbox, it boots up that black and white apple stuff and anything trying to access the drive becomes unresponsive until it is disconnected 02.42.11 # this is a 5.5G ipod 02.47.24 # and this only happens about 50% of the time. 02.47.33 # seems like more often than that lately 02.54.42 *** Saving seen data "./dancer.seen" 02.54.59 Quit rodpod (Read error: 104 (Connection reset by peer)) 03.00.22 Join Best_ [0] (n=JanM@cm-84.215.103.194.getinternet.no) 03.09.10 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 03.12.54 Quit krazykit ("Connection reset by beer") 03.13.32 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 03.14.09 # is there any known issues with the svn ams bootloader? 03.14.20 # do i need to get the branched one? 03.17.57 # JdGordon: they should be the same aside from the version string 03.18.30 # ok, just making sure.. dont want to brick my new toy :p 03.18.59 # * JdGordon really wishes it had microSD though 03.19.23 # JdGordon: you can't really brick a sansa by using a bad bootloader, the dual boot code is built into mkamsboot, not the bootloader 03.19.33 # ok sweet 03.19.37 # so you should be able to recover even if you flash a blank bootloader 03.20.04 # does anyone need bits for a 5.5g video? it doesnt turn on but the lcd and batt are fine (presumably) and hdd is good 03.20.08 # and there's always manufacturing mode 03.20.20 # dz: you're thinking of the e200 03.20.23 # ah, true 03.20.45 # I was thinking the rest had that too 03.21.19 # dz: none of the AMS players have it, its a feature on PP only 03.21.32 # ah, I completely missed the AMS bit 03.22.55 # perhaps the fuel fumes are messing with my head 03.28.10 Join hd [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 03.28.12 Quit hd (Read error: 104 (Connection reset by peer)) 03.33.30 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 03.35.30 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 03.57.44 Quit notlistening (Remote closed the connection) 04.02.59 Quit HBK (Read error: 104 (Connection reset by peer)) 04.03.21 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 04.09.34 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/freenode/x-f7b33c431190b18c) 04.16.00 Nick n00b81|afk is now known as n00b81 (n=taylor@unaffiliated/n00b81) 04.17.12 Quit n00b81 ("Leaving") 04.19.48 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 04.30.36 Quit HellDragon (Read error: 104 (Connection reset by peer)) 04.32.21 Quit CaptainKwel (Remote closed the connection) 04.33.24 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 04.44.04 Quit HellDragon (Read error: 104 (Connection reset by peer)) 04.44.10 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 04.54.45 *** Saving seen data "./dancer.seen" 04.59.56 Quit LambdaCalculus37 ("This computer has gone to sleep") 05.05.40 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 05.09.45 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 05.13.47 Quit luke_dozen (Read error: 110 (Connection timed out)) 05.14.14 Join luke_dozen [0] (n=dash32@p54AB6AA0.dip.t-dialin.net) 05.21.19 # what do people think about trying to mostly eliminate -mlong-calls on ARM targets? as i understand it *most* calls could be made short, and short calls are faster, and smaller code, since they eliminate a load-from-memory for the function address... 05.21.54 # whats the down side? 05.22.21 Join _lifeless [0] (n=lifeless@188.16.67.103) 05.23.01 Quit HBK (Read error: 104 (Connection reset by peer)) 05.24.19 # JdGordon: the down side is that calls that are "too far" must be made long calls. on the beast at least, this means calls between iram and dram (call site is in one, target function in the other). such calls would need to be explicitly made long... jhmikes had worked up a long call macro for this purpose a while ago, while trying to make a specific function short-called, because there were a few places where it couldn't be. 05.24.38 # Unhelpful: I thought funman did that along with the mmu/dcache patch, is there something that leads you to beleive he did not? 05.25.33 # FlynDice: did he? it looks like many arm targets still use it... 05.25.56 # or are those specifically the MMU-less ones? 05.27.00 # He rearranged the iram and dram virtual addresses to get rid of the long calls I think, I could be mistaken but I beleive it is so. 05.28.08 # well for AMS he did, I am rather single minded... 05.29.18 # it looks like for the gigabeats long calls are gone. they are still there for all arm9 targets (i think none of these are supported?) and for any arm7tdmi target that doesn't call arm7tdmicc with a "short" argument in tools/configure 05.29.43 # the only target that uses arm7tdmicc short is ifp7xx 05.30.12 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 05.31.19 # i'm assuming we *can't* do short calls everywhere via address fixing on the remaining arm7 targets, but it would still be possible if it's only an issue for iram<->dram calls to use a long call macro that is defined to do nothing special on other targets 05.31.20 # rasher: ping? 05.36.33 Quit martian67_ (SendQ exceeded) 05.38.18 Quit martian67 (Read error: 110 (Connection timed out)) 05.41.23 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 05.43.38 Quit luke_dozen (Remote closed the connection) 05.43.54 Join thon0925 [0] (n=matthew@cpe-24-94-55-248.stny.res.rr.com) 05.44.50 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 05.45.17 Join luke_dozen [0] (n=luke_doz@p54AB6AA0.dip.t-dialin.net) 05.51.07 Quit Horscht ("Verlassend") 05.52.38 Quit ej0rge (Remote closed the connection) 05.53.00 Quit martian67_ (Remote closed the connection) 05.53.19 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 05.53.24 Quit HBK () 05.54.01 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 06.00.06 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.00.40 # anyone know what the story with the clip keymap is? it seems to be a bit wierd on first use? 06.01.12 Quit mt (Read error: 104 (Connection reset by peer)) 06.01.18 # It is a bit weird, yes. It's a bit hard to improve it well. 06.01.34 Join mt [0] (n=mt@41.233.150.185) 06.02.33 # I find it odd that a button has been assinged for the rec screen which isnt enabled... 06.02.58 # That is weird, yes. 06.03.00 # Didn't know that. 06.03.02 # Which button? 06.03.10 # long home 06.03.13 # Ah 06.03.26 # based off the e200 keymap apparently 06.04.33 # eek, its a mess :p 06.04.47 # I want a go to wps button, but home doesnt really work there 06.05.10 # Yeah. 06.05.25 # I really think we should co-opt the volume buttons for lists. 06.05.33 # I was thinking the same 06.05.40 # But there have been some arguments against it. 06.05.47 # with an option so users can use them for volume if wanted 06.06.04 # they are a bit hard to reach in the right hand though 06.06.12 # You could even have a combination to use them for volume. Long-home could maybe do that? 06.06.40 # probably not.. buttons are too close 06.06.42 # together 06.06.50 # I'm still not sure why 2d scrolling (i.e. text input box) works the way it does on the e200, speaking of keymaps 06.07.39 # the keyboard doesnt work at all on wheel targets... 06.08.31 Part thon0925 06.09.42 # Llorean: do you know if home can be used in combos with the directions? 06.09.55 # JdGordon: No clue. 06.10.25 # I'm tihnking home+up for WPS, home+down for quickscreen 06.10.45 # I wouldn't object to that if it works. 06.12.00 # * JdGordon forgot how paintful modifying keymaps was 06.13.06 Join mt__ [0] (n=mt@41.233.150.185) 06.13.12 Quit mt (No route to host) 06.13.43 Join n17ikh| [0] (n=n17ikh@c-68-59-19-150.hsd1.sc.comcast.net) 06.19.36 # hrm, actually, i think this can be made *fairly* non-invasive if we just add an __attribute__((long_call)) to ICODE_ATTR on targets that currently use -mlong-call. doing that and removing -mlong-call should remove quite a few long-calls, though possibly not quite all that could be removed. 06.26.03 Quit n17ikh (Success) 06.43.03 Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") 06.43.43 Quit luke_dozen (Remote closed the connection) 06.47.53 Quit martian67_ (Read error: 60 (Operation timed out)) 06.50.29 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 06.53.15 Quit n17ikh| () 06.54.49 *** Saving seen data "./dancer.seen" 06.58.59 Join n17ikh [0] (n=n17ikh@c-68-59-19-150.hsd1.sc.comcast.net) 07.00.29 Join Grahack [0] (n=chri@82.227.106.100) 07.00.42 Quit mt__ (Read error: 113 (No route to host)) 07.03.58 Join _Auron_ [0] (n=DarkAuro@adsl-99-170-79-85.dsl.rcsntx.sbcglobal.net) 07.10.36 Quit martian67_ (Connection reset by peer) 07.10.54 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 07.24.21 # ugh. the long_call attribute makes pointers incompatible :/ 07.26.06 # that, and the need to make sure anything with IBSS_ATTR has LC_ATTR wherever it's declared makes this a bit more invasive than i'd hoped 07.26.12 Join drteazy [0] (i=18f2ef5f@gateway/web/freenode/x-6cab764945c2a46b) 07.26.21 # woo 07.27.59 # woo, indeed. need anything? 07.28.57 # I guess my Sansa e260 is jacked up. One day, I plugged it in to find the dreaded "USB Device Not Recognized" error. I thought it was the cable so I bought another and no go. Now, I have a question - I booted in to Recovery Mode and it said "PC Communication: Fail". Probably not good, eh? 07.29.34 Quit r0b- (Read error: 60 (Operation timed out)) 07.30.08 # oh and another thing. I managed it to get it to be recognized in Windows the other day, but oddly the transmission speeds were awfully slow. 07.30.42 # it starts rockbox normally? 07.30.58 # Yes 07.31.11 # it works great. Just cant connect to my Dersktop add/delete files. 07.31.22 # err, Desktop. 07.32.28 # you could try starting the sansa firmware to do usb transfers. *if* the problem is in rockbox USB, that should still work. otherwise, the problem is either with your player, or your OS. 07.32.54 # Upon connecting the device to my Desktop, usually one of two things happens: 1) absolutely nothing (no "USB Device" errors, no device listed in My Computer) and 2) the "USB Device not recognized" error, coupled with an Unknown Device in Device Manager. 07.32.56 # ok. 07.33.06 # How would I go about booting to the original firmware? 07.33.25 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 07.33.25 Quit pixelma (Nick collision from services.) 07.33.39 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 07.33.44 Quit amiconn (Nick collision from services.) 07.33.46 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 07.34.08 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 07.34.13 # check the sansa manual for that - they're linked from www.rockbox.org 07.34.20 # k. 07.34.35 # thank u 07.36.07 # it should be in the "Quick Start" section :) 07.43.06 # how is the manual going to help with that? he doesn't have the rockbox bootloader installed? 07.43.19 # oh, rockbox manual for Sansa 07.43.54 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 07.50.10 # drteazy: should be left arrow/rewind in the bootloader 07.50.49 # I got it. Thanks fellers. 07.51.08 # this thing is totally jacked up. I think I need a new Sansa. 07.51.54 Join __lifeless [0] (n=lifeless@188.16.67.103) 07.52.40 # anyone recommend a solid MP3 player (aside from the apple ones)?' 07.53.02 # I could get another e260, but that would be b-orrring. 07.58.20 # drteazy: http://rockbox.org/wiki/BuyersGuide I quite like my e200 and Gigabeat S (though that's not a supported target yet, and the battery life is sucky compared to others). If you want to watch videos, the iPod Video can be a hassle for that 'cause Rockbox can only run them at about 15fps. 08.07.51 Quit _lifeless (Read error: 113 (No route to host)) 08.09.33 # UGH. can't force gcc-inserted memset/memmove/memcpy calls to be long calls. 08.15.40 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 08.16.23 # Unhelpful: Gcc is weird wrt short/long calls on arm. Imo it is not possible to get rid of long calls on arm targets where memory can't be mapped close enough 08.17.31 Quit kachna|lappy (Read error: 113 (No route to host)) 08.17.47 # I mean getting rid of more long calls than would be necessary 08.18.54 Join Dauron [0] (n=DarkAuro@adsl-99-170-79-85.dsl.rcsntx.sbcglobal.net) 08.19.09 Quit _Auron_ (Read error: 54 (Connection reset by peer)) 08.19.15 # For this to work properly, gcc would need to take both the section of the caller and callee into account so that one could specify those section pairs which need long calls, but it doesn't do that 08.19.17 Nick Dauron is now known as _Auron_ (n=DarkAuro@adsl-99-170-79-85.dsl.rcsntx.sbcglobal.net) 08.19.20 # the only way i can see at this point is to insert our own memset/memcpy/memmove calls... but then somebody could add code that introduces a new auto-call to one of them, and it will be broken for no reason they're likely to understand. 08.20.09 # or to use a solution like the mem function wrappers that the plugins used to have 08.22.35 # * amiconn accepted that there is no solution to this using gcc quite a while ago 08.22.46 # Maybe gcc 8.0 will allow that... 08.25.43 # It's not like all functions are long called atm. Static functions are always short-call. This is a gcc bug and the reason why STATICIRAM exists 08.27.08 # no, i'm getting the impression we couldn't drop -mlong-call. we could go the ridiculously invasive route, and add short_call attributes everywhere, and use a macro to perform explicit long calls when calls cross in/out of iram. to get a benefit out of that we'd end up having to go through adding those attributes to every non-static function, though. :/ 08.30.23 Quit drteazy ("Page closed") 08.30.44 # Unhelpful: I'm not expert, but could the short calls be bundled into one location and wrapped with a #pragma no_long_calls instead ? 08.30.52 # s/not/no 08.31.13 # instead of adding short_call attributes to them all individually ? 08.36.27 # The fundamental flaw here is that gcc only looks at single functions, not at caller/callee pairs 08.37.12 # An iram function could be short-called from another iram function, but must be long-called from a dram function. 08.37.25 # Same for the opposite direction 08.37.42 # amiconn: yes, but if we can easily mark the bulk of functions as short-called, that leaves a fairly small number of cases to fix up. and as long as gcc-inserted mem* calls are affected by -mlong-call... 08.39.00 Quit safetydan ("Leaving.") 08.41.11 # jhmikes had worked up a long-call macro a while ago, because he'd wanted to flag some particular function as short-called, but had one instance where it needed a long call. it's, um, more than a little ugly, but you get the same asm out of gcc with it as you would if the function were labeled as long-called 08.42.34 Nick J-23|away is now known as J-23 (n=zelazko@unix.net.pl) 08.42.37 # it's non-trivial get gcc to call a function by address when it thinks it should call it by offset. he and i both tried a number of approaches and never came up with a pure-C approach - in the end it took an inline asm with "ldr %0, =function" that assigned its address to a pointer. 08.43.59 # hmm 08.44.26 # Just a quick idea - would it be possible to have a macro that turns an ordinary function call into a call-via-pointer? 08.44.53 # that is pretty much exactly what i have.... let me pastebin the ugly thing, just a sec 08.44.56 # Calling a function pointer is essentially a long call 08.45.30 # You need a pointer of the correct function type - and in an automatic way 08.46.44 Quit BHSPitMonkey ("Ex-Chat") 08.46.53 # yes, and it's pretty easy to do that with inline ASM, if you abuse statement expressions and typeof 08.46.53 # http://pastie.org/539686 08.47.28 # basically L_CALL(func) produces a pointer to func that you can call without gcc replacing it with a short call 08.47.40 # and without gcc generating any weird extra code compared to a normal long call 08.50.07 # rasher: how much of your itunes patch is specific values for the mini? I did the changes for ata-sd-pp.c in ata.c (doing this on the 5.5g) and dmesg shows a mini trying to connect but it doesnt get a ums connection at all.. and I dont know if rockbox freezes or crashes, but it needs to be reset after disconnect 08.50.10 Join ender` [0] (i=krneki@84.255.206.8) 08.50.46 # JdGordon: You'd need to ask gevaerts - it's his thing, I just tested and put the patch on FS 08.50.56 # oh, ok 08.51.03 # He's going to kill me for saying that though 08.53.14 # if that #pragma can be used to force all explicit function calls to be short, it shouldn't be hard to add L_CALL() around the ones that we know cross in or out of iram. and of course L_CALL could be a no-op for platforms where it's not needed. 08.54.22 Join Rob2223 [0] (n=Miranda@p4FDCC4F0.dip.t-dialin.net) 08.54.50 *** Saving seen data "./dancer.seen" 08.55.33 # * JdGordon will annoy gevaerts about it tomorow :) 08.56.56 # a quick test shows that that should work. it may work better than we want it to, as apparently putting it in some always-included header will lead to it being impossible to force long call except by using an explicit function pointer. it even disables the long_call attribute, it would appear. :) 09.00.22 # Why do you need the asm at all? 09.01.41 # * amiconn admits that he doesn't understand that thing completely 09.02.00 # i tried just producing a pointer to the function in the statement expr. gcc converts that to a short call. casting to uintptr_t and back also still gets you a short call, even if the uintptr_t is a separate temp variable. 09.02.30 # it seems to be much smarter than we'd like in this case... which is funny considering how often it can fail to figure out similar problems. 09.02.52 # Hmm, that's a block... 09.03.12 # Did you try including the function's arguments in the macro? 09.03.40 Join bagder_droid [0] (n=52b61a05@gateway/web/cgi-irc/labb.contactor.se/x-0e523c7a63aecaef) 09.03.45 # and just calling the pointer that i create with __VA_ARGS__? i can try :) 09.03.56 # yes 09.04.51 # Another thing to try would be using the volatile qualifier for the pointer variable. This should stop gcc from converting the call, unless there's a bug 09.05.29 Quit bagder_droid (Client Quit) 09.05.29 # that added extra code compared to a normal long call... although i must confess i'm not sure that i had the volatile in the right place. 09.06.26 Join dfkt_ [0] (n=dfkt@chello062178002170.1.11.univie.teleweb.at) 09.06.42 # Such manual solution have a fundamental problem anyway: they become ugly very quickly 09.07.07 Part _Auron_ 09.07.14 # We have code where some functions are in iram on one arm target, but in dram on another, for performance and/or iram size reasons 09.07.44 # These places need ifdefing the macro (or maybe we accept a few extraneous long calls) 09.08.10 # (the macro *call* of course) 09.09.26 Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) 09.11.41 # naturally gcc is going to make i liar out of me... i apparently have it working with a simple copy of the pointer, by atting the long_call attribute to the copy's declaration. 09.12.20 Quit dfkt (Read error: 60 (Operation timed out)) 09.12.27 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.13.20 Quit yosafbridge ("Coyote finally caught me") 09.13.41 Join yosafbridge [0] (n=yosafbri@ludios.net) 09.18.12 # this appears to work properly: http://pastie.org/539708 09.18.13 # removing the attributes causes gcc to use a short call 09.18.48 Join bagderoid [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 09.21.56 # trying this Android irc client... 09.22.28 # * rasher suggests bagderoid is in the wrong channel 09.23.23 # are there any C files that *don't* include config.h (or something else that includes it)? 09.23.25 # * GodEater likes bagderoid's nick 09.26.35 # Unhelpful: Does that also work for static functions? 09.28.07 Quit Thundercloud (Remote closed the connection) 09.28.43 # amiconn: as a replacement for the STATICIRAM hack? i'm not sure. i'm just testing with a c file that declares a few externs, and a few functions that do nothing but call them. 09.31.24 # the simple pointer-copy version doesn't work with a static function 09.35.51 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 09.35.57 # the inline-asm version works with a static function as well... and generates identical code to a call to an extern long_call function 09.43.32 Quit bagderoid (Remote closed the connection) 09.43.33 Join robin0800 [0] (n=robin080@81.98.157.181) 09.45.05 # ok, i added a firmware/export/shortcalls.h with #pragma no_short_calls in it, and arm7tdmicc adds a -include shortcalls.h along with -mlong-calls... which of course leads to relocation errors, but i knew it would take hand-work to get the long calls forced where they're needed. 09.45.59 # just adding the #pragma to config.h got me warnings about conflicting definitions - obviously it's *not* always included. 09.53.02 # if i know that *all* calls to a function should be long, is it cleaner to change the pragma around its definition, or to L_CALL all of the calls to it? 09.56.46 Join rodpod [0] (n=rod@74-133-38-196.dhcp.insightbb.com) 10.10.28 Quit cool_walking_ (Ping timeout: 180 seconds) 10.12.47 # * bubsy eats GodEater 10.14.51 # * GodEater hopes bubsy gets indigestion 10.15.08 # do go on, think thoughts inside my body 10.15.10 # it won't help 10.15.13 # you're dead soon :> 10.15.27 # * scorche thinks bubsy has the wrong channel 10.15.48 # * bubsy thinks scorche thinks too much 10.16.51 # bubsy: what i meant by that is that this channel is reserved for discussion about Rockbox...we have another channel for people to discuss social/offtopic items 10.17.16 # Yeah, I comprehended that, but somehow I didn't register it 10.40.21 # Unhelpful: The inline asm version looks like it's doing double assignment 10.49.39 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 10.50.16 Quit kachna|lappy (Read error: 110 (Connection timed out)) 10.51.46 # amiconn: really? nothing like that happened with my test case, it looked exactly like the code generated by other long calls 10.54.20 # the asm generated in rockbox appears sane to me, as well, but gcc is making trouble... it's not putting its generated constants pool close enough to the loads from it. :/ 10.54.54 *** Saving seen data "./dancer.seen" 10.56.29 Join einhirn [0] (n=Miranda@139.174.4.164) 10.57.07 # http://pastie.org/539760 from apps/codecs/sid.c 11.01.36 # i'm not sure what's up with the mov r5, r6 though... i can't find that it uses the saved value again. 11.11.17 Quit J-23 ("wszedłem") 11.13.14 # Unhelpful: In http://pastie.org/539686, the line declaring _ptr assigns to it, and the asm statement assigns to it again 11.13.37 # I think that gcc optimises the first assignment away, but then you shouldn't write it in the first place 11.13.55 --> "ident nec01nec" received from checkup (n=strac02@194.55.1.242) 11.16.55 Join kachna [0] (n=kachna@r3g248.net.upc.cz) 11.18.05 # oh! i see what you mean. i have that fixed on my end already, but there's still the constant pool problem, which is pretty much a stopper for that version of L_CALL. and the simple assign-to-temporary version of L_CALL produces a short call if the no_long_calls pragma is in effect :/ 11.18.42 # Solution: do not use #pragma. 11.19.41 # which gets us back to explicitly marking any function for which we want short calls, with an attribute. 11.19.43 # gcc is already buggy enough without it 11.19.46 Quit GodEater (Remote closed the connection) 11.20.04 # Why? Just remove -mlong-calls 11.20.32 # that's no good. gcc then generates short calls to memcpy and friends. 11.21.19 # Even if they're declared with __attribute__((long_call)) ? 11.21.54 # as far as i can tell its generated calls to them only care about the compiler flag. 11.22.21 Join GodEater [0] (n=bibble@bb-87-80-121-64.ukonline.co.uk) 11.23.18 Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) 11.24.11 Join J-23 [0] (n=kvirc@a105.net128.okay.pl) 11.24.45 # the temporary-pointer version works in *any* case if i make the pointer volatile, but it generates some rather ugly excess code 11.24.48 # When I ACTION_STD_NEXT in the file browser, I select the next file. Now if I ACTION_STD_NEXTREPEAT, it scrolls down slowly and then faster. Could someone tell me where is this 'faster' thing is implemented in the C code ? 11.25.57 # it uses a pc-relative load to get the address, but then it moves the stack pointer (as a separated sub instruction), stores the address to the stack, reads it back from the stack, and then does the call. 11.26.22 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 11.26.33 # and then uses an add to increment the stack pointer again. ick. 11.34.52 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.35.48 Quit kachna (Read error: 110 (Connection timed out)) 11.54.52 # amiconn: double-checked with a short function that uses a char array with a short string initializer. gcc generates a memset call for this, and it only respects the command-line option for how to call it. adding a declaration for a long_call memset changes nothing, gcc still produces "bl memset" for the call 11.57.55 Join TheSeven [0] (n=theseven@dslb-084-056-150-026.pools.arcor-ip.net) 12.05.07 # it's a shame that there's not a pragma that operates on the call the same way that long_calls/no_long_calls operate on the declaration... could just use that with _Pragma() and L_CALL wouldn't need any weird hacks. 12.11.46 Quit J-23 (simmons.freenode.net irc.freenode.net) 12.11.46 NSplit simmons.freenode.net irc.freenode.net 12.11.46 Quit yosafbridge (simmons.freenode.net irc.freenode.net) 12.11.46 Quit linuxstb (simmons.freenode.net irc.freenode.net) 12.11.46 Quit archstech (simmons.freenode.net irc.freenode.net) 12.11.46 Quit Zambezi (simmons.freenode.net irc.freenode.net) 12.11.46 Quit crashd (simmons.freenode.net irc.freenode.net) 12.11.46 Quit avacore (simmons.freenode.net irc.freenode.net) 12.11.46 Quit Bagder (simmons.freenode.net irc.freenode.net) 12.11.46 Quit kachna|lappy (simmons.freenode.net irc.freenode.net) 12.11.46 Quit timc (simmons.freenode.net irc.freenode.net) 12.11.46 Quit DarkDefender (simmons.freenode.net irc.freenode.net) 12.11.46 Quit notByan (simmons.freenode.net irc.freenode.net) 12.11.46 Quit jordan` (simmons.freenode.net irc.freenode.net) 12.11.47 Quit saratogalab (simmons.freenode.net irc.freenode.net) 12.11.47 Quit rasher (simmons.freenode.net irc.freenode.net) 12.11.47 Quit rvvs89 (simmons.freenode.net irc.freenode.net) 12.11.47 Quit r4v5 (simmons.freenode.net irc.freenode.net) 12.11.47 Quit kadoban (simmons.freenode.net irc.freenode.net) 12.11.47 Quit scorche (simmons.freenode.net irc.freenode.net) 12.11.47 Quit vedlith (simmons.freenode.net irc.freenode.net) 12.11.47 Quit dz (simmons.freenode.net irc.freenode.net) 12.11.47 Quit Hadaka (simmons.freenode.net irc.freenode.net) 12.11.47 Quit saratoga (simmons.freenode.net irc.freenode.net) 12.11.47 Quit bmbl (simmons.freenode.net irc.freenode.net) 12.11.47 Quit __lifeless (simmons.freenode.net irc.freenode.net) 12.11.47 Quit Llorean (simmons.freenode.net irc.freenode.net) 12.11.47 Quit trisiak (simmons.freenode.net irc.freenode.net) 12.11.47 Quit tmzt (simmons.freenode.net irc.freenode.net) 12.11.47 Quit lostlogic (simmons.freenode.net irc.freenode.net) 12.11.48 Quit fred_2 (simmons.freenode.net irc.freenode.net) 12.11.48 Quit r00s (simmons.freenode.net irc.freenode.net) 12.11.48 Quit jon-kha (simmons.freenode.net irc.freenode.net) 12.11.48 Quit rwong (simmons.freenode.net irc.freenode.net) 12.11.48 Quit Slasheri (simmons.freenode.net irc.freenode.net) 12.11.48 Quit HellDragon (simmons.freenode.net irc.freenode.net) 12.11.48 Quit rodpod (simmons.freenode.net irc.freenode.net) 12.11.48 Quit krazykit (simmons.freenode.net irc.freenode.net) 12.11.48 Quit gevaerts (simmons.freenode.net irc.freenode.net) 12.11.48 Quit DaCapn (simmons.freenode.net irc.freenode.net) 12.11.48 Quit parafin (simmons.freenode.net irc.freenode.net) 12.11.48 Quit tucsbgns (simmons.freenode.net irc.freenode.net) 12.11.48 Quit bubsy (simmons.freenode.net irc.freenode.net) 12.11.48 Quit killan (simmons.freenode.net irc.freenode.net) 12.11.48 Quit Beta2K (simmons.freenode.net irc.freenode.net) 12.11.48 Quit freqmod (simmons.freenode.net irc.freenode.net) 12.12.13 Quit sbhsu (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Erant (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Tuplanolla (simmons.freenode.net irc.freenode.net) 12.12.13 Quit obo (simmons.freenode.net irc.freenode.net) 12.12.13 Quit crwl (simmons.freenode.net irc.freenode.net) 12.12.13 Quit feisar-- (simmons.freenode.net irc.freenode.net) 12.12.13 Quit ChanServ (simmons.freenode.net irc.freenode.net) 12.12.13 Quit efyx_ (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Torne (simmons.freenode.net irc.freenode.net) 12.12.13 Quit FOAD (simmons.freenode.net irc.freenode.net) 12.12.13 Quit brndyhite (simmons.freenode.net irc.freenode.net) 12.12.13 Quit thegeek (simmons.freenode.net irc.freenode.net) 12.12.13 Quit JdGordon (simmons.freenode.net irc.freenode.net) 12.12.13 Quit fxb__ (simmons.freenode.net irc.freenode.net) 12.12.13 Quit webmind (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Neovanglist (simmons.freenode.net irc.freenode.net) 12.12.13 Quit einhirn (simmons.freenode.net irc.freenode.net) 12.12.13 Quit TheSeven (simmons.freenode.net irc.freenode.net) 12.12.13 Quit robin0800 (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Rob2223 (simmons.freenode.net irc.freenode.net) 12.12.13 Quit ender` (simmons.freenode.net irc.freenode.net) 12.12.13 Quit amiconn (simmons.freenode.net irc.freenode.net) 12.12.13 Quit pixelma (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Grahack (simmons.freenode.net irc.freenode.net) 12.12.13 Quit n17ikh (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Best_ (simmons.freenode.net irc.freenode.net) 12.12.13 Quit AndyI (simmons.freenode.net irc.freenode.net) 12.12.13 Quit patmulchrone (simmons.freenode.net irc.freenode.net) 12.12.13 Quit evilnick_home (simmons.freenode.net irc.freenode.net) 12.12.13 Quit dmb (simmons.freenode.net irc.freenode.net) 12.12.13 Quit at0m (simmons.freenode.net irc.freenode.net) 12.12.13 Quit linuxguy3 (simmons.freenode.net irc.freenode.net) 12.12.13 Quit kkurbjun (simmons.freenode.net irc.freenode.net) 12.12.13 Quit bertrik (simmons.freenode.net irc.freenode.net) 12.12.13 Quit cg_ (simmons.freenode.net irc.freenode.net) 12.12.13 Quit shadearg (simmons.freenode.net irc.freenode.net) 12.12.13 Quit AlexP (simmons.freenode.net irc.freenode.net) 12.12.13 Quit agaffney (simmons.freenode.net irc.freenode.net) 12.12.13 Quit tchan (simmons.freenode.net irc.freenode.net) 12.12.13 Quit blithe (simmons.freenode.net irc.freenode.net) 12.12.13 Quit Ridayah (simmons.freenode.net irc.freenode.net) 12.12.13 Quit redfox (simmons.freenode.net irc.freenode.net) 12.12.13 Quit FlynDice (Connection reset by peer) 12.13.02 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 12.13.29 NHeal simmons.freenode.net irc.freenode.net 12.13.29 NJoin TheSeven [0] (n=theseven@dslb-084-056-150-026.pools.arcor-ip.net) 12.13.29 NJoin einhirn [0] (n=Miranda@139.174.4.164) 12.13.29 NJoin robin0800 [0] (n=robin080@81.98.157.181) 12.13.29 NJoin Rob2223 [0] (n=Miranda@p4FDCC4F0.dip.t-dialin.net) 12.13.29 NJoin ender` [0] (i=krneki@84.255.206.8) 12.13.29 NJoin amiconn [50] (n=jens@rockbox/developer/amiconn) 12.13.29 NJoin pixelma [50] (n=pixelma@rockbox/staff/pixelma) 12.13.29 NJoin Grahack [0] (n=chri@82.227.106.100) 12.13.29 NJoin n17ikh [0] (n=n17ikh@c-68-59-19-150.hsd1.sc.comcast.net) 12.13.29 NJoin Best_ [0] (n=JanM@cm-84.215.103.194.getinternet.no) 12.13.29 NJoin AndyI [0] (i=AndyI@212.14.205.32) 12.13.29 NJoin patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 12.13.29 NJoin evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 12.13.29 NJoin dmb [0] (n=Dmb@unaffiliated/dmb) 12.13.29 NJoin at0m [0] (n=at0m@94-225-90-23.access.telenet.be) 12.13.29 NJoin linuxguy3 [0] (n=timj@adsl-68-253-212-153.dsl.emhril.ameritech.net) 12.13.29 NJoin kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) 12.13.29 NJoin bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 12.13.29 NJoin cg_ [0] (n=cromos@80.222.113.186) 12.13.29 NJoin shadearg [0] (i=arg@ipv4.panoptix.net) 12.13.29 NJoin AlexP [0] (n=alex@rockbox/staff/AlexP) 12.13.29 NJoin agaffney [0] (n=agaffney@gentoo/developer/agaffney) 12.13.29 NJoin tchan [0] (n=tchan@lunar-linux/developer/tchan) 12.13.29 NJoin blithe [0] (n=blithe@blakesmith.me) 12.13.29 NJoin Ridayah [0] (n=ridayah@173-19-228-175.client.mchsi.com) 12.13.29 NJoin redfox [0] (n=redfox2@ns351996.ovh.net) 12.13.36 Quit tarbo (SendQ exceeded) 12.13.51 Quit AfterDea1h (SendQ exceeded) 12.14.13 NJoin ChanServ [0] (ChanServ@services.) 12.14.13 NJoin efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 12.14.13 NJoin Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 12.14.13 NJoin FOAD [0] (n=dok@dinah.blub.net) 12.14.13 NJoin brndyhite [0] (n=brndyhit@206.251.250.223) 12.14.13 NJoin thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 12.14.13 NJoin JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 12.14.13 NJoin fxb__ [0] (n=felixbru@h1252615.stratoserver.net) 12.14.13 NJoin webmind [0] (n=webmind@shell.puscii.nl) 12.14.13 NJoin Neovanglist [0] (i=Neovangl@69.31.129.33) 12.14.13 Mode "#rockbox +o ChanServ " by irc.freenode.net 12.14.14 Part Grahack 12.14.55 NJoin bmbl [0] (n=Miranda@unaffiliated/bmbl) 12.14.55 NJoin DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 12.14.55 NJoin J-23 [0] (n=kvirc@a105.net128.okay.pl) 12.14.55 NJoin kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) 12.14.55 NJoin rodpod [0] (n=rod@74-133-38-196.dhcp.insightbb.com) 12.14.55 NJoin yosafbridge [0] (n=yosafbri@ludios.net) 12.14.55 NJoin __lifeless [0] (n=lifeless@188.16.67.103) 12.14.55 Join HellDragon [0] (i=jd@Wikipedia/HellDragon) 12.14.55 NJoin krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 12.14.55 NJoin notByan [0] (n=notByan@logo.csl.mtu.edu) 12.14.55 NJoin Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 12.14.55 NJoin jordan` [0] (i=gromit@78.235.252.137) 12.14.55 NJoin saratogalab [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-7d1a5c883081427c) 12.14.55 NJoin linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 12.14.55 Join rasher [50] (n=rasher@rockbox/developer/rasher) 12.14.55 NJoin timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) 12.14.55 NJoin gevaerts [0] (n=fg@rockbox/developer/gevaerts) 12.14.55 NJoin saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 12.14.55 Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 12.14.55 NJoin tucsbgns [0] (n=tucsbgns@206.251.250.211) 12.14.55 NJoin archstech [0] (n=archstec@206.251.250.215) 12.14.55 NJoin r4v5 [0] (n=r4v5@lenin.glasnost.us) 12.14.55 Join bubsy [0] (i=Bubsy@unaffiliated/bubsy) 12.14.55 NJoin kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 12.14.55 NJoin killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 12.14.55 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 12.14.55 NJoin Beta2K [0] (n=beta@d24-36-78-223.home1.cgocable.net) 12.14.55 NJoin scorche [50] (n=scorche@rockbox/administrator/scorche) 12.14.55 NJoin vedlith [0] (n=ved2@137-mi2-1.acn.waw.pl) 12.14.55 NJoin Bagder [241] (n=daniel@rockbox/developer/bagder) 12.14.55 NJoin Zambezi [0] (i=Zulu@bnc.dotbnc.se) 12.14.55 NJoin avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 12.14.55 NJoin crashd [0] (i=foobar@lostnode.org) 12.14.55 NJoin dz [0] (n=dz@alt.dissonance.nl) 12.14.55 NJoin Hadaka [0] (n=naked@kiiro.naked.iki.fi) 12.14.55 NJoin parafin [0] (i=parafin@paraf.in) 12.14.55 NJoin freqmod [0] (i=quasselg@dhcp208-240.ed.ntnu.no) 12.14.55 NJoin fred_2 [0] (i=fred@hpc-cluster.hamburgnet.de) 12.14.55 NJoin sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 12.14.55 NJoin Erant [0] (i=erant@plz.stfu.kthnx.org) 12.14.55 NJoin trisiak [0] (n=tree@chello089078243195.chello.pl) 12.14.55 NJoin tmzt [0] (n=tmzt@adsl-99-164-52-98.dsl.akrnoh.sbcglobal.net) 12.14.55 NJoin lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) 12.14.56 NJoin r00s [0] (n=ru@zentrale.profitables.biz) 12.14.56 NJoin Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 12.14.56 NJoin rwong [0] (n=ricky@www.roflwaffle.com) 12.14.56 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 12.14.56 NJoin DaCapn [0] (i=dacapn@using.your.wireless-inter.net) 12.14.56 Join obo [0] (n=obo@rockbox/developer/obo) 12.14.56 NJoin feisar-- [0] (i=jljhook@irkki.fi) 12.14.56 NJoin crwl [0] (n=crawlie@a91-156-100-168.elisa-laajakaista.fi) 12.14.56 Quit alexbobp (SendQ exceeded) 12.15.10 Join tarbo [0] (n=me@unaffiliated/tarbo) 12.15.32 Join alexbobp [0] (n=alex@ppp-70-253-66-27.dsl.austtx.swbell.net) 12.19.06 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 12.22.31 Quit J-23 ("znc") 12.22.48 Join J-23_ [0] (n=zelazko@unix.net.pl) 12.24.07 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 12.25.29 Quit LambdaCalculus37 ("Fwump") 12.28.54 Quit ChanServ (simmons.freenode.net irc.freenode.net) 12.28.54 Quit tarbo (simmons.freenode.net irc.freenode.net) 12.28.54 Quit thegeek (simmons.freenode.net irc.freenode.net) 12.28.54 Quit fxb__ (simmons.freenode.net irc.freenode.net) 12.28.54 Quit JdGordon (simmons.freenode.net irc.freenode.net) 12.28.54 Quit Torne (simmons.freenode.net irc.freenode.net) 12.28.54 Quit brndyhite (simmons.freenode.net irc.freenode.net) 12.28.54 Quit efyx_ (simmons.freenode.net irc.freenode.net) 12.28.54 Quit webmind (simmons.freenode.net irc.freenode.net) 12.28.54 Quit Neovanglist (simmons.freenode.net irc.freenode.net) 12.28.54 Quit FOAD (simmons.freenode.net irc.freenode.net) 12.29.45 NJoin ChanServ [0] (ChanServ@services.) 12.29.45 NJoin tarbo [0] (n=me@unaffiliated/tarbo) 12.29.45 NJoin efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 12.29.45 NJoin Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 12.29.45 NJoin FOAD [0] (n=dok@dinah.blub.net) 12.29.45 NJoin brndyhite [0] (n=brndyhit@206.251.250.223) 12.29.45 NJoin thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 12.29.45 NJoin JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 12.29.45 NJoin fxb__ [0] (n=felixbru@h1252615.stratoserver.net) 12.29.45 NJoin webmind [0] (n=webmind@shell.puscii.nl) 12.29.45 NJoin Neovanglist [0] (i=Neovangl@69.31.129.33) 12.29.45 Mode "#rockbox +o ChanServ " by irc.freenode.net 12.29.56 Quit tarbo (SendQ exceeded) 12.29.59 Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) 12.38.53 Join bimbel [0] (n=Miranda@unaffiliated/bmbl) 12.39.26 Join tarbo [0] (n=me@unaffiliated/tarbo) 12.42.32 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 12.50.48 Quit bmbl (Read error: 110 (Connection timed out)) 12.52.56 # opinions on having an actual feature to have bookmarks resume X seconds before the actual saved position (for the benefit of audiobooks) vs telling people to just hit rewind themselves? :) 12.54.48 Join n1s [0] (n=n1s@rockbox/developer/n1s) 12.54.58 *** Saving seen data "./dancer.seen" 12.55.35 Join barrywardell [0] (n=barrywar@79.97.85.223) 12.57.32 # Torne, as long as it can be set on or off 12.57.42 # yah, i was expecting it would be a number of seconds 12.58.18 # the only cost would be the binsize, which would be "a setting" and then probably one line of code somewhere. 12.58.45 # (assuming that it's okay to not bother to wrap to previous track) :) 13.00.22 # Torne, a setting in music to go back to the beginning of the track? 13.01.17 # a setting in bookmarks for how many seconds befor ethe bookmark to resume, i meant 13.01.37 # * Torne shrugs. I dunno if it's worth it or not tbh :) 13.03.08 Quit AlexP (Read error: 104 (Connection reset by peer)) 13.03.17 # Torne, The user would not know that for music so that would only be useful for audio books? 13.03.18 Join AlexP [0] (n=alex@rockbox/staff/AlexP) 13.03.41 # wouldn' tknow what? 13.03.52 # and yes, it's intended to be useful for audio books 13.04.39 # Torne, How long from start of track to bookmark position 13.05.06 # i don't see what the start of the track has to do with anything 13.05.17 # and it would just be *one setting* applied to all bookmarks 13.05.25 # not for each bookmark, otherwise you'd just set the bookmarks earlier :) 13.06.13 # Torne, that's where I would like the bookmark to resume from 13.06.16 Quit daurn (Read error: 113 (No route to host)) 13.06.34 # oh, you mean you'd want to set it to "beginning of track" 13.07.02 # that's trivial also, but might make it two lines :) 13.09.35 # Torne, at the moment every time you turn the dap on you have to hold rewind to do this or if possible only turn off at the end of a track 13.10.15 # this isn't anything to do with resuming playback 13.10.19 # this is specifically for bookmarks 13.11.29 # Torne, This is bookmark on stop and resume last bookmark 13.12.06 # well, whatever. i was just asking if anyone cared at all. you do :) 13.13.09 # Torne, YES IF YOU COULD IMPLEMENT IT FOR MUSIC AS WELL 13.13.41 # * Torne arghs 13.13.44 # robin0800: you do know rockbox can't tell the difference between an audiobook and music don't you ? 13.13.51 # there's no difference between.. oh there we go 13.13.57 # if it was implemented it would apply to everything 13.14.06 # sheesh 13.16.08 Join Sajber^ [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 13.18.49 Join _lifeless [0] (n=lifeless@188.16.122.181) 13.19.34 Quit bimbel (Success) 13.21.30 # Torne: one problem would be that (as far as I understand) with many codecs you can't really just tell them to go back three seconds 13.21.53 # well, you can tell them, but you can't really predict where exactly they will end up 13.21.58 # gevaerts: i don't think it would work any worse than bookmarks already do 13.22.06 Quit __lifeless (Read error: 110 (Connection timed out)) 13.22.10 # wha ti was imagining is just literally subtracting the time from the bookmark position before doing anything 13.22.18 # bookmarks also keep a byte offset I think (or was it number of frames?) 13.22.25 # really? 13.22.40 # I'm not sure, but I seem to remember they do, yes 13.22.55 # * Torne looks 13.23.16 # damn, so they do 13.23.23 # well, they keep "a big load of numbers" 13.23.43 # presumably because of that very problem with codecs 13.23.45 # I really would like the feature, I just have my doubts on how feasible it is 13.24.11 # if you tell a codec to go back three seconds is it likely to end up going back *less*? 13.24.19 # or hugely, uselessly more? :) 13.24.37 # cuz i wouldn't really care if it went back six seconds instead 13.25.16 # Torne: as I understand it the problem can be hugely exacerbated in long audio book mp3s, where you can end up going back minutes 13.25.30 # Llorean has more experience of it though I think 13.25.49 # ah. 13.27.01 # it probably violates my effort/caring ratio threshold then 13.27.10 # :D 13.27.17 Nick dfkt_ is now known as dfkt (n=dfkt@chello062178002170.1.11.univie.teleweb.at) 13.27.30 # Torne: I've tried to rewind two seconds only to end up three minutes *later* in a file 13.27.47 Nick dfkt is now known as Guest62011 (n=dfkt@chello062178002170.1.11.univie.teleweb.at) 13.28.00 Part TheSeven 13.28.47 # Llorean: ouch 13.28.54 # Yes 13.29.10 # It's quite frustrating, but apparently difficult to solve 13.29.23 # Sadly the time displayed in WPS is also somewhat unreliable. 13.29.57 Nick Guest62011 is now known as dfkt (n=dfkt@chello062178002170.1.11.univie.teleweb.at) 13.30.19 # If I seek to 2:10:22, it'll actually show a different time (sometimes several minutes different) after the seek (which is the part that confuses me most - if we end up at the wrong time in the file we shouldn't *know* it's wrong or we could correct it) 13.31.42 # * gevaerts thinks that Torne shouldn't give up on this. He should just start by fixing the codecs to seek properly :) 13.32.42 # gevaerts: you're not gonna get me like that again 13.33.02 # i'm reading the entire bloody code for the beast flash. what more do you want! :) 13.33.36 # lots :) 13.36.55 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 13.37.04 # gevaerts: Seeking's easy if you drop support for VBR mp3... 13.37.33 # let's do that then 13.37.41 # * linuxstb_ doesn't object 13.37.57 # * Llorean gets the pitchforks and torches. 13.45.16 Join Trista340 [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 13.45.27 # Unhelpful: can't you just use the MMU to map the IRAM close to the SDRAM address? (on targets that have MMU's of course) 13.46.00 # mcuelenaere: i would guess that we were already doing this on targets that have MMUs. Lots of them don't :) 13.46.02 Join Sajber^1 [0] (n=Sajber@81-235-177-115-no54.tbcn.telia.com) 13.46.21 # I don't think any of them do that, except for the Sansa AMs ones 13.46.24 # AMS* 13.50.22 # the gigabeats apparently no longer use -mlong-call, either. it looks, though, like nearly all other supported arm targets do. there's a "short" argument to arm7tdmicc to drop tho -mlong-calls option, but only ifp7xx appears to use it. 13.50.47 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 13.52.07 # it seems rather stupid that gcc can't decide whether it needs long calls based on section 13.54.30 Join KoRnAgE [0] (n=chatzill@150.204-26-211.dynamic.dsl.mel.iprimus.net.au) 13.54.36 # Heya 13.55.02 # hang on. can't you just get the linker to insert stubs using ip? 13.55.09 # Torne: even if it can, it appears to use internal delcarations for memcpy and friends. if you don't pass it -mlong-calls, it always generates short calls for these functions when inserting them automatically. 13.55.37 Quit _lifeless (Remote closed the connection) 13.55.41 # Unhelpful: it can't. it treats all functions with an explicit section as long calls, according to the docs 13.55.49 # which means it will long-call between them too even in the same section 13.56.04 # and yah, it's not going to listen to what you claim memcpy does. :) 13.56.13 # sadly it assumes you are a standard C implementation for all that kind of thing 13.57.05 # right, and the unnneed long-calls within the same region of memory are what i want to try to reduce. it may well be that the best we can hope to do is look for select often-called functions and give them a short_call attribute. 13.57.27 # ;~; *scratches head* 13.57.45 Quit Tristan (Read error: 110 (Connection timed out)) 13.58.03 # KoRnAgE: this is a development and support channel for rockbox. expect programmer talk. :) 13.58.18 # Yup ^^ I know x3 13.59.00 # erm 13.59.13 # the docs for ld say the linker automatically inserts stubs for function calls which turn out to be too far away 13.59.23 # which is as i thought :) 13.59.32 # Rockbox can view images without plugins. right? o3o I'm sorry for such a noob question but I've been pissed at how putting my photos on the ipod firmware takes up more space than my HDD :s 13.59.33 # Torne: really, the most ideal would be to re-do the calls at link time based on their actual relative addresses. i don't think that gcc is capable of modifying anything but addresses/offsets at link... 13.59.51 # Ooh, aha 13.59.53 # there we go 13.59.54 # Torne: if it's doing that, i wonder why i get so many relocation errors at link? 14.00.00 # it only works for EABI 14.00.08 # We need to fix rockbox to use an EABI toolchain then :) 14.00.30 # try changing configure to use "arm7tdmicc short" for, say, e200. ;) 14.00.32 # then you can have no long calls and it will generate them when needed at a small cost in binsize 14.01.07 # it doesn't rewrite the instructions, sadly, becaus ethat's too hard :) 14.01.53 # "Farcalls stubs insertion is fully supported for the ARM-EABI target only, because it relies on object files properties not present otherwise." 14.02.15 # well, a short call is fewer instructions, since a long one much load an address 14.02.29 # yes. 14.02.31 Quit Sajber^ (Success) 14.02.38 # it inserts stub functions which the short calls are redirected to call instead 14.02.49 # the stub loads the address of the far function into ip and then branches to ip 14.02.56 # thi sis what ip is for in the AAPCS 14.03.41 # * Torne will test this out usin ghis eabi toolchain 14.03.49 # i have no idea what issues we might face trying to build rockbox with eabi though 14.04.30 # (or how *much* binsize increase we might be talking about) 14.12.51 Join MarcGuay [0] (n=chatzill@ip216-239-79-254.vif.net) 14.13.07 Join MrDuck [0] (n=kachna@r3g248.net.upc.cz) 14.25.27 Quit DarkDefender (Remote closed the connection) 14.25.58 # well i can't get it to work 14.26.03 Quit KoRnAgE ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 14.26.04 # but variou sthings imply it should :) 14.27.52 Join MarcGuay_ [0] (n=chatzill@ip216-239-79-254.vif.net) 14.28.30 Quit kachna|lappy (Read error: 110 (Connection timed out)) 14.29.11 Join Syrius [0] (n=Syrius@unaffiliated/syrius) 14.29.15 # hello all 14.30.20 # I have restored my ipod via linux awhile back and have rockbox on it and I was wondering how do I get it to detect on windows vista that it is a storage device ? 14.30.36 # because when i use musikcube I am unable to see it 14.31.10 # it says that any portable media player is visible if windows sees it as a storage device 14.31.30 # that it would be should under the devices menu in musikcube 14.31.46 # showed* 14.32.33 # I can access it of course via windows just like any device 14.32.46 # I am just wondering why it is not showing up in musikcube 14.33.12 # I can play music from my ipod if I add the directory 14.33.19 # in musikcube though 14.33.48 # maybe I need it in disk mode 14.34.02 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/session) 14.34.35 # Syrius: Perhaps musikcube is expecting an MTP connection? 14.34.45 # When Rockbox provides a MSC? 14.36.02 # Unhelpful: OK, autogeneration of stubs on ARM requires binutils 2.19 and *possibly* to be using eabi rather than oldabi, though i'm not sure about that 14.36.23 # maybe 14.36.25 # Unhelpful: it doesn't work for me because my arm-eabi toolchain i have handy only has binutils 2.18.1 :) 14.36.33 # rockbox's is even older 14.36.48 # so i guess on that front it's back to revisiting how to get rb to build with current gcc/binutils? :) 14.36.57 # (which would probably also help compiling as thumb and various other things) 14.38.44 # maybe MarcGuay 14.39.31 # that would be cool if programs would offer a plugin to detect rockbox firmware and to treat the device as a storage device and to scan it for playable audio files 14.39.48 Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 14.39.53 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 14.39.54 # I think they should seriously do that now since rockbox is user friendly now 14.39.57 # musikcube doesn't do MTP, it works fine with MSC 14.40.00 # according to their website 14.40.05 # so something else is wrong. 14.40.10 # hmm 14.40.17 # what do you think it is Torne 14.40.28 # site says it treats any removable drive with music on equally 14.40.32 # so doesn't matter if it's rockbox or not 14.40.39 # I see 14.40.39 # Well, if it's an iPod, it may be trying to treat it as an iPod rather than straight MSC. 14.40.40 # hmm 14.40.48 # Ah, there is that 14.41.11 # how could I get it to think it is not an ipod ? 14.41.28 # in vista explorer window it shows up as removable disk 14.41.33 # website also implies that it doesn't have ipod support 14.41.35 # not as ipod 14.41.37 # but that's less clear 14.41.59 # maybe I should email them 14.42.00 # Syrius: iPods always show up as a removable disk, or should. 14.42.06 # if it shows up in windows as a disk then it's pretty much guaranteed to be the program's fault, not ours 14.42.25 # either the program is treating it as an actual ipod and looking for iTunesDB, or it's just broken in some other way 14.42.30 # well I wouldn't know I haven't used windows in years Llorean 14.42.49 # well I am not saying it is Torne 14.42.59 # yah, i'm just saying 14.43.09 # there's not a lot we can suggest other than trying to disable any ipod support it might have 14.43.17 # I just thought you guys would be knowledgeable enough to know how to fix this problem 14.43.34 # it's unlikely that anyone here has used that program, so probably not :) 14.43.38 # Unfortunately, we can't fix problems with other software. 14.43.51 # I love that program for windows 14.44.00 # Our software tries to do things "right" and hopes other software doesn't make bad assumptions, some software does. 14.44.10 # it is the best software libre program for music player I have seen for windows 14.44.32 # we're not criticising your choice of audio player :) 14.44.45 # I highly recommended it 14.44.56 # I don't like itunes 14.46.51 # do you think I should change my ipod to manually manage music in itunes Torne ? 14.47.12 # I hope that works in wine I really don't want to install that on my windows box 14.47.21 # that doesn't change anything on the ipod 14.47.25 # that's just a setting for how itunes treats it 14.47.33 # okay 14.47.43 # hmm 14.47.53 # The iTunes setting shouldn't change anything. 14.48.00 # You need to find out if your software gives special treatment to iPods, and if it does, ask them to fix it to be more strict on what it decides is an iPod. 14.48.41 # okay Llorean 14.48.51 # thanks for your help and suggestions 14.50.02 # I think it is pretty cool that I can view images and play videos on a grayscale ipod but then again their was the grayscale gameboy 14.50.17 # I still have one of those a grayscale gameboy 14.50.54 # it still works too 14.51.23 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 14.51.44 # is there anything specific stopping us from using gcc 4.x other than "some things may not build properly for the usual reasons" :) 14.52.58 # 4.x is used on a majority of archs. Om sh 4.x produces larger binaries iirc 14.53.07 # On* 14.53.57 # Llorean what media player do you use for you media device in linux also what media player do you use ? 14.54.03 # I mean media device 14.54.04 Join _lifeless [0] (n=lifeless@90.150.113.130) 14.54.44 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 14.54.55 # rasher: ok, i'm blind somewhat, though i actually mean 4.3 or whatever, but still 14.55.00 *** Saving seen data "./dancer.seen" 14.55.09 # how about a newer binutils, is the actually relevant one 14.55.50 # binutils 2.19 on ARM for automatic far call stub insertion :) 14.56.08 # Syrius: Many people here have found they don't need a media manager. 14.56.30 # so what do you use then Llorean ? 14.56.41 # do you just play them from the disk 14.56.53 # rasher: i guess i should just try it :) 14.57.01 # well I would like to play the music on my computer from the media device 14.57.23 # I already move the music to its own folder on my ipod 14.57.48 Quit HBK (Connection timed out) 14.57.59 # but I don't want to waste up memory of audio files on my computer 14.58.20 # Syrius: This channel is about Rockbox. If you're asking how to play music on your computer, that's really a question for something else. 14.58.28 # None of Rockbox's features require management software. 14.58.53 # okay 14.59.46 # yeah but rockbox allows the ipod the ability to put music in a folder on your ipod which makes accessing the music different thus that is why I am asking here Llorean 15.00.11 # it makes it the same as every other mp3 player :) 15.00.15 # because you don't need the apple itunes database file any more 15.00.51 # Syrius: But PC-side stuff like that is still off topic here. it's the same as playing music from any hard disk, internal or external. 15.01.00 # Syrius: relying on your ipod to keep your entire music collection is bad idea. You *should* keep all your music on your PC as well. Otherwise you risking losing it all one day when you drop the ipod and spack the hard drive in it. 15.01.25 # um GodEater I back it up on dvds 15.01.34 # excellent idea :) 15.02.24 # but most media player software for linux detects that it is an ipod and automatically treats it as such so then I can't play my music on it Llorean 15.02.50 # Syrius: And in every single one of those cases, you should be reporting the problem to the software provider. 15.02.56 # I am asking for a media player for linux that treats it and automatically detects the device as removable storage 15.03.21 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 15.03.31 # then scans it for audio files 15.03.39 # then makes an index file 15.03.39 Quit martian67_ (Success) 15.04.53 Quit Lazatar (Remote closed the connection) 15.05.12 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 15.05.57 # Syrius: Amarok does that 15.06.45 # the ones which detect it as an ipod cna generally be told not to, either by disabling/removing the ipod plugin or by putting a special file on the device that says what kind of player it is and wat formats it supports 15.07.21 # I don't use kde GodEater 15.07.38 # Torne: the reason that we've stuck with the gcc versions that we use is basically "they work" and the reward for an upgrade has been small to non existant, as in some cases things break, get slower/larger etc... 15.07.38 # thanks Torne 15.08.10 # n1s: right. i guess sometime i'll try and see if it seems to work with binutils 2.19 15.08.14 # btw coldfire is the only arch using 3.4 all others are 4.x 15.08.22 # Syrius: what's that got to do with it ? Neither do I. 15.08.28 # and if so then it may be possible to make it generate longcall stubs on ARM at link time 15.09.11 # because it requires kde libraries GodEater 15.09.21 # that doesn't mean you need to run kde 15.09.29 # doesn't go well with gtk 15.09.47 # Torne: i tried to build the coldfire gcc with binutils 2.19 but bumped against some incompatibilities, not that that matters for arm... 15.09.50 # I don't want to install kde libraries 15.10.06 # n1s: it might also need to be built for arm-elf-eabi instead of arm-elf :) 15.10.09 # n1s: not clear on that one 15.10.11 # it works FINE with GTK 15.10.33 # I mean it does look good 15.10.36 # GodEater: The two of you seem to be wandering further off topic 15.10.37 # it doesn't match 15.10.58 # I think it has to do with rockbox 15.11.05 # I have already explained above 15.11.10 # Syrius: it has *nothing at all* to do with rockbox 15.11.17 # * n1s still want's to try 4.4 with coldfire but it will take a whole day 15.11.23 # gevaerts you should scroll up 15.11.32 # ... to build on this netbook 15.11.39 # Syrius: He's read your explanation. You're wrong in terms of what this channel considers "on topic" 15.11.52 # hmm 15.11.58 # Syrius: you're talking rubbish. I use Amarok just fine with all my Rockboxed players, including my ipod. 15.12.19 # I don't want to use kde GodEater 15.12.26 # kde apps 15.12.53 # well I think this conversation has gone as far as it needs to then. 15.13.19 # okay Llorean 15.18.50 # * Syrius sorry guys I was being stupid I am tired also I noticed that I didn't have the show devices checked :( 15.18.58 # I solved my problem 15.21.20 # thanks Torne I also solved my rythmbox problem 15.22.03 # I disabled the ipod plugin and enabled the MTP plugin :D 15.22.32 # rhythmbox* 15.23.56 # * Syrius is a happy camper now 15.26.59 # Torne: I think the newer versions either produce larger binaries or slower code, pretty much across the line. Go figure 15.27.35 # rasher: of binutils? 15.27.54 # it shouldn't be needed to actually change gcc version now that i realised arm is already on 4.0 :) 15.28.27 # Torne: Yeah, and 4.3 or 4.4 produce slower binaries iirc. 15.28.37 # right. 15.28.56 Quit Grahack ("Leaving.") 15.29.11 # having ld 1.19 do the longcall stub trick should probably be a net win for binsize/speed though 15.29.20 # rasher: in some cases at least i think we have not seen any comprehensive benches 15.29.24 # since you can go back to -mno-long-calls 15.29.33 # and it will just put in the stubs for the cases where it's needed 15.29.42 # which is likely to be smaller and faster than having -mlong-calls for everything 15.31.32 # I'd like to commit FS#9383. any objection? 15.34.27 # teru: if it fixes the issue, why not? 15.34.56 Join _zic [0] (n=user@91-165-242-33.rev.libertysurf.net) 15.35.06 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 15.36.02 # Unhelpful: The beast has no code in iram, hence the long-call problem doesn't exist 15.36.20 # ifp7xx is able to map iram close enough to sdram, and does that 15.36.26 # New commit by 03teru (r21733): fix FS#9383 (chessclock freezes on deleting a player), patch by Yoshihisa Uchida. 15.36.33 Join Flasher [0] (n=4e343568@gateway/web/cgi-irc/labb.contactor.se/session) 15.38.06 # GodEater: reproduced the ipod DMA problems using just the one patch :) 15.38.14 # godeater could you help me use the flashwriter plugin? i can't compile it, i get all sorts of "missing *.h file" errors. where do i have to place th.c file provided in that task? http://www.rockbox.org/tracker/task/7505 15.38.21 # Torne: yay =/ 15.38.31 # GodEater: it seems very likely to be cacheline interference 15.38.39 # * GodEater wonders why he got picked out for this onerous task ? 15.38.55 Quit daurn (Read error: 113 (No route to host)) 15.38.56 # i'll have a look in the code. :) 15.39.33 # Flasher: if you can't compile that on your own, you're not the right person to be playing with such dangerous code in the first place. 15.40.35 # do i have to compile it patching svn? 15.41.53 # i though this was a promgramme on its own 15.42.31 # Flasher: seriously, if you don't know what you're doing, leave it alone. 15.43.34 # wtf i got three gigabeats it doesn't matter to me if one gets broken, so why not just help me out? i won't blame anyone if anything doesn't work anymore, it's my responsibilty 15.44.35 # perhaps because it's an involved process, and I had REAL LIFE to deal with ? 15.46.42 # i don't understand? what do you mean by involved process? i just read you had success using it, that's why i ask you. i tried contacting karl but didn't get any response. you're in the irc richt now, aren't you, so why do you tell me about real life at this moment of time? 15.50.10 Quit Flasher ("CGI:IRC (EOF)") 16.05.51 Quit rodpod (Read error: 54 (Connection reset by peer)) 16.06.19 # is there some reasonably easy way to disable the cache on PP? 16.06.26 # (just to test something) 16.08.40 # * GodEater conducts the Summoning jhMikes ritual 16.08.52 # heh, apparently i'm still blind 16.08.56 # Torne: you might want to join in =/ 16.09.08 # "comment out init_cache()" should do it :) 16.09.13 # hahaha 16.09.14 # ok 16.09.20 # * GodEater cancels the ritual 16.09.22 # i was looking too early 16.09.33 # in the asm bits 16.09.37 # and it's just not done until later :) 16.10.41 # GodEater: this is the brute force way to check if it's cache line interference :) 16.11.38 # what do you mean by cache line interference? 16.12.09 # saratogalab: the DMA code doesn't account for the memory not being cache line aligned and thus possibly containing other data 16.12.38 # depending what this other data is and when it gets accessed, the cache operations in the dma code might trash it 16.14.22 # yah. the player is unusably slow without the cache but the albumart doesn't get corrupted and it doesn't seem to crash 16.15.59 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 16.16.24 # Torne: would it be possible to round to the nearest cacheline and then truncate? 16.16.50 # saratogalab: how to do it has been discussed in the tracker, you'd just use PIO for the start and end of the copy if they weren't aligned 16.17.00 # and only DMA for cachelined aligned bits in the middle. 16.17.12 # that code just needs writing :) 16.18.01 # oh great usb doesn't work now 16.18.07 # i guess the system is too slow :) 16.18.12 # * Torne boots emergency disk mode. :) 16.26.44 # how can you check the version of rockbox from the command line Torne ? 16.26.58 # look in rockbox-info.txt 16.27.04 # has all the parameters it was built with 16.28.19 # Torne should I remove the .rockbox folder before I upgrade to 3.3 if my Version: r19569-081223 ? 16.28.46 # shoul dbe fine to jus textract it over the top 16.28.56 # okay 16.28.59 # if you removed the .rockbox folder you would lose all your settings etc 16.29.06 # yes I know 16.29.12 # okay just making sure 16.29.35 # cause I know with a lot of software it has problems if you do not first remove the software 16.29.40 # Syrius: it should always be fine to just extract over the old .rockbox 16.29.54 # I had problems with that with deluge 16.30.06 # in some rare cases of files being moved or renamed a few old will remain but it is harmless 16.30.14 # I just removed the preferenced folder and reinstalled and it was fine 16.30.35 # okay cool thanks Torne nls 16.31.23 Quit MarcGuay ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 16.55.04 *** Saving seen data "./dancer.seen" 16.56.19 Quit dmb (Read error: 113 (No route to host)) 17.00.10 Join stoffel [0] (n=quassel@p57B4F908.dip.t-dialin.net) 17.09.56 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 17.16.26 # * Torne hacks in the stats patch and tries using dma for only requests which happen to be cacheline aligned by fluke. :) 17.18.24 # Torne: that will be all USB tranfers, purely by fluke indeed :) 17.19.24 # oh, really? 17.19.29 # that's possibly quite useful then 17.19.55 Quit teru ("Quit") 17.21.49 # Torne: cbw_buffer = (void *)UNCACHED_ADDR((unsigned int)(audio_buffer+31) & 0xffffffe0); 17.22.16 # aha 17.22.23 # so i can test dma a bit like that 17.22.57 # i'm assuming cachelines are 32 bytes on PP5020? :) 17.23.40 # I think so, yes. Have you looked at http://daniel.haxx.se/sansa/memory_controller.txt ? 17.23.55 # i haven't, no 17.23.58 # and that says 16 byte cachelines 17.24.19 # i'm just Trying Things to see if i can get dma to work 17.24.53 Quit MarcGuay_ ("ChatZilla 0.9.85 [Firefox-3.5 3.5.1pre/20090704164440]") 17.29.05 # Torne: the USB thing is for similar reasons, i.e. this way it worked. And if you're using 128k buffers anyway, aligning them to 32 bytes won't waste much anyway 17.29.07 # mcuelenaere: trying to install a pure lua lib which has this structure: libname/init.lua, I noticed that the Lua plugin couldn't reach it. http://www.lua.org/manual/5.1/manual.html#pdf-package.loaders says package paths can end with `?/init.lua` so we could go `#define LUA_PATH_DEFAULT "$/?.lua;" "$/?/init.lua;" VIEWERS_DIR"/?.lua;" VIEWERS_DIR"/?/init.lua;"` in rockconf.h. Works for me. 17.29.25 # gevaerts: yeah. the problem with the ata code is it reads into all kinds of places in memory 17.29.53 # you can fiddle to get the audio buffer cache line aligned, but that won't help anything that calls read() 17.30.07 # anywya the stats patch appears to work now i've painfully resynced it :) 17.30.24 # Grahack: ok, I wondered why I removed that init part.. 17.30.28 # wonder* 17.30.39 # * Torne tries some usb to get some DMA going :) 17.31.07 # Torne: I think that if USB and the audio buffer use aligned reads, we can do things like only using dma if things are aligned 17.31.25 # gevaerts: that might be ok, yah, at least until someone is prepared to write the code to top-and-tail requests with PIO 17.32.01 # Grahack: do we want the VIEWERS_DIR"/?/init.lua;" part though? I'm not sure that putting lots of Lua libs in VIEWERS_DIR is a good idea.. 17.32.09 # * gevaerts doesn't think that "if you want performamce, align the thing" is really bad 17.32.30 # * Torne checks the stats 17.33.15 Part linuxstb_ ("Leaving") 17.34.23 # mcuelenaere: why could it be bad ? 17.34.43 Join Strife89 [0] (n=Michael@168.16.239.88) 17.35.08 # Grahack: I think putting those in a separate 'Lua' dir would be more appropriate 17.35.19 # gevaerts: ok, the audio buffer is getting DMAs about 10% of the time with the code i have here 17.35.27 # i think i need to fiddle with the buffer alignment patch 17.35.39 # the usb code does indeed do it basically all the time 17.36.05 # if i can get this looking like it's working then i'll throw it into my real build and use it for a week or two 17.36.23 Join riek42 [0] (n=erik-ubu@BAJ1a9b.baj.pppool.de) 17.38.17 # mcuelenaere: agreed, I was wondering from the start why putting actions.lua here, but where to put this Lua dir ? .rockbox/rocks/viewers/lua ? 17.39.18 # Grahack: well I didn't want to fiddle with the build system to make a separate folder etc. but now I'll take a look 17.39.49 # .rockbox/lua/ or .rockbox/rocks/viewers/lua/ sounds good to me 17.41.03 # I personaly prefer the latter 17.41.16 Part riek42 17.41.20 # so does the info on firmware/export/ata.h.orig 17.41.22 # oops 17.41.43 # so does the info on http://daniel.haxx.se/sansa/memory_controller.txt (which talks about PP5024) definately apply to pp5020? 17.41.50 # i have no idea wha tthe PP model numbers mean :) 17.42.16 # PP5022 and PP5024 are the same basically aside from the DAC 17.42.27 # Grahack: I'll look into this later, am busy atm 17.42.32 # PP5020 is an older model thats fairly close to PP5022 17.42.50 # PP5002 is the oldest and is much different and very slow, its only in the Ipod 3G and older 17.42.53 # i can't imagine an olde rone having bigger cachelines 17.43.02 # so it's probably ok to check for 16-byte alignment only 17.43.19 # i think we can only do DMA on PP5020 and abvoe anyway 17.43.26 # yeah, it's in ata-pp5020.c 17.48.59 # ok, i don't understand buffering.c :) 17.51.12 # Torne: ask 17.51.58 # * BryanJacobs thinks there should be a master's degree in Rockbox buffering 17.52.28 # BryanJacobs: i want to arrange for the buffering code's calls to the storage layer to request reads into 16-byte aligned regions :) 17.53.12 # that would be in buffering_thread 17.53.20 # look for that method 17.53.33 # probably near Q_BUFFER_HANDLE it'll call buffer_handle 17.53.44 # and then in the body of buffer_handle you'll find the storage-layer calls, eh? 17.54.26 # line 635, exactly 17.55.40 # the issue is that the read request could be for < 16 bytes and you can't just waste space in the buffer - the codecs expect contiguous regions - so you can't actually guarantee aligned reads 17.55.59 Quit Grahack ("Leaving.") 17.55.59 Quit n00b81 ("Leaving") 17.56.54 # it won't be unless it's the end of the file or the end of the buffer, though, no? 17.57.10 # correct 17.57.19 # otherwise it'll be BUFFER_DEFAULT_FILECHUNK bytes 17.57.32 # err BUFFERING_DEFAULT_FILECHUNK 17.57.54 # so it doesn't need to realign itself at any point codecs would care about 17.58.03 # as long as it was aligned correctly at the start of each handle and ata the wraparound point 17.58.48 # yes, so you could just make the memory_handle correctly sized and alter add_handle to align it 17.59.59 # is it possible to specify one font for the menu system and one for the wps? 18.00.05 # Dhraakellian: no 18.00.09 # okay 18.00.33 # then I guess it's fortunate that Plain Text VP looks okay(ish) with the built-in font 18.00.49 # * BryanJacobs would like to have a different menu font as he likes the NerdSketch theme 18.01.03 # * BryanJacobs also has good eyesight and so likes small menu text 18.01.07 # BryanJacobs: fix the multifont code to be acceptable then :) 18.01.16 # * BryanJacobs remembers that patch and shudders 18.01.20 # heh 18.01.22 # or just write a new one ;) 18.01.40 # I think I'll do the work that pays the bills first 18.01.47 # like the summer of code stuff :-P 18.01.57 # bah, being paid :) 18.02.14 # my brother likes PlainTextVP with 08-Rockfont (which I set up for him), but he wants the (larger) default helvetica for the menu system 18.02.30 # hes out of luck for now 18.02.39 # what font is the built-in? 18.02.46 # is it the same as schumacher clean? 18.03.06 # yes 18.03.14 # ah 18.03.15 # good 18.04.01 # because the PlainText VP theme specifies Schumacher Clean (although it looks better with 08-Rockfont) 18.04.24 # I like how line 1281 has "register_buffering_callback" and "unregister_buffering_callback" listed but those functions don't actually exist in buffering.c 18.07.18 # anyway, i need the *other* kind of alignment first, i think 18.07.43 # but there's already a patch for that, it's just out of date :) 18.11.18 Join toffe82 [0] (n=chatzill@74.0.180.178) 18.12.18 # well that doesn't seem to have changed anything for better or worse. 18.13.04 # no noose is good noose 18.14.23 Quit Strife89 ("Leaving") 18.14.54 Quit saratogalab ("CGI:IRC (EOF)") 18.19.40 # BryanJacobs: is it sufficient to align new_widx in add_handle to a multiple of 16 instead of 4? 18.21.33 # no, not new_widx, that's wher ethe handle gets put 18.21.49 # buf_widx, after it gets incremented by sizeof(struct memory_handle) 18.25.10 # ..ok, i'm gonna stop for now. :) 18.41.43 # is there a rule of thumb for when to use a simple polling wait loop, and when to use a wakeup_wait/wakeup_signal? 18.42.28 # bertrik: I think wakeup_wait is always preferred 18.42.43 # well of course not for very tiny microloops or so 18.44.44 # I would guess anything longer than the interrupt latency could use a wakeup* 18.55.05 *** Saving seen data "./dancer.seen" 18.58.21 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.00.11 Quit MrDuck (Read error: 110 (Connection timed out)) 19.09.21 Join ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) 19.09.32 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/session) 19.11.26 Quit robin0800 ("Leaving") 19.14.49 # Torne: until shrink_handle, yes 19.15.28 # wait... no 19.15.46 # buf_widx gets incremented as data are read into the handle 19.16.14 # so it'll be fine unless the handle is moved or shrinks 19.16.46 # if you align it there on line 252 you guarantee that every new handle is created with its data on a 16-byte alignment 19.18.28 # however, if you call read(),bufadvance(),shrink_handle(),and read(), the last read won't necessarily be aligned 19.19.27 Quit flydutch ("/* empty */") 19.22.25 # mcuelenaere, we currently use busy loops for i2c on meizu and ams sansa, those could take up to 75 us 19.22.38 Quit KBH () 19.22.50 # more like, _at least_ 75 us 19.23.04 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 19.23.46 # and I think a full LCD update on the fuze or e200v2 for example takes 10 ms 19.23.47 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 19.25.32 # I plan to commit the adc code for the meizus tonight, maybe also some more timer code 19.25.43 Join JdGordon| [0] (n=Miranda@nat/microsoft/session) 19.26.42 # perhaps convert some busy-wait loops into wakeup_wait 19.27.21 Quit _lifeless (Read error: 110 (Connection timed out)) 19.29.40 Quit Lazatar (Remote closed the connection) 19.29.59 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 19.31.59 # can home+up be used as a combo on the clip? 19.33.13 # you mean if it is technically possible? 19.33.17 # yes 19.33.44 # home+down does work so I'm not sure if its a keymap thing or its hardware 19.34.34 # it think it should be possible 19.35.57 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 19.36.20 # but I don't like to use combos :P 19.36.50 # yeah yeah :) 19.37.34 # so obviously being late to the party... why isnt the clip supported yet? 19.37.45 # or are we still blocked with no manual and rbutil? 19.39.59 # playback stops spontaneously sometimes on the clip 19.40.32 Join petur [0] (n=peter@rockbox/developer/petur) 19.41.54 # it does that on my ipods also :p 19.44.33 # hmm... the button(s) for marking a number as possible in sudoku on the fuze is/are select+up currently 19.44.40 # would it be better for them to be long select? 19.44.48 # JdGordon|: I think it's because there are still some SD driver bugs to work out. 19.45.05 Join _lifeless [0] (n=lifeless@90.150.113.130) 19.45.05 Quit _lifeless (Read error: 104 (Connection reset by peer)) 19.50.31 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 19.55.24 Join p3tur [50] (n=petur@rockbox/developer/petur) 19.56.08 Quit Lazatar (Operation timed out) 19.56.08 Join kugel [0] (n=kugel@rockbox/developer/kugel) 19.56.34 Join Lazatar [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 19.57.34 Quit barrywardell () 19.58.21 Join merbanan [0] (n=banan@c-83-233-52-104.cust.bredband2.com) 19.58.47 # JdGordon|: do you have a clip now? 19.59.06 # yes :) 19.59.48 # so why don't you just try whether home+up is possible? It should be 20.00.07 # I did... and like i said, i wasnt sure if it was a keymap or hardware issue... 20.00.15 # I'll play more tonight 20.01.34 # work on the keymap is surely welcome 20.01.44 Join barrywardell [0] (n=barrywar@79.97.85.223) 20.01.51 # it's heavly based on the c200 keymap 20.01.58 # yeah, it sucks :D 20.02.11 # I started last night but ended up doing stuff... ill play tonight properly 20.03.03 # the comments say its based on the e200 doesnt it? 20.03.11 Quit BryanJacobs ("Java user signed off") 20.08.07 Join TheSphinX^ [0] (n=cold@p54A5C32B.dip.t-dialin.net) 20.09.32 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 20.09.58 # JdGordon|: the c200 keymap probably also says this 20.10.13 # :) 20.10.27 # adding keymaps is always c&p, hence barrywardell has done so many of them :) 20.10.53 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.16.50 # I think the clip keymap is quite OK already 20.17.35 # you don't use plugins, do you? :p 20.17.57 # btw, I'm also against volume-in-lists 20.18.22 Quit Lazatar (Connection timed out) 20.18.26 Quit Sajber^1 (Read error: 104 (Connection reset by peer)) 20.18.27 # I'd rather put goto-wps and quickscreen (i.e. what UP and DOWN do on e200/fuze) on those 20.18.45 # although, that won't work for the wps I guess 20.19.04 # I'm putting the wps on home+up and quickscreen on home+down... the logic is pressing home makes the button do what the image on it is 20.19.30 # there shuld be a setting to use the volume buttons as volume or as page up/down in the lists thoughg 20.19.47 # couldn't toggling wps and main menu be on plain home? 20.20.00 Join kushalone [0] (n=kushal@12.169.180.141) 20.20.05 # as in configurable buttons? :/ 20.20.09 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.20.19 # some drongo ( :D ) put goto rec on long home.... 20.20.54 # I was surprised that it was Llorean's idea, I remember him to be against configurable btutons 20.21.00 # and short home should usually go to the menu, but keeping with every other target, pressing it again should go back to the previous screen from the top menu, so it cant really be goto wps from there 20.21.16 # what was Llorean's idea? 20.21.30 # the setting for volume in lists 20.21.59 # i dont think he said anything about making it an option... 20.22.09 # What's co-opt then? 20.22.38 # isn't it already doing volume in lists? 20.22.45 # yes 20.23.26 # maybe I got him wrong then 20.24.47 # long record going to the record screen was annoying with the e200 20.25.00 # * JdGordon| does want single finger goto wps and menu 20.25.37 # so we can map that on HOME, right? 20.25.50 # * gevaerts suddenly remembers that he got annoyed a bit by the D2 keymap yesterday. Stop is too close to hold-off... 20.26.03 # bertrik: 20.26.05 # bah 20.26.16 # no, because home is goto menu/previous 20.26.22 # question regarding Fuze Sudoku binds: how deliberate are they? Is there any particular reason for them to not be closer to the e200? 20.26.25 # or should be 20.27.38 # HOME could be goto wps (or goto FM) when you are in the menu 20.28.08 Join shotofadds [0] (n=rob@80-44-101-38.dynamic.dsl.as9105.com) 20.28.28 # in keeping with every other target it shuold go to previous (which it does) 20.28.48 # maybe long home goto wps 20.29.12 # gevaerts: do you think it would be better if a short POWER press went to the menu instead? 20.29.26 # i agree it's annoying the way it is currently 20.29.37 # shotofadds: maybe. I haven't thought about it much 20.29.57 # Or maybe my fingers can just get used to it 20.30.05 # JdGordon, well what do you like more, single-finger WPS or goto-previous? 20.30.08 # I still find it annoying now... 20.30.44 # bertrik: I dont tihnk it would be an issue if home in the wps went to the menu instead of down 20.30.53 # I think stop is useful to have on a physical button though, and there aren't that many of those 20.31.05 # home does SFA i tihnk 20.31.13 # gevaerts: well, there's always long POWER ;-) 20.31.23 # shotofadds: that will stop it all right :) 20.31.49 # JdGordon: the volume buttons........ 20.32.14 # who *needs* volume in lists really of the wps is 1 press away. 20.32.22 # if* 20.32.25 # kugel: I think if we did that, volume should be up/down and the actual buttons do what they say 20.32.40 # but that should be configurable... :D 20.32.56 # I disagree, but still better than what's now 20.37.02 # * pixelma scrapped forced horizontal scrolling on the c200 recently to get a "go to WPS button" which is "long right" now 20.37.51 # although I also found it quite nice to have "volume up" for it and then have no volume in lists 20.38.41 # JdGordon: using volume buttons for up/down is a major annoyance. you'd need to move the finger from the side to the middle and back constantly while browsing 20.38.54 # the only difference between the e200 and c200 is that the wheel is replaced by two volume buttons, right? 20.39.04 # the thing is tiny, so you have to rearrange your girp anyway 20.39.26 # and where does the brain mapping come in for up being wps and down being qs? 20.39.32 # JdGordon, I won't 20.39.54 # ? 20.39.59 # JdGordon|: up = play = go to the display of what's playing? 20.40.27 # the play picture is on the other button though 20.40.31 # Dhraakellian: yes but that is a quite important difference, especially since the volume button is quite a bit away from the main pad 20.40.31 # Dhraakellian, the clip has no rec button and having no wheel means there nothing in the way of the left/right/up/down buttons 20.41.12 # the buggers should have put a microSD slot in and a wheel! 20.41.17 # he asked about the c200 though 20.41.28 # JdGordon|: you're too focussed on the pictures on the buttons...we ignore those on many targets 20.41.38 # no we dont... 20.41.46 # * Dhraakellian is watching the convo out of curiosity and such 20.41.47 # we go by them on far more than ignoring 20.41.57 # I didn't say most 20.42.24 # a keymap which isn't totally insane is much more preferrable 20.42.41 # there needs to be some logic to it though... 20.42.54 # I shoudlnt have to open the manul to figure out how to use it 20.43.21 # oh yea, and putting up/down which are on the side is clearly logical 20.43.30 # s/which ar// 20.43.56 # its a verticle bar... yes its bloody logical 20.44.04 # far more than using it for arbitrary commands 20.44.09 # I have a very hard time seeing the logic in it 20.44.24 # it even says "volume"! 20.44.34 # show me a player which doesn't have the navigation buttons on the front 20.44.35 # at least my clip does on those buttons 20.45.30 # * JdGordon| is now confused 20.45.46 # is bertrik agreeing with me or kugel? 20.45.51 # or neither 20.46.05 # JdGordon|: He's not seeing the logic in your proposal 20.46.36 # because there is no logic. even if we go that route to map functions to the fancy pictures, it doesn't work for volume 20.47.02 # it is ALOT harder to see the volume text than it is to see the pictures 20.48.40 # I want up/down/left/right navigation on the buttons around the select button, not up/down on volume. I prefer the volume buttons to control volume. 20.49.04 # but the PICTURES! 20.49.21 # * kugel stops being sarcastic 20.49.30 # * JdGordon| punches kugel in the nose 20.49.39 # I'm not saying we have to use the picutres.. 20.49.50 # I'm saying having those actions on the volume button makes no sense 20.49.54 # Dhraakellian: The built-in font uses the same glyphs as 08-Schumacher-Clean, but only the ISO8859-1 codepoints 20.49.55 # the pictures should have meaning in the WPS, not in the menu IMO 20.50.09 # The loadable 08-Schumacher-Clean goes beyond that 20.50.33 # HOME should goto the main menu though... not the bottom button which should be the context menu button 20.50.35 # amiconn: ah 20.50.53 # * shotofadds starts his first D2 battery_bench (mp3 from SD). I'm going for a *pessimistic* 18hrs, since I've seen RB play FLACs from internal flash for a solid 24hrs, and that wasn't even on a full charge... 20.51.09 # s/going for/expecting 20.51.14 # heh. 20.51.24 # * Dhraakellian should do a batterybench on his Fuze 20.51.56 # load up the 10-symphony Bruckner cycle (q6 Vorbis) on repeat 20.52.02 # see if it makes it all the way through 20.52.30 # shotofadds: tell us if it beats the M5L record :) 20.52.37 # JdGordon: why should the bottom one context menu? It's on long select on the majority of targets 20.52.49 # we even changed it from bottom to long select on the e200 20.52.59 # and the c200 20.53.10 # then both should goto menu 20.53.24 # pixelma: now that would be impressive! 20.53.29 # amiconn: right... and if we start using iram on beast we can map it wherever we want. can we possibly move iram's mapping on the other arm7tdmi targets, or is that not under our control? 20.53.32 # how HOME can do anything but goto the main menu is beyond me 20.53.48 # * JdGordon| gets his first audio fubar on the clip 20.54.09 # I have stable 3.0. It might be time for a flash. :-) 20.54.10 # Unhelpful: IRAM on PP cannot be remapped afaik, and also SDRAM cannot be mapped anywhere above 0x40000000 20.54.18 # * gevaerts still wants to know how long the M5L lasts with FM 20.54.27 # JdGordon|: no-one is arguing against home for menu I think 20.55.09 *** Saving seen data "./dancer.seen" 20.55.38 # shotofadds: does the d2 have some sort of sd_enable() to power down the sd when unused? 20.56.19 # at the moment we just turn the clocks off. I assume there's some way to power it down, but it's not done yet 20.57.10 # hm... I've found that my e260 and Fuze don't appear to get full charge from my computer (only getting up to 95ish, give or take, according to the statusbar) 20.57.12 # SD cards do auto power down. So the only part that might need explicit powerdown would be the controller 20.57.32 # But if you stop clocks, remaining power consumption should be very low 20.57.53 # we could disable the controller block, but like you say, I doubt it would make much difference 20.58.27 # I think we're not doing much more on the samsas 20.58.54 # * shotofadds just copied the PP code ;-) 20.59.23 # kugel: please use sansa AMS instead of samsa. :-) 21.00.31 Quit Xerion (Read error: 104 (Connection reset by peer)) 21.00.49 # samsa:sansa AMS::sammich:sandwich? 21.01.13 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 21.01.51 # amiconn: the best thing i've tried so far, i think is just removing -mlong-call. we'll need stubs to handle gcc-generated calls to mem*, since we can't control how those are called, and there might *still* be some problems with static functions. it looks as if without -mlong_calls there's almost no way to get make a long call to a function that happens to be defined in the same file. 21.01.59 # shotofadds: I suspected that when looking at the commit diff :) 21.02.23 # What about this eabi/binutils 2.19 thing? That sounds like a nice way to go - if it works 21.05.17 # amiconn: i'm not sure. i don't really like the idea of having bunches of autogenerated stubs whenever a function is called that's too far away. 21.06.44 # Better than unnecessary long calls I would expect 21.07.29 # it should be reasonable, i think 21.07.47 # * shotofadds really should disable long-calls for the D2 build, since we don't use IRAM (yet) 21.08.03 # it will try and use the same stubs as much as it can 21.08.46 # the stubbed branches obviously are one more instruction but a regular branch is cheap 21.09.39 # http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/NEWS?annotate=1.105&cvsroot=src line 72 21.11.05 # so we'd be adding one instruction per function when some code calls that function out of range. and the speed cost is one relative branch per actual out-of-range call. 21.11.21 # domonoky: for deb packaging 21.11.25 # not for us.. 21.11.46 # you'd be making most functoins smaller, not bigger 21.11.59 # kugel: it not problem to build rbutil non-statically... so that can be the blocker.. 21.12.05 # assuming he also wants it to be in the debian/ubuntu/whatever repos 21.12.10 # s/can/cant 21.12.25 # N calls to a far function becomes N+2 instructions instead of 2N instructions 21.12.37 # the bigger problem is, that rbutil still changes often.. 21.12.59 # and yes, the far calls are slower by one relative branch, but it means that every other call can always be relative 21.13.28 # domonoky: I don't think that's a problem, except for debian stable maybe. 21.14.43 # this eabi thing seems to have a number of other differences to the old abi 21.14.45 # (in fact 2N instructions plus at least one copy of the actual address depending how smart it manages to eb with the constant pools) 21.14.49 # so, it's a code-size win vs long calls everywhere, except for functions that need exactly one long call. it's not *quite* as big a win as if we can use long calls exactly where we need them. the situation for speed is probably similar, since we're removing probably rather a few unnecessary long calls. 21.15.05 # kugel: so if that also isnt a problem, its only lazyness that nobody made a package. :-) But i would expect that if we have packages, people will often use old rbutil versions, as the repositorys probably will have quite some lag. 21.15.11 # kugel: it's not clear from the docs whether it's actually mandatory for it to be EABI for it to work 21.15.16 # the source implies it might work anyway 21.15.23 # i've not got a suitable binutils installed so i've not tried it yet 21.15.33 # I'm worried about the struct alignment thing 21.16.31 Join SeismicMike [0] (n=Mike@adsl-76-235-57-25.dsl.dytnoh.sbcglobal.net) 21.16.48 # has anyone ever installed on a Sansa e260? I'm having some trouble 21.17.10 # I'm in Windows and I don't know what to put down for the mount point because it doesn't give the device a drive letter 21.17.19 # I can't figure out how to give it a drive letter. 21.18.18 # wait... nm.. that's when it was in MTP mode 21.18.27 # I just switched it to MSC mode and it has a drive letter now... 21.18.35 # :) 21.18.40 # kugel: EABI structs are often *smaller* though 21.18.51 # kugel: we might have to fix places that were making assumptions about packing 21.18.57 # but you may find it's actually a memory win :) 21.19.19 # asm that touches structs may be in trouble. 21.19.31 # yes, 21.19.32 # I'd willing to pay a bit memory for speedup due to alignment 21.19.45 # Unhelpful: Do we have those? 21.19.48 # kugel: what? no, it never packs stuff below its natural alignment 21.20.16 # kugel: i'm responsible for at least one instance, jpeg_idcth asm. 21.20.39 # "Under the EABI there is no minimum and the alignment is determined by the types of the components it contains. " not sure what it means 21.20.40 # since the output is to an array of struct{ char;char;char; } 21.21.14 # Unhelpful: so that ends up with 4-byte alignment atm, yes? 21.21.33 # could it mean the alignment is determined by the biggest datatype? 21.21.48 # kugel: it means the alignment of the whole struct is whatever makes the types in it all aligned at once. 21.21.50 # is there anything special about the wakeup_XXX functions? I see they are only defined for some specific CPUs 21.21.51 # char;char;char would be 3, but char;char;int would be 4? 21.21.55 # Torne: correct. the particular code in question would not be harmed speed-wise by making tose 3-byte aligned 21.21.55 # 8* 21.22.26 # kugel: char;char;int; ends up with size 8, alignment 4 21.22.33 # two bytes of padding before the int 21.22.37 # eh 21.22.50 # yea, I don't know why I was correcting myself to 8 :/ 21.22.52 # that's the same under both abis 21.23.15 # char;char;char; in oldai is size 4 align 4, in eabi it's size 3 align 1 21.23.18 # "can break code that writes binary files by dumping and reading structures." <-- rockblox does that :( 21.23.36 # the new struct rules never make anything bigger unless you have 64-bit fields 21.23.39 Part SeismicMike 21.23.43 # Torne: hm, it seems reasonable then 21.23.53 # it requires higher stack alignment :) 21.23.56 # which may break asm 21.23.59 # and may use more stack 21.24.15 # Why that, btw? 21.24.17 # asm functions can't push odd numbers of registers and then call C funcitons 21.24.21 # bertrik: that's to decrease binsize 21.24.23 # AFAIK 21.24.26 # so that 64-byte types are naturally aligned on the stack 21.24.34 # 64-bit even 21.25.05 # still not really logical to me 21.25.09 # but the source says that we *might* get the stubs generation without all of these ABI changes? 21.25.26 # Unhelpful: it might. one thing at a time, i guess 21.25.52 # presumably if that's the case all one really need do is changes the binutils version for ARM in rockboxdev.sh? 21.25.54 # You don't have 64bit registers, i.e. you need to load/pop 2x32bit, I don't see a need for 8byte alignement 21.26.12 # LDRD needs 8 byte alignment 21.26.17 # mcuelenaere, ok, just surprised that so few targets seem to use it, and slightly unsure if it requires something that I'm not aware of yet 21.26.28 Quit courtc (Read error: 113 (No route to host)) 21.26.28 # so does VFP double format 21.26.31 # and some other things 21.26.34 # not that I know of, at least I didn't need to do anything special to use them 21.26.40 # * gevaerts thinks that code that reads and writes structs to disk for long-term storage without packing them is broken 21.26.46 # * Dhraakellian changes some buttons for Sudoku on the Fuze and checks to see how they work out 21.26.56 # * Unhelpful agrees with gevaerts on this 21.27.33 # it's also nearly impossible to change what is/isn't stored without simply discarding old saves... this is why i changed pictureflow to use a configfile. 21.28.17 # * Unhelpful has already modified rockboxdev.sh and is building :) 21.29.01 # Unhelpful: let me know how it goes, i gotta go do stuff :) 21.29.12 # Torne: LDRD is said to need 8 byte alignment, but in fact it works with 4 byte alignment as well 21.29.22 # gevaerts: you're saying the struct should have __attribute__((packed))? 21.29.54 # kugel: yes, with possibly manual padding 21.30.18 Join courtc [0] (n=court@unaffiliated/courtc) 21.30.32 # kugel: if it doesn't, an abi change could break old saves. it's not like we've promised *never* to update gcc/binutils. 21.30.39 # amiconn: the docs suggest it's not (or at least suggest it's not guaranteed to be atomic anymore) 21.30.47 # however, adding that attribute will of course break it now. :) 21.31.12 # maybe it will just work also? :) it has only ints and an array of shorts 21.31.59 # Iiuc the only differences between old arm abi and eabi are floating point related, and we don't use that 21.32.15 # * Unhelpful sincerely hopes that everywhere that does this at present will be smart enough to at least check the size of the read 21.32.29 # then you just get your old save or config invalidated, but nothing will crash 21.32.38 # amiconn: http://wiki.debian.org/ArmEabiPort 21.33.25 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 21.34.01 Join balug_ [0] (n=dvg@HSI-KBW-078-042-132-156.hsi3.kabel-badenwuerttemberg.de) 21.34.04 # i believe what i recall seeing in the manual was that ldrd works with four-byte alignment but does an extra read in this case 21.34.05 # Unhelpful: rockblox checks, but I don't think checking for sizeof(struct) after telling read() to read sizeof(struct) bytes help for this case 21.34.07 # kugel, the wakeup_signal/wait mechanism could also be used in the fuze LCD driver (instead of polling for the volatile flag) 21.34.46 # bertrik: so you're telling you're volunteering to write the code? :D 21.34.56 # kugel: ah... if the "new" size is shorter, it will still succeed. 21.35.01 # go use configfile! ;) 21.35.18 # kugel, no, well maybe 21.35.23 # hehe 21.35.32 Quit barrywardell () 21.35.41 Quit stoffel (Remote closed the connection) 21.35.45 # Unhelpful: why? the size parameter of read() and the check after have the same size 21.35.46 # I also looked into the button code and I don't quite understand it 21.36.29 # kugel: i mean that the *test* will succeed. it will read exactly the number of bytes it wanted, and not know that it's discarded some. :/ 21.36.43 # the test will always succeed, that's what I'm saying 21.36.56 # Hmm. Iiuc eabi will alomost automatically support vfp - might be interesting for special purposes on the beast 21.37.11 # i didn't think the beast had vfp? 21.38.15 # kugel, even at 100 fps LCD update rate, a full update takes 10 ms, that's quite a long time to block 21.38.26 Quit balug_ (Client Quit) 21.38.48 # yes, but we can't help it, can we? 21.39.10 # so some yielding or switching threads while waiting for the interrupt would be nice 21.39.23 # huh 21.39.34 # the ISR is blocked 21.40.04 # Or what interrupt are you refering to? 21.40.37 # the DBOP FIFO (almost) empty interrupt 21.40.50 # oh with my patch 21.41.13 # I think I have tried yielding without slow down 21.41.27 # but the issues is with the blue bars anyway 21.41.55 # kugel, I suspect the blue bars have something to do with the button readout 21.42.14 # Why do you think that? 21.42.38 # on the e200, there's no button readout if the lcd is currently busy with updating, it still has the bars 21.42.57 # no readout on dbop, at least 21.43.34 # because the blue bar changed slightly when pressing buttons, and because I see two different button readout functions that are not obviously protected from running together with LCD update (to me at least) 21.43.55 # look at lcd_button_support() 21.44.33 # what do you guys think of http://pastebin.ca/1489985 for a Sudoku button change on the Fuze? 21.44.40 # the fuze still reads the scrollwheel, that's correct. But the e200 doesn't even try to touch dbop in during updates 21.45.23 # This eabi thing is definitely something we should try 21.45.41 # as far as I can see, the the button_gpio function is not protected from running at the same time as lcd update 21.45.57 # why are there two button read functions anyway? 21.46.03 # yes, because it doesn't change the fifo 21.46.06 # menu is a short click on the home button (quit is still long home). I moved menu away from the power/hold slider on the side 21.46.23 # per infocenter: "ARM1136JF-S processor has a floating point coprocessor." without any mention of VFP... but then the VFP11 docs state: "This manual only describes the implementation of the VFP11 for the ARM1136JF-S processor." 21.46.32 # it's running in an interrupt, and sets the state of the gpios back 21.47.04 # Unhelpful: the vfp is the fpu, IIUC 21.47.42 # kugel, but button_gpio changes the function of the DBOP hardware ports, right? 21.48.05 # bertrik: why should it be one? They're getting at the hardware with different approaches. Also, the dbop function runs more often 21.48.23 # kugel: There also was FPA for older ARMs 21.48.34 # this would show below 100fps too I think 21.48.47 Quit n1s (Read error: 110 (Connection timed out)) 21.48.52 # amiconn: yes, I know. I was refering to the arm11 Unhelpful mentioned 21.49.08 # I don't see the need for two button read functions 21.49.12 # even more below 100fps, since the update needs longer 21.49.28 # bertrik: "Also, the dbop function runs more often" 21.49.32 # * Unhelpful doesn't see "has an FPU" and automatically assume it's SIMD :) 21.50.36 # I don't see what's wrong with it, are you trying to safe 2 instructions? 21.50.45 # I don't understand, this looks hopelessly complex to me 21.51.21 # but maybe I don't know all the weird things this hardware has ... :P 21.52.12 # the dbop function is called twice per tick, 1x in button_read_device() and 1x in the timer interrupt outside of call_tick_tasks() (the timer is configured to interrupt every 5ms) 21.52.23 # I think it would be bad if button_gpio would be called when LCD update was in progress. Is there any mechanism to prevent this? 21.52.41 # I doubt this, but one could try 21.53.01 # lcd_button_support() returns false if an update is running 21.56.25 Join matsl [0] (n=matsl@host-90-233-242-98.mobileonline.telia.com) 21.57.04 # bertrik: don't you think it would show even more with lower fps, the update takes longer then (i.e. possibly button_gpio is called twice during an update) 21.58.10 # yes, possibly. 21.58.57 # I can't really explain that, but I still suspect we're doing something wrong now 21.59.16 Quit LambdaCalculus37 () 22.09.35 Join JdGordon|| [0] (n=Miranda@nat/microsoft/x-e189c50f66bf57ac) 22.14.29 Quit JdGordon| (Nick collision from services.) 22.14.37 Nick JdGordon|| is now known as JdGordon| (n=Miranda@nat/microsoft/x-e189c50f66bf57ac) 22.16.38 # hrm... i had to add a -Wa,-meabi=4 to GCCOPTS. trouble now seems to be that libgcc was not similarly compiled... 22.17.51 # New commit by 03bertrik (r21734): S5L8700: Implement ADC driver 22.21.06 Nick martian67_ is now known as m67_l3 (n=martian6@about/linux/regular/martian67) 22.21.20 Nick m67_l3 is now known as martian67 (n=martian6@about/linux/regular/martian67) 22.23.16 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 22.23.48 # bertrik: is it possible that adc_read() is accessed from different threads? 22.23.48 Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) 22.24.27 # mcuelenaere, not sure, but could happen I think 22.24.44 # do you think it's not necessary? 22.25.11 # ah /me sees that the Onda does the same 22.25.11 # to protect multiple access I mean 22.25.45 # now that I think of it, it's probably only the power thread that uses it to read the battery voltage 22.25.46 # no, it's just that battery_adc_voltage() on the Onda VX747 is a bit hackish implemented, and I was searching for a reason what was causing the problems I had 22.30.42 Quit martian67 ("out") 22.30.59 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 22.31.56 Quit martian67 (SendQ exceeded) 22.32.55 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 22.33.47 Quit martian67 (SendQ exceeded) 22.34.29 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 22.35.23 Quit martian67 (SendQ exceeded) 22.35.48 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 22.37.16 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 22.39.43 # mcuelenaere: should be safe 22.40.00 # it has mutexes 22.40.38 # kugel: you mean battery_adc_voltage() on the VX747? see the 'primitive wakeup event' thingy .. 22.40.39 # at least, if your i2c uses them. the generic, and as3514 i2c have this mutex 22.41.34 Join n1s [0] (n=n1s@rockbox/developer/n1s) 22.41.35 # kugel: huh? i2c? 22.41.48 # (btw I just see those don't use mutexes) 22.42.11 # I'm have no idea how mutexes work, but those are meant to block threads out of code that's currently in use by another thread, IIUC 22.42.21 # mcuelenaere: which "those"? 22.42.29 # i2c-jz4740.c 22.42.53 # (the functions in them, hence the plural ;) ) 22.43.19 # ah, they probably should just have the mutex and be thread safe :) 22.44.01 # * mcuelenaere enlarges his TODO list ;) 22.46.47 Join luke_dozen [0] (n=luke_doz@p54AB6AA0.dip.t-dialin.net) 22.47.08 # Bagder: The client reconnect problem is still there (dunno if it's supposed to be fixed) 22.47.25 # I don't think anyone has tried to fix it yet 22.51.47 Quit merbanan (Remote closed the connection) 22.51.49 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 22.51.54 Join FlynDice_ [0] (n=FlynDice@c-76-121-18-103.hsd1.wa.comcast.net) 22.54.00 Quit saratoga (Ping timeout: 180 seconds) 22.55.12 *** Saving seen data "./dancer.seen" 22.57.23 Quit _zic (Read error: 110 (Connection timed out)) 23.00.32 Quit Ridayah ("The Rise and Fall of the Heavens themselves is dependant upon Humanity's belief and disbelief.") 23.01.21 Join Ridayah [0] (n=ridayah@173-19-228-175.client.mchsi.com) 23.01.44 Quit p3tur (Remote closed the connection) 23.01.56 Quit petur ("Zzzzzz") 23.02.23 Join dmb [0] (n=Dmb@unaffiliated/dmb) 23.03.11 Quit TheSphinX^ ("XChat@Linux") 23.04.13 Quit jgarvey ("Leaving") 23.04.49 # Hillshum, you meant FS#10210? 23.05.53 # Yes, though I'm not sure. Did it change the keymap on the screen where one browses the video? 23.06.04 Quit n1s (Read error: 110 (Connection timed out)) 23.07.01 # * Hillshum compiles a sim 23.08.04 Join n1s [0] (n=n1s@rockbox/developer/n1s) 23.10.46 Quit dfkt (Read error: 110 (Connection timed out)) 23.11.07 Quit dmb (Client Quit) 23.19.07 Quit luke_dozen (Remote closed the connection) 23.19.11 Join dmb [0] (n=Dmb@unaffiliated/dmb) 23.19.19 Join tessarakt [0] (n=jens@e180079163.adsl.alicedsl.de) 23.19.43 Join luke_dozen [0] (n=luke_doz@p54AB6AA0.dip.t-dialin.net) 23.20.25 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 23.24.38 Join funman [0] (n=fun@rockbox/developer/funman) 23.24.45 # hello 23.25.22 # is it possible to download current builds for an old svn revision ? (r21710) 23.25.40 # I think only the daily build is archived 23.26.47 # correct 23.26.51 # i could build this revision myself but the i think the addresses inside rockbox.elf could change with a different gcc version 23.27.45 # Did you find out the version it used to build it? 23.28.17 # no, but the gcc version is mentioned in rockbox-info.txt, i'll ask the person 23.28.33 # it might be on the build table 23.29.10 # penultimate entry ;) 23.29.28 # http://www.rockbox.org/dl.cgi?bin=sansafuze :( 23.31.08 # I now have the LCD controller datasheets, as well as the routines to write to the display, but I can't actually get it all to tie together and display anything... :( 23.31.21 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 23.31.30 # bertrik: Nevermind, mpegplayer's fine 23.31.43 Quit r0b- (Read error: 110 (Connection timed out)) 23.32.00 # obo: so did you then find the init sequence in the OF that matches the datasheet? 23.32.32 # Bagder: pretty much - I've found several init routines for that controller, and most, but not all of the values tend to match 23.33.04 # some of those don't seem to matter too much, since they're gamma curves etc 23.33.40 # so could it be a separate power-on to the LCD or similar that needs to be done? 23.33.52 # I've attached the datasheets plus my attempt to the GSoCSansaView wiki page if anyone fancies a look? 23.34.06 # Bagder: since I'm running after the OF bootloader, shouldn't that be done already? 23.34.23 # right, one would think so... 23.34.30 # Doesn't it depend on when the OF inits? 23.34.51 # obo: I assume you have a all white display right now? 23.35.06 # kugel: no, still the OF bootlogo 23.35.21 # oh, that's funny too :) 23.35.30 # I can create a white display by flipping a GPIO bit... 23.36.03 # can you somehow "manually" clearing the hw-framebuffer then a lcd update? 23.36.13 Quit funman ("leaving") 23.37.24 # I have a little patch to move the sudoku menu on the Fuze from the power button (on the side) to the home button (on the front). Should I make a bug report for it? 23.38.13 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.38.22 # Dhraakellian: put it on Flyspray yes, but mark it as a patch\ 23.38.42 # *patch 23.38.43 Join midgey|w [0] (i=836b0056@gateway/web/freenode/x-c2fe074e39193f1d) 23.39.00 # kugel: I'll need to find out how to do that... 23.39.21 # You have the ds, haven't you? 23.39.29 # yes 23.39.42 # the registers of the memory should be there 23.40.04 # the init routine sets them to 0x0 23.41.48 # * Dhraakellian ponders also including some column formatting in the patch 23.42.33 # whitespace changes? 23.43.18 # kugel: 0x20 and 0x21 are both set to 0x0 (horiz and vert GRAM address set) 23.43.19 # obo: huh? you can change the location of the output memory? 23.43.21 # yeah. all the other sections that are lined up as columns appear to do it with spaces. the Fuze section uses tabs 23.43.49 # yes, four spaces are to be used in place of tabs 23.44.07 # obo: I think that's only interesting for doing partial updates. I mean the actual memory 23.45.13 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 23.45.19 Quit Thundercloud (Remote closed the connection) 23.45.55 # kugel: it has a completely different set of registers for partial updates? (0x80 to 0x85), and 0x51 and 0x53 also set the display size... 23.46.04 # hmm, I think I'm confusing things 23.46.27 # Hillshum: http://pastebin.ca/1489985 vs. http://pastebin.ca/1490086 23.46.49 # obo: "0x20 and 0x21 are both set to 0x0 (horiz and vert GRAM address set)" this is probably the start pixel for updates 23.47.51 # is your lcd_update() maybe buggy? 23.48.21 # Dhraakellian: I don't know which is better 23.48.27 # kugel: that's entirely possible( if not probable) 23.49.43 # although I guess the e200's lcd_update should work 23.50.45 # Hillshum: they should be the same except that the second one just has some extra whitespace stuff to line the columns up better 23.51.11 # kugel: it doesn't seem to work like the e200 controller? AFAIK you don't point the controller to your buffer the way the e200 does? 23.51.27 # Why that? 23.51.31 # Yes, but I don't a whole lot about the whitespace rules 23.51.47 # ah 23.51.59 # How would that work? You need to pass the data from the rockbox framebuffer somehow 23.52.12 # I've not seen that in any of the init routines that are floating out on the web for this controller... 23.52.36 # kugel: yes, more like the way the c200 works... 23.54.32 # basically, you have at least make sure to set the window position (i.e. start pixel and end pixel) write a command that updates 23.54.34 # +and 23.54.53 Join BdN3504 [0] (n=5ce227df@gateway/web/cgi-irc/labb.contactor.se/x-ece31549c5740a6d) 23.56.56 Quit domonoky (Read error: 104 (Connection reset by peer)) 23.58.32 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 23.58.50 Quit matsl (Read error: 110 (Connection timed out))