--- Log for 10.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 7 days ago 00.00.56 Quit mirak (Remote closed the connection) 00.01.24 Quit n1s (Read error: 110 (Connection timed out)) 00.06.41 # kugel: okay - that took a little too long to sink in here. Will look up what I need to send. 00.08.58 # New commit by 03bertrik (r21735): S5L8700: use wakeup_wait/wakeup_signal instead of polling for i2c communication 00.09.52 # Zagor: I think we should let the client exit if it had no server-traffic in 30 seconds or so 00.11.33 # Bagder: yeah 00.11.54 # have you looked at the server ping logic? 00.12.11 # no, but I think the problem is client-side 00.12.19 # ie it doesn't "see" the server drop off 00.12.24 # so it just sits there waiting 00.12.37 # but the server doesn't disconnect either, does it? 00.12.46 # I don't know 00.12.54 # it should 00.12.59 # anyway, it can't hurt checking on both sides 00.14.38 # "make zip" fails for jjim. that's why there are missing builds in the size table. I 00.14.47 # I'm adding a check for that now. 00.15.19 # aha 00.15.36 # that reminds me of a 'test' option for the client 00.16.31 # but perhaps probing for most of the tools at startup should be enough 00.17.22 Quit BdN3504 ("CGI:IRC (EOF)") 00.17.32 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 00.18.57 # Zagor, Bagder: Why are builds killed before the round ended? 00.18.59 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 00.19.09 # kugel: when another client completed it 00.19.50 # Why are clients getting the same build in the middle of the round? I thought this speculative parallel build was about when the round ends 00.20.15 # it starts as soon as all builds are handed out once 00.20.30 # I could easily have two builds, but now I get 3 of 4 killed 00.20.34 # it'll happen pretty soon as some clients are really fast 00.21.19 # it's all about how the builds are distributed to what clients 00.21.28 # and that's why a better speed meter is useful 00.21.39 # Shouldn't it give builds that have not been assigned yet, and only assign builds of other clients if no builds are left? 00.22.18 # that's what it does 00.22.31 # it gives the builds with the lowest number of assigns 00.22.39 # that aren't completed 00.23.28 # oh, I think all my builds got killed 00.23.38 # yep, looks like it 00.24.00 # I'll be adding some stats info so we can measure how much cpu time was "wasted" 00.24.37 # I mean, instead of giving someone my ipodnano build, the other cliend should rather have taken what's next (or even last) in my list 00.24.54 Quit soap () 00.24.54 # kugel: you need to read my explanation 00.24.57 # we already do that 00.25.41 # we hand out builds in a fine order to the clients we think are most suitable 00.25.50 # the order is pretty easy to understand 00.26.02 # yea, that's why I get ipod nano and ipodvideo64mb? 00.26.12 # with lowest bogomips? 00.26.42 # what are you suggesting? 00.27.05 # why am I getting the hardest build if it's meant to suit the clients? 00.27.19 # they're not 00.27.20 # kugel: you don't. your low bogomips means you don't get the heaviest builds in the first handout. 00.27.46 # ipodnano was my first build, ipodvideo64mb the 2nd 00.28.26 # that was the first handout, and those are some of the hardest, aren't they? 00.28.48 # Bagder http://www.youtube.com/watch?v=EIyixC9NsLI&feature=channel 00.28.55 # ipodnano is yes 00.28.55 # I actually never got a quick bootloder or so 00.28.59 # ipodvideo64mb is not 00.29.08 # Syrius: what are you talkign about? 00.29.50 # but yes kugel should not get ipodnano first I'd say, if joined from the start 00.29.50 # kugel: you're right. It looks like the order is reversed :-) 00.30.10 # kugel got the heaviest, gevaerts the easiest! 00.30.13 # You mean I'm not going to get all the bootloaders anymore? 00.30.16 # that also explains why gevaerts gets to many bootloaders 00.30.19 # omg....... 00.30.23 # * gevaerts is not happy! 00.30.35 # gevaerts: you could've told that earler 00.30.36 # Oh dear 00.30.46 Quit robin0800 ("Leaving") 00.30.48 Quit J-23 (Read error: 113 (No route to host)) 00.30.54 # Bagder: that's on sub sortbuilds, right? 00.30.56 # *in 00.31.01 # yes 00.31.08 # or possibly the client sort 00.31.22 # btw, when are we getting build times in new.cgi? 00.31.40 # "soon" :) 00.31.52 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 00.33.08 # * JdGordon| thinks he remembers some discussion about wanting to give big builds to slow clients 00.33.25 # JdGordon|: why would we want that? 00.33.32 # JdGordon|: maybe in the old system 00.33.40 # although, my initial point remains. My build was cancelled 4-5min before the build round ended. It seems to me that the handout doesn't prioritise builds that another client already started lowest 00.33.47 # yeah, it doesnt make much sense.. but I'm sure i rmember the discussion 00.34.09 # i can see the reasoning on a relatively small fleet of computers 00.34.24 # you get several builds out of the faster ones in the time it takes the slow one to do the one 00.34.29 # kugel: why not? we have very fast clients involved 00.34.38 # shouldn't it work like: client requests new build -> give him a unhanded build; if there's no unhanded build give him a unstarted instead, if there's no unstarted give him a started one 00.34.46 # It does make some sense in the old system, in that it could avoid them starting a second big build 00.34.51 # kugel: That's what it does 00.34.58 # Well, barring any more sorting errors 00.35.12 # the list is sorted on "handed out count" and then on "weight", excluding the ones already completed 00.35.27 # gevaerts machine is just very fast and probably responsible for a lot of kills 00.35.34 # it doesn't recognize already started builds? 00.35.44 # "handed out count" is exactly that 00.35.46 # I must say that I haven't seen many killed builds on it :) 00.35.47 # given to a client 00.35.57 # kugel has a point. we don't know when builds are started, only handed out. that means the builds we hand out again are likely builds that are already running on other targets rather than those in their queue 00.36.01 # Bagder: handed out count also includes builds that haven't been started yet though 00.36.02 # handed out != started. I mean started as in actively compiling 00.36.21 # we have no concept of "started" in the server 00.36.24 # * rasher still doens't quite understand the need for the queue 00.36.40 # rasher: upload in the bg is the first explanation of course 00.36.56 # Bagder: Why doesn't the client just request a new build before uploading? 00.37.01 Join webguest93 [0] (n=d8870b32@gateway/web/cgi-irc/labb.contactor.se/x-c9deab1e8c2d7d48) 00.37.07 # Bagder: if we wouldn't hand out 3 builds at once at the start, then handed out == started 00.37.08 # Or after starting the upload. Whichever 00.37.16 # well, because clients don't request builds at all ;-) 00.37.21 Quit webguest93 (Client Quit) 00.37.26 # wasn't that the plan, initially? 00.37.30 # This seems sub-optimal 00.37.32 # kugel: and why would that improve anything? 00.37.40 # I don't get it 00.37.48 Quit HBK (Read error: 104 (Connection reset by peer)) 00.37.57 # Bagder: Because there's less of a chance that a client gets its running build killed, rather just one picked from its queue 00.38.01 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 00.38.14 # in theory perhaps 00.38.19 # I doubt it is like that in real life 00.38.19 # I *really* don't understand why the client just doesn't say "I'm ready for another one" 00.38.26 # as Zagor said, it's not unlikely to hand a build out that a client is about to complete, instead of giving one that's only in their queue 00.38.46 # but it's not a likely scenario 00.38.56 # Bagder: my ipodnano build was killed near the end even though I had 2 other not even started builds 00.39.01 # clients do the builds in the order they get them 00.39.03 # I think we'll need a "gimme more" command anyway, once we start doing single-thread builds. 00.39.24 # kugel: that doesn't prove anything 00.39.32 # on the contrary 00.39.32 # Bagder: But why risk it? Why have any builds that are not started in the queue? 00.39.40 # risk? 00.39.43 # it's not a risk 00.40.05 Quit FlynDice_ (Remote closed the connection) 00.40.13 # the one you've worked on the longest is the one your building/uploading 00.40.13 # Well, it's not as fast as it could be if you kill a build even if there are unstarted builds around 00.40.30 # _that_ one was the highest prio for you to complete 00.40.31 # kugel: what happens at one client doesn't really reflect what happens at the server 00.40.32 # and you failed 00.40.36 # kill 00.40.39 # FAILED! 00.40.42 # it doesn't matter if you introduce a command 00.40.47 # ls 00.40.50 # wrong window 00.40.56 # giving a build that's currently compiling instead of a queued one is just illogical 00.41.03 # kugel: agreed 00.41.12 # its perfectly logical 00.41.16 # no its not... it could be stuck on a really slow server 00.41.22 # I agree too. I don't quite see your point Bagder 00.41.35 # JdGordon: that's no problem 00.41.42 Join AndyIL [0] (i=AndyI@212.14.205.32) 00.41.44 # you could add some logic to only do that if the is better though 00.41.45 # JdGordon|: So what? If there are other builds around, let the slow server finish rather than *wasting* the time that server's spent on the build 00.41.59 # if there's no queued build left, currently compiling builds would be handed out. whoever finished first wins 00.41.59 # ah, yeah ok 00.42.01 # my point isn't so much that I dislike the idea of changing this 00.42.22 # it's mostly that these guys argue as if this is something that'll make a big diff 00.42.33 # and I don't believe that 00.42.42 # it's not about spending time most efficiently, but getting the builds done quickest 00.42.43 # only one way to find out for sure though :D 00.42.44 # I believe it does. 00.42.49 # It just seems more complex and less efficient than simply "give me a build" "okay" 00.42.53 # Bagder: well, possibly not. but in theory it can make a difference. 00.42.54 # I often see even my first build getting killed 00.43.09 # Zagor: yes, and I'm not against it 00.43.10 # It won't make the round end twice as fast 00.43.22 # But it'll invariably shave off some amount of time 00.43.25 # let's first see what happens with the fixed sorting 00.43.43 # rasher: the thing is that we don't add things we don't need, hence we never had such a command 00.43.47 # gevaerts: well the underlying issue will remain 00.43.57 # the point with a queue was to allow the client to build in parallell 00.44.10 # for single-threaded builds, such as manuals and voices 00.44.14 # Bagder: I don't see why this is an argument? The client can still build in parallell surely 00.44.24 # Just ask for a new build when it's ready.. 00.44.25 # I recall this command was sort of planned anyway 00.44.29 # Zagor: of course, but I expect the symptoms to look a bit different 00.44.34 # I'm just explaining 00.44.43 # Bagder: but with 8-core servers, we'd need 8 builds in queue. It would be simpler to just have the client say "I can take one more, please" 00.44.47 # as we saw no need for such a command, we made none 00.44.50 # indeed 00.44.54 # I'm just explaining 00.44.57 # ok 00.45.07 # The server maintains a queue per client, right? 00.45.16 # yes 00.45.17 # I guess I'm just slightly surprised you came up with the most complicated solution 00.45.24 # I disagree 00.45.28 # I actually thought the clients requesting builds was one of the main ideas initially 00.45.30 # * JdGordon| also diagrees 00.45.37 # there is always a mroe complicated solution 00.45.40 # uh, the most complicated? I can think of _lots_ more complicated solutions! :) 00.45.45 # kugel: it wasn't from me at least 00.45.54 # me neither 00.45.55 # Anyway! 00.46.05 # then my memory is wrong 00.46.06 # Maybe you could increase the allocation count for the first build on every queue? 00.46.08 # I'm willing to stop and look forward 00.46.27 # Or ignore the whole thing. Whichever. 00.46.33 # adding a "gimme next" command for the clients should be fairly easy 00.46.41 # I'm thinking the whole queue'ing could be dropped for client requested builds 00.46.50 # no 00.46.56 # Huh? 00.46.58 # it still wants a new before the previous is done 00.46.59 # gevaerts: queuing is the problem, really. we should just skip the server queues and add the "gimme more" command 00.47.04 # that's a queue 00.47.14 # isn't that a queue? 00.47.20 # Bagder: Why does it want a new before the previous is done? 00.47.20 # two outstanding builds 00.47.25 # Well, depending on threads 00.47.28 # because it is uploading 00.47.40 # compile->request new build->upload 00.47.40 # well, it depends on definition. the queue would only contain running builds then 00.47.41 # then it wants to start the next, before the ul is done 00.47.44 # ok, so you want to replace pre-emptive queue filling by filling on demand? 00.47.50 # I would argue that A and C in the wiki are "the client asking for another build" 00.48.11 # Bagder: Yeah, that's a definition. I mean a queue of not-even-running builds 00.48.14 # Bagder: then just request before uploading 00.48.30 # kugel: that's what I said, but that makes it a queue in my terms 00.48.39 # but not in yours ;-) 00.48.48 # So we all agree 00.48.51 # And cake for everyone 00.48.53 # seems so :> 00.48.55 # cake! 00.49.18 # Bagder: it's also a queue, but not the same as the current one :) 00.49.29 # yes it is, just shorter ;-) 00.49.45 # the server won't have to treat it any differently 00.51.06 # Bagder: do you have time to do this, or should I dig in? 00.51.40 # please go ahead, I'm stuck in another project atm 00.51.47 # ok 00.51.54 # I'll review the commits 00.55.04 # New commit by 03zagor (r21736): Check that zip is in path. Check that make zip succeeded. 00.55.14 *** Saving seen data "./dancer.seen" 00.55.22 Quit AndyI (Read error: 110 (Connection timed out)) 00.56.49 Join soap [50] (n=soap@rockbox/staff/soap) 00.57.06 # bertrik: What does a wakeup offer what a simple volatile variable doesn't? 00.57.51 # I guess doing away with the non-building-queue does mean that slow clients will only get one bootloader to build 00.58.20 # kugel: yielding? 00.58.25 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 00.58.27 # + a sleeping thread 00.58.28 # kugel, it puts the thread doing the wait to sleep until it gets woken up by wakeup_signal, saving cycles 00.59.00 # ah, that's nice of course 00.59.24 # but if we do that in the lcd driver, it would be done in interrupt context 01.00.06 # although we could special case that as it writes only 1px (count == 1), the wakeup thing woudnt be needed for count == 1 as the fifo doesn't fill enough 01.00.36 # rasher: no, not really. the slowest of 20 clients will still get the 20th hardest build in the first handout 01.01.12 # we discussed trying to "spread" the builds over clients but didn't come up with a good way to do it. 01.01.28 # and besides we'd need a non-bogus speed measurement to have any real use for it 01.01.36 # the slowest clients get the hardest builds? 01.01.48 # kugel: eh? 01.01.51 # kugel: read again 01.02.03 # "the slowest of 20 clients will still get the 20th hardest build" 01.02.08 # ah, 20th 01.02.41 # I was "the slowest of 20 clients will still get the 20 hardest builds" 01.02.56 # +reading 01.02.59 # haha 01.03.29 # Zagor: So with the current system, the slowest system doesn't get the 3 easiest builds? 01.03.46 # exactly 01.04.15 # to do that, we'd have to "leave" a very hard build for a while and hand out easy builds to the slower ones 01.04.27 # to risk that no fast client is left later 01.04.53 # we instead focus on handing out builds in prio order, the heavier the earlier 01.04.57 # rasher: correct. they are simply last in the handout list. 01.05.19 # Bagder: True 01.05.25 Quit kushalone (Client Quit) 01.05.32 Quit soap () 01.05.46 # but there are indeed many things we can tweak in this 01.06.54 Quit midgey|w (Ping timeout: 180 seconds) 01.10.07 Join soap [50] (n=soap@rockbox/staff/soap) 01.12.19 Quit mcuelenaere () 01.14.46 # Bagder, Zagor: going for clients requesting builds would also make making use of ccache easier right? the client could mention the build he did last in the request message 01.15.11 # kugel: the build the client did last is already built :) 01.15.12 # kugel: no, clients don't choose builds. the will just say "I'm ready for another one" 01.15.41 # we discussed prioritizing clients that did previous versions of each target, but that gets very messy very fast 01.15.56 # yeah, we get too many variables to take into account 01.16.59 # * gevaerts thinks that the best allocation strategy is to give out builds that require uploads before builds that don't, and then just big builds first 01.17.06 # Zagor: I didn't mean to make the client choose, but rather put a recommendation, as in telling the server "This is what I did last, it would be nice if you can give it me again due ccache, if not I'll silently accept any other build too" 01.17.20 # gevaerts: yes, but that's just a matter of "scoring" those builds higher 01.17.30 # gevaerts: yeah that was the plan for this last build, but it bugged. heavy zip builds should be first next round. 01.17.49 Join MrDuck [0] (n=kachna@r4ax178.net.upc.cz) 01.17.52 # but it might get complicated indeed 01.18.29 # * preglow_ applaudes the new build system work 01.18.34 Nick preglow_ is now known as preglow (i=thomj@tvilling2.pvv.ntnu.no) 01.18.34 # if all clients stay equally fast and they are the same set between builds, they will most likely get the same builds 01.20.00 # heh indeed, getting the same build automagically seems rather likely 01.20.31 # Considering the amount of variables involved, I doubt it 01.21.06 # hm, wait, they get the same starting build. but the build last is most likely not the starting build 01.21.31 # kugel: you see how it's getting messy? 01.21.33 # well, the last _set_ would be the same 01.21.41 # Zagor: I do, yes 01.22.01 # but yeah, towards the end of a round the order is not likely to be the same between rounds 01.23.00 # we could also have a custom ccache that only ccaches certain builds based on bogomips :D 01.26.26 Quit bmbl ("Bye!") 01.26.27 # New commit by 03zagor (r21737): Added server connection check. 01.27.58 Quit kugel (Remote closed the connection) 01.29.13 # * shotofadds wonders if preglow has seen fs#10415, before running off to bed 01.29.41 # night all 01.29.43 Quit shotofadds ("Leaving") 01.31.53 Quit Syrius ("/connect irc.freenode.org /join ##survival") 01.33.04 Quit gevaerts (Nick collision from services.) 01.33.13 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 01.33.27 # shotofadds, i have indeed, but i'm a bit here and there during the summer, and my d2 isn't with me, currently :/ 01.33.43 # thought the prospect of it alone of course has me very happy indeed :P 01.34.24 Quit Zagor ("Clint excited") 01.35.30 # ok, i had to use gcc-4.0.4, but i have an arm-elf-eabi toolchain. it doesn't really seem to be making a huge difference. 01.40.08 Quit dmb (Read error: 104 (Connection reset by peer)) 01.40.27 Join dmb [0] (n=Dmb@unaffiliated/dmb) 01.41.49 Quit tessarakt ("Client exiting") 01.47.04 Quit Thundercloud (Remote closed the connection) 01.54.46 Part toffe82 01.59.04 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.59.54 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 02.18.30 Quit r0b- (Read error: 110 (Connection timed out)) 02.19.18 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-7a55fb6249a2b3cf) 02.19.50 # Bagder: my build client ended up in a loop saying this today: http://pastebin.com/m4bbfb404 02.19.54 # not sure if it matters 02.20.56 Quit efyx_ (Remote closed the connection) 02.38.07 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.55.17 *** Saving seen data "./dancer.seen" 03.12.49 Quit saratoga ("Page closed") 03.14.12 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 03.34.09 Join toffe82 [0] (n=chatzill@adsl-99-130-7-236.dsl.frs2ca.sbcglobal.net) 03.40.42 Join ReKleSS [0] (n=ReKleSS@d58-110-112-4.meb3.vic.optusnet.com.au) 03.45.24 Quit HellDragon (Read error: 60 (Operation timed out)) 03.55.35 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 04.02.36 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 04.03.34 Part n00b81 ("Leaving") 04.20.35 Join z35 [0] (n=z35@ool-45701ce5.dyn.optonline.net) 04.26.00 # SUCCESS! gcc 4.0.4 arm-elf-eabi builds e200 rockbox without -mlong-calls, cutting 61KB from RAM usage, 56KB from binary size. 04.28.09 # also, i think it might work without bumping gcc, with one caveat... libgcc build fails for arm-elf-eabi with -mcpu=arm9e 04.28.56 Quit courtc (Read error: 60 (Operation timed out)) 04.29.20 Quit krazykit (Read error: 60 (Operation timed out)) 04.29.53 Join courtc [0] (n=court@unaffiliated/courtc) 04.32.24 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 04.34.51 # Bagder: Re: New builds for the build table? -- Sansa e200v2 - Sim 04.39.57 # Zagor: Server refused connection: error duplicate name! 04.49.36 Quit dmb (Read error: 113 (No route to host)) 04.55.19 *** Saving seen data "./dancer.seen" 05.08.01 Join dmb [0] (n=Dmb@unaffiliated/dmb) 05.14.29 Quit luke_dozen (Read error: 110 (Connection timed out)) 05.15.13 Join luke_dozen [0] (n=luke_doz@p54AB5FAA.dip.t-dialin.net) 05.26.04 Nick notByan is now known as Byan (n=notByan@logo.csl.mtu.edu) 05.32.28 # digging a bit further... gcc issues ldrd instructions when building __muldc3 with -mcpu=arm9e, but gas says that ldrd is not valid for this processor. as far as i can tell all of the targets that use -mcpu=arm9e could switch to -mcpu=arm946e-s, which appears to be the actual ARM core in the SoC on these devices. 05.44.06 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.48.38 Quit Horscht ("Verlassend") 05.54.25 # hrm... is there any reason to use cmps on arm instead of cmp? i'm getting a warning about the s modifier being deprecated for cmp. 06.02.08 Quit luke_dozen (Read error: 110 (Connection timed out)) 06.08.09 # * JdGordon prepares a pretty contentious commit :) 06.08.47 # Which one? 06.09.27 # clip keymap changes.... dont worry.. I'll put it on FS first though 06.09.55 # I was thinking of being an ass and implementing 100% customisable keymaps this evening though :) 06.10.15 # You live on the same continent as me now, remember that. :-P 06.11.28 # I can take you on! :D 06.11.47 # JdGordon: i have seen you =P 06.11.57 # I can take you also! 06.12.01 # mmmhmmm 06.12.09 # I've bulked up since you last saw me :p 06.12.16 # ... not really :'( 06.13.16 # WTF? home+left is pageup in the list? 06.13.50 Join dash32 [0] (n=dash32@p54AB4D0D.dip.t-dialin.net) 06.25.04 # * JdGordon has managed to make it worse! 06.32.40 # Llorean: you have a clip yeah? 06.32.55 # Yup 06.33.33 # agg, never mind, I thought the pitchscreen combo was home+up not select+up 06.33.43 # I dont think home+up works 06.34.40 # Combos are limited? 06.34.52 # i cant tell... code looks like it should work 06.35.02 # keymap isnt letting me do anything with home+up though 06.35.05 # which sucks... 06.39.00 # Llorean: can you check in home+right (pg down) in the lists work please? 06.39.55 # * JdGordon has a suspision 06.40.06 # not to be confused with a suspicion 06.40.40 # Doesn't seem to do anything 06.40.55 # but home+left works? 06.40.58 # If I hold "Home" and press right more than once quickly, I actually end up back at the home menu 06.41.35 # I tihnk buttons in the same "column" cant be mapped together 06.41.46 # I can do Home+Left if I press them at nearly the same time 06.41.52 # If I hold Home, then wait, then press left, nothing happens 06.41.55 # So I can't go up multiple pages 06.41.57 # which means no home+up or home+right 06.42.17 # home+left doesn't really work either. 06.42.20 # can't be mapped limited by what? 06.42.27 # hardware 06.42.27 # rockbox or the hardware? 06.42.28 # you have to release home, then press it again, for each press of left. 06.42.33 # hm 06.42.50 # thats a keymap issue though, not hardware.. i tihnk 06.43.08 # Other combos don't normally work like that, but okay 06.43.22 # I guess it's Home+Left rather than Home(Repeat) + Left 06.44.13 # BUGGER... this makes the keymap much more painful 06.44.32 # didnt want to use select as the main modifier because its all too cramped 06.45.28 # Yeah, someone should write a letter to sandisk about their inconsiderate hardware design for added features 06.46.19 # * JdGordon wonders who might have all this time now he's not spamming the forums and mailing lists... :D 06.46.55 Join _lifeless [0] (n=lifeless@188.16.122.181) 06.54.13 Quit dash32 (Read error: 104 (Connection reset by peer)) 06.55.21 *** Saving seen data "./dancer.seen" 06.56.05 # down in the wps is id3 and pitch screens... which should be quick and which should be repeat? 06.57.11 # ^ that is why we need partially customisable buttons... 06.57.48 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 06.59.46 # yeah, I reckon this is pretty useable now... 07.00.25 # roughly how long should it take to reflash the H120 bootloader? 07.00.37 # I'm guessing <0.5s is means something went wrong 07.01.15 Join __lifeless [0] (n=lifeless@188.16.122.181) 07.01.19 Quit __lifeless (Read error: 104 (Connection reset by peer)) 07.02.24 Join dash32 [0] (n=dash32@p54AB4D0D.dip.t-dialin.net) 07.03.29 Quit dash32 (Remote closed the connection) 07.05.15 Join dash32 [0] (n=dash32@p54AB4D0D.dip.t-dialin.net) 07.06.55 Join kugel [0] (n=kugel@rockbox/developer/kugel) 07.08.36 # FS#10421 is my clip keymap changes... hopeing its not too contentious... 07.10.13 # JdGordon: maybe r21253 has something todo with the failiure of some combos 07.11.01 # * kugel loves the fuze keymap, btw, sad thing it can't be that way on the clip 07.11.53 # Unhelpful: can you share the binaries? 07.12.43 # Unhelpful: So rockbox just works with eabo, or did you need to make some modifications to it or the compiler or special options? 07.13.57 # eabi* 07.14.43 # kugel: i'm loading it on my e200 shortly. :) 07.15.04 # i've not cleared *all* the new warnings yet, either, only the ones in core. :/ 07.15.52 # could you also make a samsa build, to see if there's other binsize changes (the amses don't have long calls)? 07.16.32 # if you build for fuze, you could send me the binary also 07.16.44 # or the zip rather 07.17.59 Quit _lifeless (Read error: 113 (No route to host)) 07.22.13 # kugel: when it doesn't crash on mp3 playback i'll let you know ;) 07.25.38 # core jpeg appears to be a bit broken :) 07.28.03 Quit kugel (Remote closed the connection) 07.30.26 # most of the core stuff should probably have been fixed anyway... it was all things using int in places of enum themable_icons 07.31.58 Quit dash32 (Remote closed the connection) 07.33.40 Quit amiconn (Nick collision from services.) 07.33.42 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 07.33.46 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 07.33.46 Quit pixelma (Nick collision from services.) 07.33.59 # here's the diff: http://pastie.org/541009 07.34.01 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 07.34.03 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 07.34.52 # keep in mind that the gcc patch, which is downloaded, also needs to be edited... replace the arm9e with either arm9 or arm946e-s for libgcc to build. 07.36.12 Join stoffel [0] (n=quassel@p57B4C624.dip.t-dialin.net) 07.37.32 # i should double-check that both the snapshot version of binutils and the eabi arch setting are required. if the binutils alone could do it, it would save us a bit of trouble, i think. 07.59.34 # Unhelpful: Congrats :) Those rockbox code fixes should probably be committed independently of the actual eabi switch 08.00.39 # Does the build work properly apart from core jep? What kind of breakage do you see there? 08.00.42 # amiconn: it crashes on mp3 playback, at an address about .icode. vorbis playback starts, but there's no progress. and the cover art was a disaster. :/ 08.00.56 # s/about/above/ 08.03.10 # i wouldn't be surprised if there are some code generation oddities... i've no idea at all why it's emitting instructions while building libgcc for arm9e that it then claims are not valid. :/ 08.03.38 Part toffe82 08.04.31 # What gcc version did you use? 08.04.49 # Perhaps binutils 2.19 should be used in conjunction with a newer gcc as well 08.05.20 # Iirc the debian wiki mentions gcc 4.1.1 as the first with "usable"eabi support 08.05.27 # it would be nice if we could just have a linker option to generate the long-call "veneers"... they seem quite sensible really, it sets up just as if for a short call to the function, using the veneer address, and then the veneer address has a pc-relative ldr to pc, and the target address of the real function. 08.06.43 # is there any specific claim made as to which gcc versions are compatible with which binutils? 08.07.51 # I don't know. I do know though that some combinations definitely won't work, at least for coldfire 08.09.03 # are either of the components of these "bad" combinations known to work in combination with other versions? 08.09.34 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 08.16.25 Quit FlynDice (Remote closed the connection) 08.18.10 # with regard to the deprecated cmps... changing those to cmp should be fine, right? 08.18.14 Quit MrDuck (Read error: 113 (No route to host)) 08.19.10 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 08.28.18 # Unhelpful: The coldfire incompatibility is caused by a change in cpu naming. Binutils >= 2.17 will only work with gcc >= 4.1 and vice versa, at least for some cpus of the m68k/coldfire family 08.30.19 # binutils-2.19.51 + gcc-4.1.2 still gives me the same errors building libgcc. :/ 08.30.42 # * amiconn would try 4.3.x or 4.4.x 08.31.22 # conveniently i made sure i had archives for those while i was at a decent connection. :) 08.31.36 # but yes, if i'm going to use a binutils on the bleeding edge... 08.32.14 # I wouldn't use bleeding edge binutils, but rather release 2.19 or 2.19.1 08.32.41 # The s in 'cmps' is purely redundant, so these should be changed to 'cmp' 08.33.17 # Same for 'cmns', 'tsts' and 'teqs', should we have such 08.33.29 # http://www.sourceware.org/ml/binutils/2006-05/msg00075.html 08.35.10 # i had the relocation errors until i used 2.19.51... 08.37.22 Join einhirn [0] (n=Miranda@p5DCC1963.dip0.t-ipconnect.de) 08.38.01 Quit safetydan ("Leaving.") 08.42.49 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 08.43.14 # hmmm 08.53.00 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 08.53.42 # i'll try 2.19.1 with 4.4.0. if i get relocation errors i'll have to try the snapshot again. i found mailing list messages regarding newly-committed work to generate veneers in some previously-unsupported cases, so i'm guessing that 2.19.1 won't work... but we'll see. 08.54.09 Join Rob2222 [0] (n=Miranda@p4FDCC312.dip.t-dialin.net) 08.55.20 # Hmm, there's only 4.4.0 in the 4.4.x line now? In that case I'd probably try 4.3.x (x == maximum available) 08.55.22 *** Saving seen data "./dancer.seen" 08.55.54 # * amiconn trusts x.y.0 versions of gcc even less than gcc in general :\\ 08.56.07 Quit einhirn (Read error: 104 (Connection reset by peer)) 08.57.36 # * amiconn expects at least some problems in rockbox code to show up on newer gcc 08.58.06 # Probably not many in generic code which is also built for the sims, more in target specific code 09.03.45 # i'd expect generic code to have been shaken out pretty well, given how fresh the gcc shipping with many linux distributions tends to be. 09.09.27 Join MrDuck [0] (n=kachna@r3g248.net.upc.cz) 09.10.05 Quit robin0800 ("Leaving") 09.10.08 Join petur [50] (n=petur@rockbox/developer/petur) 09.10.24 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.16.14 Quit robin0800 ("Leaving") 09.17.37 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.18.35 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 09.18.43 Quit robin0800 (Client Quit) 09.18.45 Quit Rob2223 (Read error: 110 (Connection timed out)) 09.19.03 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.24.52 # amiconn: oh! i suspect i know the cause of the jpeg trouble. possibly the other things, as well. EABI specifies different structure packing. i bet the size of struct uint8_rgb changed... it's {uchar;uchar;uchar} so it could very well be unpadded now. 09.24.53 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.25.56 # hrm: /home/chshrcat/rockbox-crossdev-test/arm-elf-eabi/lib/gcc/arm-elf-eabi/4.4.0/../../../../arm-elf-eabi/bin/ld: error: no memory region specified for loadable section `.ARM.extab' 09.26.31 # that could actually account for crashes in pretty much anything that mixes C and asm if structures are involved, too, i suppose? 09.27.02 # It depends on what assumptions the asm makes about struct alignment 09.27.26 # Regarding arm.extab - that means the linker script(s) need adjustment 09.28.23 # we need to add it somewhere? 09.29.12 # Maybe we can just drop it 09.29.53 # how would i go about doing that? 09.30.05 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.30.22 # ".ARM.extab names a section that contains exception unwinding information." 09.30.28 # actually, i think i see how :) 09.30.33 # I don't know whether we need this, but probably we don't 09.31.49 # hrm, getting rid of .ARM.exidx makes link angry... unresolved symbols from libgcc now. :/ 09.37.23 # * Unhelpful scratches his head @ /home/chshrcat/rockbox-crossdev-test/arm-elf-eabi/lib/gcc/arm-elf-eabi/4.4.0/../../../../arm-elf-eabi/bin/ld: .ARM has both ordered [`.ARM.exidx' in /home/chshrcat/rockbox-crossdev-test/arm-elf-eabi/lib/gcc/arm-elf-eabi/4.4.0/arm7tdmi/libgcc.a(bpabi.o)] and unordered [`.ARM.extab' in /home/chshrcat/rockbox-crossdev-test/arm-elf-eabi/lib/gcc/arm-elf-eabi/4.4.0/arm7tdmi/libgcc.a(_udivdi3.o)] sections 09.39.58 Quit robin0800 ("Leaving") 09.40.00 # oh, and reloc errors again. i think perhaps i'd best try binutils-2.19.51 again, maybe with gcc-4.3 09.40.15 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.43.17 # YAAAY I unbricked my iriver 09.43.27 # about 4 full days of work 09.44.03 # ...bugger, with the BDM interface soldered on I can't put the CF card in 09.48.08 Quit Thundercloud (Remote closed the connection) 09.52.58 Quit kadoban (Remote closed the connection) 09.54.51 # ReKleSS: congrats man 09.58.33 Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 10.03.18 Quit scorche (Read error: 104 (Connection reset by peer)) 10.04.22 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 10.04.37 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 10.25.06 # ReKleSS: BDM? 10.25.44 # tmzt: http://en.wikipedia.org/wiki/Background_Debug_Mode_interface 10.26.12 # thanks 10.26.19 # something like jtag? 10.26.37 # sure 10.27.23 Join J-23_ [0] (n=zelazko@unix.net.pl) 10.28.42 Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) 10.35.45 Join mc2739_ [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 10.36.30 Quit J-23 ("wszedłem") 10.38.39 Join J-23 [0] (n=zelazko@unix.net.pl) 10.43.20 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 10.44.17 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 10.44.17 Quit trisiak (Read error: 110 (Connection timed out)) 10.50.20 Quit mc2739 (Read error: 110 (Connection timed out)) 10.52.34 Quit stoffel (Remote closed the connection) 10.53.32 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 10.55.26 *** Saving seen data "./dancer.seen" 10.56.18 Part Grahack 11.06.09 Join kugel [0] (n=kugel@rockbox/developer/kugel) 11.08.05 Quit mc2739_ (Read error: 110 (Connection timed out)) 11.10.19 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 11.25.44 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 11.31.35 Join mt [0] (n=MTee@41.233.150.185) 11.39.31 Quit kugel (Read error: 110 (Connection timed out)) 11.52.56 # Torne: no luck with that configure option, nor with adding -fno- while compiling RB. 11.53.12 # send me your libgcc.a and i'll see what's different 11.56.01 # also, which input objects have an exidx/extab section anyway? 12.02.10 # is there an easy way to list just the sections? 12.03.34 # objdump should be able to 12.03.43 # -d or -x I think 12.06.54 # almost all of rockbox has them. :/ 12.10.50 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 12.14.11 # + lines are object files with, - are ones without: http://pastie.org/541170 12.19.05 # Unhelpful: that looks like "all the objects containing C functions" to me 12.19.09 # pretty much all of those files reference __aeabi_unwind_cpp_pr0 12.19.20 # pretty much, yes. :) 12.19.31 # which is what you expect from compiler-generated unwindings :) 12.20.06 # i am totally puzzled on why it's generating them at all 12.22.29 # with my toolchain, a trivial C file gets an exception table if compiled with g++ but not if compiled with gcc 12.23.08 # which is what you'd expect: g++ has to generate one for every function, unless it can prove it's a leaf which doesn't throw (or only calls functions which ultimately call leaves which don't throw, in the same object file) 12.25.02 Join n1s [0] (n=n1s@rockbox/developer/n1s) 12.26.39 # Unhelpful: what happens if you compile something entirely trivial and unrelated to rockbox, like http://pastie.org/541177 with that gcc? 12.26.48 # is there exception info in the object produced? 12.27.32 Join kugel [0] (n=kugel@rockbox/developer/kugel) 12.29.34 Quit J-23 ("wszedłem") 12.30.48 # no... all normal stuff. 12.31.19 # right... so what about args/etc? 12.31.51 # there must be *something* making it decide to generate extab for every bloody thing :) 12.33.32 Join trisiak [0] (n=tree@chello089078243195.chello.pl) 12.38.39 # well, for one, i note that when i tried to kill exceptions, i used -funwind-tables rather than -fno-unwind-tables 12.38.53 # ...not that fixing that fixed rockbox 12.38.59 Join J-23 [0] (n=zelazko@unix.net.pl) 12.39.27 # Unhelpful: gcc should always have those things off by default anyway 12.39.30 # adding our GCCOPTS doesn't create them... 12.39.40 # so it must be something in our code, then :) 12.39.54 # take a nice small file from rockbox that produces exception tables and #if 0 loads of it out 12.39.58 # try and narrow it down :) 12.40.31 # i doubt we have any "small" files if you consider includes... 12.40.43 # if 0 those out as well 12.40.56 # hack and slash job until some subset happens to compile :) 12.42.00 # if you send me what you changed in rockboxdev.sh i'll have a go later on 12.42.52 Join atb [0] (n=atb@69.90.52.123) 12.48.20 # wait a sec, removing that errant -funwind-tables killed them from the files... but i still get the link errors related to get_eit_entry and friends. 12.48.40 # right, that's a more directly diagnosable problem 12.48.59 # as long as gcc isn't emitting any into things it compiles, then it's just the runtime libraries trying to be C++ friendly 12.49.48 # objdump -x libgcc.a into pastebin? :) 12.49.51 # in fact, none of our objects contain any now, so what gives? 12.50.17 # an object in libgcc probably does, or refers to the unwinding functions directly 12.51.34 # it'd have to be an object that *we* refer to, though, wouldn't it? 12.51.42 # indirectly, yes 12.51.58 # something referred to by something referred to by something we refer to :) 12.52.15 # just paste me the whole of libgcc and i can probably spot it ;) 12.53.07 # weird, i can't paste into pastebin... 12.55.09 # ugh. half a MB. this might not make it up over my cell :) 12.55.17 # eep 12.55.21 # also, apt-get install pastebinit :) 12.55.30 *** Saving seen data "./dancer.seen" 12.55.45 Quit flydutch (Read error: 104 (Connection reset by peer)) 12.55.55 # "We did say the maximum allowable file size is 150,000 bytes. You sent us a file that is too big. Sorry, it is being ignored." :) 12.56.05 # aw 12.56.24 # i guess otherwise you could transfer big binaries with base64 :) 12.57.16 # conveniently it's highly compressible: http://filebin.ca/equvwp/libgcc.dump.bz2 12.57.28 # actually, seeing as filebin accepts anything <50MB... 12.57.33 # well if you were just going to send a binary you could upload the library 12.57.39 # but this is fine :) 12.58.35 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 12.59.58 # seeing as you insist: http://filebin.ca/qoxowz/libgcc.a 13.00.27 # interesting 13.01.00 # it looks suspiciously like my pykern binary just doesn't happen to include any of the objects that have exception info 13.01.07 # which seems odd given that that includes "division" 13.02.09 # New commit by 03zagor (r21738): Fixed build score sort bug. ... 13.02.38 # Unhelpful: did you try explicitly discarding the exidx and extab sections? 13.02.48 # yes. 13.03.05 # hm, did it definately get their relocs as well? 13.03.52 # i've no idea how to make sure? 13.04.41 # i just added a *(.ARM.extab) to our existing /DISCARD/ 13.04.53 # also exidx? 13.04.57 # you might need a wildcard on the end 13.05.12 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 13.05.22 # *(.ARM.extab) *(.ARM.extab.*) *(.ARM.exidx) *(.ARM.exidx.*) 13.05.37 # * Torne experiments building stuff with division 13.06.00 # yup, just tried that. 13.07.34 # * Torne shakes fist at gcc for optimising away his divisions :) 13.08.11 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 13.11.26 # isn't there -O0 for that? 13.11.49 # switching the operands is quicker. :) 13.11.51 Join stoffel [0] (n=quassel@p57B4C624.dip.t-dialin.net) 13.11.58 # anyway. i can do integer division without bringing in exception info either 13.12.24 # a partial link against libgcc gives me implementations of __aeabi_idiv and also __aeabi_idiv0 which don't have exception tables. 13.15.46 # yeah, it's _divdi3 that's bringing it in for you 13.16.27 Quit dmb (Read error: 104 (Connection reset by peer)) 13.17.00 # there must be some way to tell it to throw them away :( 13.22.47 # Unhelpful: which linker script did you add the discards in? :) 13.25.14 # discarding the sections really should work. 13.25.44 # the linux kernel ld script does it, for exactly the ame reasons 13.27.38 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 13.27.52 Quit stoffel (Remote closed the connection) 13.28.10 Quit mc2739 (Client Quit) 13.28.33 Join stoffel [0] (n=quassel@p57B4C624.dip.t-dialin.net) 13.30.30 # New commit by 03mcuelenaere (r21739): Lua: ... 13.31.31 # 2.5min per toolchain 13.31.39 # oops 13.36.59 # some config-*.h seem to say that HAVE_LCD_SLEEP_SETTING is optional, but if I don't define it I get an undeclared LCD_SLEEP_TIMEOUT error .. ? 13.37.50 # ah nvm, I found HAVE_LCD_SLEEP_SETTING 13.39.48 # mcuelenaere: if you don't define _SETTING you need to define the hardcoded timeout 13.40.18 # kugel: yes, I just figured that out :) However, it sounds more logical to me that if you don't define _SLEEP_TIMEOUT, it uses the setting 13.40.56 # mcuelenaere: if your display isn't readable without backlight (and if waking up doesn't take too long), you could also ignore _SLEEP and put all power saving into lcd_enable() 13.41.39 # kugel: ah, that's how it's currently done; however I don't see a call to lcd_enable() when the backlight turns off ? 13.41.47 # (I added some logf's) 13.43.17 # mcuelenaere: that call should be in _backlight_off() of your lcd driver 13.43.40 # kugel: ah; and don't you mean the backlight driver? 13.43.46 # I haven't made it target independant like lcd_sleep() yet because I recall the F/X is still doing it wrong somehow and I don't want to break it 13.44.06 # ok 13.44.43 # but the difference between lcd_enable() and lcd_sleep with _TIMEOUT == 0 is neglible 13.48.43 # Torne: firmware/target/arm/sansa/app.lds. pretty sure it's the right one as make bin re-preprocesses whenever i modify it. but my system with arm-elf-eabi is packed up for the day 13.49.55 # Unhelpful: yah. i might have a go late r:) 13.50.59 # you need a snapshot binutils... as far as i can find those aren't on gnu.org? i posted a diff earlier with most of what you should need, although i'm now using a later gcc. 13.52.06 # that sounds like a hilarious nightmare. :) 13.53.18 # New commit by 03kugel (r21740): Fix a few comments in gwps.c. 13.53.45 # well, this exception nightmare started when i built a later gcc. if you use an arm-elf-eabi gcc with binutils <=2.19.1 you still get the reloc errors because it apparently *doesn't* generate stubs for most function calls 13.55.15 # fun 13.55.43 # tbh there may be some intrinsic value in moving to eabi anyway, as long as it proves not to make anything slower/bigger ;) 13.56.36 # it might be worth padding uint8_rgb to 4 bytes... pixel-fits-in-a-register could come in handy. :) 13.57.15 # indeed, someone will want to look at all the things whose size have changed and see whether it's really a win or not 13.59.00 # and somebody *must* look at all of the things that pass C structs to asm functions. i'm pretty sure that's why core jpeg was hosed, and i suspect that's how the mp3 codec ended up at an address somewhere past it's .icode section. 13.59.29 # fun 14.12.24 # Unhelpful: It would also safe load/store instructions, wouldn't it? 1 ldr vs 3 ldrb 14.12.28 # save* 14.17.29 Part linuxstb ("Leaving") 14.18.19 # kugel: unless you need to inspect the component values, yes. everything that uses uint8_rgb to my knowledge *does* unpack the components. 14.19.03 Join GreatBeaver [0] (n=chatzill@c-71-59-18-236.hsd1.ga.comcast.net) 14.19.06 # hi 14.19.21 # i have been searching far and wide for an alternative to using h120 as a transport 14.19.51 # does anyone know if there is a 500gb external multimedia harddrive that can replace the h120 as transport? 14.20.02 # with coax or usb or optical 14.22.32 # New commit by 03alle (r21741): Fix a typo 14.27.37 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.33.14 # How did I miss that one !? 14.35.20 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 14.36.03 # kugel: another typo on the same line -- surpress should be suppress 14.36.31 # hm 14.36.51 # I recall looking in a dict for that word when i wrote it, don't know what happened 14.39.49 # Zagor: Server connection stalled. Exiting! -- this happens just before I get the duplicate name error. 14.40.40 Quit n1s (Read error: 110 (Connection timed out)) 14.41.29 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 14.41.45 # does anyone know of a harddrive that can be used as a transport for audio? 14.42.01 # Any Rockbox DAP? 14.42.16 # i am using an h120 optical out 14.42.20 # but i want more space 14.42.29 # You can upgrade the hard drive in the H120 easily. 14.42.40 # i am waiting for amazon to have the 80gb mk8025gal in stock 14.42.56 # but im researching 500gb-1tb harddrive with transport capability 14.43.17 # is there anything like it without the crazy price of music servers? 14.43.27 # Sorry, but no 1.8" hard drive has even reached that capacity yet. 14.43.53 # just a few months ago this came out 14.43.55 # http://sdd.toshiba.com/main.aspx?Path=StorageSolutions/1.8-inchHardDiskDrives/MK8025GAL/MK8025GALSpecifications 14.44.44 # i have the adapter but the mk8025gal is rare 14.45.06 # And I'm going to also bet rather expensive. 14.45.29 # You can also perform a CompactFlash mod on your H120. 14.45.48 # 64gb cf is very expensive 14.45.54 # 80gb hdd is $100 14.49.14 # i think i might just get a laptop known for its transport quality 14.49.34 # the rarity of harddrive based transports and their price is crazy 14.50.06 # * GodEater wonders how you define "transport quality" 14.51.54 # New commit by 03funman (r21742): Sansa AMS SD driver: fix error checking in µSD insertion ... 14.53.09 # less jitter 14.53.20 # good software 14.54.39 # I'm still not understanding 14.55.32 *** Saving seen data "./dancer.seen" 14.55.34 # an audiophile transport 14.55.44 # with low emi/rfi 14.56.32 # GodEater: he means transport as in outputting an audio signal, not as in moving mp3s around 14.57.06 # but he asked for a harddrive. Harddrives don't ouput an audio signal. 14.57.13 # * GodEater is clearly confused 14.58.10 # i mean a multimedia harddrive 14.58.12 # a harddisk transport is a box with a hard drive and an audio out and enough of a processor to play audio off the drive 14.58.19 # i.e. an mp3 player, but less portable :) 14.58.31 # do you know of any good ones Torne ? 14.58.34 # Nope 14.58.35 # never even heard of the things 14.58.42 # im searching everywhere and no luck im about to just search for notebooks 14.58.53 # GodEater: they're a replacement for carting huge boxes of CDs around to DJ with, or hwatever :) 14.59.42 # anyway, no we don't know, it seems, and this is offtopic: this channel is for rockbox development and support 14.59.53 # any rockbox player will do what you want, but may not have enough storage: website lists them all 15.00.01 # other than that we are unlikely to know 15.00.20 # maybe rockbox should rockbox a multimedia harddrive ^^ 15.00.35 # I'm not sure what percentage of rockbox people that hang out here are audiophiles anyway 15.00.40 # I'm certainly not ;) 15.00.45 # indeed :) 15.01.50 # GreatBeaver: anyone's welcome to try a port like that if they have the hardware for it :) 15.02.08 # we don't write ports because someone else wants them; we help people do it themselves :) 15.02.20 # i have to find a harddrive with a display interface 15.02.25 # cant find any 15.03.01 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 15.03.15 # is it possible to rockbox a computer? 15.03.25 # like no operating system just rockbox 15.03.29 # no. 15.04.34 Quit bmbl (Read error: 110 (Connection timed out)) 15.04.35 # nobody has done a PC port; it's assumed that such a thing would not be particularly useful 15.05.00 # what an utter waste of a computer it would be. 15.05.09 # it could bypass the windows kmixer with certainty though 15.05.19 # that resamples music to 48khz 15.05.26 # if you don't like windows's sound system, don't run windows 15.05.31 # windows is a dirty word here :) 15.05.38 # yes, we should rockbox windows 15.05.45 # there are other operating systems with other sound systems 15.06.19 # yes but im boycotting apple 15.06.31 # there are other OSes besides OSX too 15.06.50 # there are a plethora of them in fact 15.06.52 # Linux? DOS? The BeOS derivatives? The BSDs? etc :) 15.06.58 # QNX 15.07.00 # but do they start up as fast as rockbox? 15.07.13 # QNX does. 15.07.20 # they start up faster than rockbox, given that rockbox doesn't start at all on PC hardware 15.07.28 # hehe 15.07.31 # and thus its startup time would have to include "port rockbox to PC" 15.07.35 # which would be months :) 15.07.44 # Month shmonths. 15.08.02 # courtc: depends if you want it to work on any pc other than the author's, really :) 15.08.17 # getting an OS to run on *one* PC is not too difficult, getting it to run on a majority of PCs is a lot more work ;) 15.08.21 # i think i'll just hardwire my h120 to a 1tb harddrive 15.08.40 # GreatBeaver: if you're happy with the sound hardware on the h120 then that sounds like a perfectly sensible plan 15.08.51 # assuming we can support that big a drive which i have no idea 15.08.51 # i only use the optical output on the h120 15.09.14 # maybe the external harddrive needs to be plugged to a power supply 15.09.29 # Nah, it's easy, as long as you don't care about functionality, which would be given, since you are porting rockbox to a pc. 15.09.54 # WHY IS THIS WORLD SO CRUEL TO AUDIO PEOPLE 15.09.58 # courtc: there's several dozen popular sound chipsets to support, for a start :) 15.10.06 # courtc: without which rockbox would be *particularly* useless 15.10.11 # Who said anything about sound? 15.10.53 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 15.11.23 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 15.11.24 # fork the project, and call it NotSoRockBox. 15.13.41 # i think i will make my own laptop and rockbox it 15.13.55 # i only trust rockbox software 15.14.05 # i dont trust any operating system to handle the audio data 15.15.08 # Hrm... wouldn't be much of a laptop, why don't you just buy a DAP? 15.15.09 # see, guys? Fanboys DO exist on our planet. 15.15.23 # courtc: because he wants a 1TB hard drive :) 15.15.34 # and they don't make those in 1.8" :) 15.15.46 # Sure they do... I bet. 15.16.18 # Commission one from toshiba, they'd be happy to oblige... for the right price. 15.16.26 # Price. Exactly 15.18.34 # Just get a DAP with wifi; make rockbox work with wifi/said DAP; precache playlists. 15.19.32 # GreatBeaver: Not to rain on your parade, but Rockbox resamples everything to 44.1kHz 15.20.06 # 44.1khz is what i want 15.20.13 # i dont listen to 96khz 15.20.40 # would it be worthwhile writing up my H120 unbrick procedure? 15.21.00 # it involves soldering wires to the motherboard and wiring it to a microcontroller... 15.21.03 # ReKleSS: if it's not already on the wiki, then ys, put it there 15.21.08 # nm im just going to use 80gb hdd on the h120 15.21.13 # well, if you can be bothered ;) 15.21.50 # you guys made an awesome software for h120 15.21.58 # i will just buy more h120's if i need more space 15.23.05 Join BdN3504 [0] (n=5ce227df@gateway/web/cgi-irc/labb.contactor.se/x-001b70fc5385bdd7) 15.23.39 # is any dap company going to pay rockbox for their software? 15.23.48 # i bet rockbox is 100x better than the ipod software 15.23.53 # apple should pay you guys for it 15.26.03 Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) 15.26.14 # is marc guay around? i just saw that the bootloader task has changed. Was the name only updated or did you also change the bootloaders? or have only some bootloaders been updated? is the sansa bootloader new? then i'll test... 15.26.25 # it should also be possible to make a 1,8 -> 3,5 adapter and connect a 2TB Harddrive to a rockboxed DAP.. Of course thats not very transportable :-) 15.26.46 # oooooo thats what i want ^^ 15.27.42 # i dont think an h120 has enough juice to power on that harddrive though 15.27.49 # any DAP witha 1TB drive attached is at least going to need a custom build of Rockbox with LBA48 compiled in. 15.27.51 # GreatBeaver: I've often wondered about a Rockbox port to a multimedia appliance, but there's nothing on the drawing board that I know about. You might try looking at something like a Mac Mini and go the HTPC route. 15.28.23 # yeah but i will have to research if people think it is good quality optical output first 15.28.24 # GodEater: yes, but thats only a define. no real work needed... :-) 15.28.46 # also i have something against apple, i dont like how they boycott flac 15.29.01 # GreatBeaver: define "good quality". 15.29.09 # hrm... should the svn bootloader be ... maybe not safe, but at least somewhat tested? 15.29.17 # equivalent to expensive audiophile cd transports 15.29.24 # lots of people don't implement FLAC in their DAP firmware. 15.29.27 # it's not just Apple 15.29.43 # yeah which means im boycotting them too :D 15.30.05 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 15.31.55 # GreatBeaver: expensive "audiophile" CD transports are often triumphs of marketing over engineering. Unless you have an extremely discriminating system (and if you're worried about the expense of HDD capacity, you don't have one) you just can't tell the difference between an "audiophile" transport and a $49 Walmart special CD player. Digital is digital. 15.32.15 Quit n00b81 (Client Quit) 15.32.40 # ya i have a pretty expensive headphone system though 15.32.54 # $500 dac, $1000 amp, $500 headphones 15.33.09 # GreatBeaver: I'd be far more concerned about playable formats vs. tachnical stats that can not audibly discerned. 15.33.14 # tech 15.33.19 # yes formats is important to me 15.33.27 # GreatBeaver: That's nice and all, but can you please keep it on topic here? 15.33.32 # Sorry. 15.34.13 Join stettberger [0] (n=stettber@peer.zerties.org) 15.34.22 # maybe in the future i'll buy a mac mini and rockbox it 15.34.26 # With all that said, *can* Rockbox be ported to an appliance? 15.34.27 # i'll let u guys know how it goes 15.34.43 # GreatBeaver: how will you do that? Rockbox doesn't run natively on PC hardware of any sort. 15.36.08 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 15.36.31 # is here anybody, who uses rockbox on an sansa e200v2? 15.36.58 # stettberger: you're better off just asking your actual question. 15.37.55 Quit stoffel ("No Ping reply in 90 seconds.") 15.38.16 Join stoffel [0] (n=quassel@p57B4C624.dip.t-dialin.net) 15.38.22 # i want to try the actual development, but with the longer thread in the forum (72 pages atm) i don't get an ideo how to do so 15.38.50 # is there some condensed information? 15.39.01 # SansaAMS wikipage 15.39.20 # And the source code is also a good place to look at what's been done so far. 15.39.32 # And the official testing builds forum, where we published installation tools and methods 15.40.02 # And here. If you have a specific question, ask away. 15.40.23 # ah, ok is see thank you, i think that will be a good starting point 15.41.20 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-131b8d4f6bc52f0c) 15.45.53 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 15.46.32 Quit Zarggg (Read error: 104 (Connection reset by peer)) 15.47.04 Quit stoffel (Remote closed the connection) 15.47.31 Join stoffel [0] (n=quassel@p57B4C624.dip.t-dialin.net) 15.51.36 # yeahaa, rockbox is really working on it :-) thx to all developers 15.57.15 # stettberger: Even at this early stage, quite a lot works on the AMS Sansas. 15.57.29 # stettberger: If you see any places where improvments can be made, feel free to chip in. 15.57.50 # We always welcome volunteers to the project... that's how it works. :) 15.58.05 # its written in c or? 15.58.24 # stettberger: Mostly C, with some assembler for speed-specific bits. 15.58.24 # stettberger: Almost entirely in C 15.59.03 # nice :-) 16.00.20 # stettberger: So feel free to checkout the source from SVN and dig in. 16.02.38 # there is only one rockbox svn where the code for all models is in? 16.03.28 # Yep. 16.03.40 # all models? 16.03.46 # If you have svn installed, run svn co svn://svn.rockbox.org/rockbox/trunk rockbox 16.03.50 # bubsy: All models. 16.04.03 # even Creative Zen Vision:M? 16.04.05 # No. 16.04.12 # ifdef-hell? 16.04.15 # bubsy: There's code for the ZVM in the trunk. 16.04.26 # without a proper HDD initalizer 16.04.29 # But it's not a complete port by any means. 16.04.30 # stettberger: There's some, but it's better than it has been 16.06.39 # New commit by 03teru (r21743): Correct return value of function get_ucs, position of next character, in viewer plugin (FS #9387, patch by Yoshihisa Uchida, small modification by ... 16.22.38 Quit BdN3504 ("CGI:IRC (EOF)") 16.23.14 Join Zarggg [0] (n=zarggg@65.78.69.194) 16.30.53 Join BdN3504 [0] (n=5ce227df@gateway/web/cgi-irc/labb.contactor.se/x-65ad84c60b5cabb4) 16.31.19 # somebody give me a quick link to the latest sansapatcher please. 16.33.08 # nvm 16.33.09 # http://download.rockbox.org/bootloader/sandisk-sansa/sansapatcher/ 16.34.18 Quit robin0800 ("Leaving") 16.34.18 Quit BdN3504 (Client Quit) 16.34.41 Join robin0800 [0] (n=robin080@81.98.157.181) 16.36.56 Quit courtc (Read error: 104 (Connection reset by peer)) 16.37.00 Join courtc [0] (n=court@unaffiliated/courtc) 16.37.25 Quit timc (Remote closed the connection) 16.37.34 Quit stoffel ("No Ping reply in 90 seconds.") 16.37.56 Join stoffel [0] (n=quassel@p57B4C624.dip.t-dialin.net) 16.38.00 Join dash32 [0] (n=dash32@p54AB4D0D.dip.t-dialin.net) 16.47.47 Quit ReKleSS (Read error: 110 (Connection timed out)) 16.49.42 Join BryanJacobs [0] (n=bryanjac@128.151.67.243) 16.55.35 *** Saving seen data "./dancer.seen" 17.01.06 Join toffe82 [0] (n=chatzill@74.0.180.178) 17.03.35 Quit teru ("Quit") 17.05.59 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 17.08.51 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 17.13.54 Join domonoky1 [0] (n=Domonoky@g229247165.adsl.alicedsl.de) 17.15.39 Quit mt (Read error: 104 (Connection reset by peer)) 17.16.28 # kugel: thanks for your pointers yesterday. I've added those into the lcd_update routine, and fixed a missing udelay in my SPI function, but still no luck displaying anything 17.17.29 # obo: lcd_update is mainly "flushing" the rockbox framebuffer into the gram. 17.18.01 # I would try to that manually (just writing a red pixel or so), to see if the the adresses are correct, at least 17.18.25 # yup, it's coded at the moment to dump the entire thing over. I've tried that, no effect 17.20.19 Join mt [0] (n=MTee@41.233.150.185) 17.25.09 Quit petur ("beer time") 17.29.08 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 17.32.06 # New commit by 03kugel (r21744): Rearrange things a bit for less #ifdefs and less duplication. 17.32.09 Quit domonoky (Read error: 113 (No route to host)) 17.35.37 Quit flydutch ("/* empty */") 17.40.29 # obo: what are you trying to display?` 17.41.09 Quit BryanJacobs ("Java user signed off") 17.41.14 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 17.41.20 # does lcd_clear_display() (followed by lcd_update()), that should get away with the sandisk logo 17.44.42 # New commit by 03kugel (r21745): Adding last minutes comments to explain things is only cool if you close it also (aka fix yellow). 17.45.41 # kugel: anything but the sansa logo would be good :) Shouldn't just writing a fixed value be even more simple? And since that's not working, I'm not sure what I'm missing... 17.45.58 # that's what clear_display is doing 17.46.42 # maybe you didn't get the window positions right yet, and you actually write outside visible area 17.47.41 # but a hardcoded value has the same effect? Plus that bypasses reading from main RAM (although I think it's mapped properly, I'm not certain) 17.48.00 # kugel: Comment on line 389 needs to be closed 17.48.08 # FlynDice: svn up 17.48.33 # just too fast for me.... 17.49.18 # I'm just trying to go for the most simple, likely to work case to begin with - to try and rule out as many other potential issues as possible 17.50.06 # obo: yes, I understand that. Have you tried to write single pixels or the whole display so far? 17.50.30 # whole display at the moment. 17.51.15 Quit dash32 ("Verlassend") 17.51.16 # kugel: http://www.rockbox.org/twiki/bin/viewfile/Main/GSoCSansaView?rev=2;filename=lcd-view.c - but with a hardcoded value instead of *addr in lcd_update 17.52.22 # obo: You doest seem correct (from what I see what other drivers are doing) 17.53.05 # That doesn't* 17.53.09 # which bit? 17.53.43 # other drivers are seting the window position before the transfer, not within 17.54.15 # 0x22 is the gram register I assume? 17.55.16 # yes, 0x22 is GRAM. 0x20 is horiz GRAM address, 0x21 is vert 17.55.22 # I really can't tell you much as I have no idea of this driver (less that you even), but other drivers are working differently 17.55.40 # I think you set those only once at the beginning 17.55.47 # the hardware will advance the internal pointer 17.56.22 # in which case, with the init routine setting them both to 0x0, they shouldn't need setting at all? 17.56.48 # you need to set them before writing to the GRAM of course 17.57.24 # Okay, I'll try that. 17.57.45 # if they're really only used in the init function then they're probably not that what you're thinking they are 17.57.54 # I wish the datasheet had more details on the SPI mode... 17.58.16 # well, in fact, if you only use fullscreen updates, you might only need to set them once 17.58.34 # but you also don't set the end position, that confuses me a bit 18.00.06 # different registers provide the start and end positions during init 18.02.45 # * JdGordon points clip owners to FS#10421 18.23.22 Join mt_ [0] (n=MTee@41.233.144.236) 18.23.39 Join n1s [0] (n=n1s@rockbox/developer/n1s) 18.27.27 # New commit by 03kugel (r21746): Correct another small typo in a comment. 18.33.57 Join JdGordon| [0] (i=ad75f7a5@gateway/web/freenode/x-b996193561a0d76b) 18.34.18 Quit robin0800 ("Leaving") 18.35.52 Quit MrDuck (Read error: 110 (Connection timed out)) 18.38.04 Join barrywardell [0] (n=barrywar@86-45-11-60-dynamic.b-ras2.prp.dublin.eircom.net) 18.39.41 Quit mt (Read error: 110 (Connection timed out)) 18.52.14 # New commit by 03gevaerts (r21747): Also bump version in trunk 18.53.00 Join mrkiko [0] (n=mrkiko@host232-107-dynamic.24-79-r.retail.telecomitalia.it) 18.53.25 # is it released? 18.53.48 # not yet, no. I just don't want to forget this... 18.55.03 # you mean you just want more build runs... :) 18.55.21 # New commit by 03rob (r21748): Make the TCC NAND driver use the (virtual) disk activity LED. 18.55.36 *** Saving seen data "./dancer.seen" 19.01.04 Quit mt_ (Read error: 101 (Network is unreachable)) 19.01.19 Quit barrywardell () 19.01.27 Join pixthor [0] (n=48c1aacc@gateway/web/cgi-irc/labb.contactor.se/x-2878c4a867cd85f3) 19.02.35 # hmpf 19.02.56 Quit pixthor (Client Quit) 19.03.02 # well said! 19.03.03 Join pixthor [0] (n=48c1aacc@gateway/web/cgi-irc/labb.contactor.se/x-d49d50f260ed4897) 19.03.07 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 19.03.58 Quit thegeek (Read error: 54 (Connection reset by peer)) 19.04.05 # The lost connection detection in the client works, but it is often refused on reconnect due to duplicate name 19.04.17 # ...and neither Zagor nor Bagder are around :\ 19.04.46 # Hey. 19.05.08 # Hey everyone. 19.06.07 Quit JdGordon| ("Page closed") 19.09.14 Quit pixthor ("CGI:IRC") 19.13.39 Join mt [0] (n=MTee@41.233.136.213) 19.25.39 # I think firmware/drivers/i2c.c misses a mutex_init 19.26.21 # but this looks like very old code, so I'm surprised nobody ran into problems with it yet 19.26.41 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 19.30.32 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-2076cf0324777e70) 19.32.15 # i purchased a 80gb 1 platter 5mm harddrive for the iriver h120 today :D 19.32.38 # only 1 person has said he has done it correctly, isanggon on rockbox forums 19.32.53 # re the duplicate client problem... what would happen if when that happens, the server pings the client it thinks is connected? as long as the clients dont respond to pings unless it is connected then the server would know the connection was dropped, kill that client and accept the new one... 19.33.27 # i have a rockbox question, what is the easiest way to shuffle through all the music on my mp3 player? 19.33.38 # Turn Shuffle on? 19.34.55 # what USB controller (compatible with what other target usb) was in the s5l8700 again? 19.35.18 # the tcc one 19.35.28 # see usb-tcc.c 19.35.42 # ah, maybe something to work on this weekend :P 19.35.48 # LambdaCalculus37: will that shuffle through multiple folders? 19.36.06 # the way i access music is to use folder directories, not the playlist thing 19.36.09 # * gevaerts points GreatBeaver to our fine manual 19.36.11 # will i have to use playlist? 19.36.19 # you *always* use a playlist 19.36.24 # * LambdaCalculus37 also points GreatBeaver to the manual... the Manual Knows All 19.36.56 # gevaerts, we'll have to drive both the "usb function" part and the "usb phy control" part, right? 19.37.28 Quit r0b- (Read error: 110 (Connection timed out)) 19.37.48 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 19.38.04 # possibly. I'm not entirely sure. From what I understand some controllers handle the phy bit for you 19.39.49 # my mp3 player takes a few seconds to enter folder directories, is there a way to prevent it from doing that until i click an album for it to play? 19.39.50 # * bertrik spots rockbox code indented with 3 tabs 19.39.54 # *3 spaces 19.40.11 # GreatBeaver: Turn dircache on 19.40.20 # ok 19.40.40 # GreatBeaver: And for shuffling all the music, create a playlist of all the music, then turn shuffle on (or shuffle the music) 19.40.47 # ok 19.41.14 # i keep changing music on my mp3 player so i dont like having to create playlists so much 19.41.43 # Turn on recursivly insert directories, then if all your music is in a folder (e.g. Music) then open the context menu on it, then select add to playlist (or add shuffled) 19.42.16 # ok 19.42.35 # Whenever you play anything in Rockbox you are using a playlist - select a file in a directory and it creates a playlist of that directory for you 19.42.39 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 19.43.10 Quit linuxstb ("Leaving") 19.43.19 Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 19.43.59 # The "erase dynamic playlist?" message always scares me for a second 19.45.46 # Bagder: is rbclient.pl expected to do basically nothing after getting a build on arm? 19.46.06 # I added the cpu model to the list of 32 bit cpus 19.46.35 # the server won't care 19.46.38 # New commit by 03bertrik (r21749): Add missing mutex_init to i2c driver 19.47.08 # no, but all I get from it is a list of "Got " lines, and nothing happens 19.47.24 # weird 19.47.39 # Every now and then it gets another build, but that's it 19.48.18 # Bagder: Maybe some experimentation should be done with the build order - with the current "easiest to slowest clients" order, my laptop builds for about 200 seconds, with the other order, it managed a single build of.. 350 seconds I think? 19.48.32 # That is, when counting builds that actually succeed 19.48.42 Join _zic [0] (n=user@91-165-236-113.rev.libertysurf.net) 19.49.17 # yes, the order is indeed subject for further tweaking and testing 19.49.57 # * gevaerts spots something 19.49.59 # "and 0 cores" 19.50.22 # that's probably why then 19.50.53 # /proc/cpuinfo is a bit different 19.51.38 # Server connection stalled. Exiting! 19.52.18 # Hm, the cpuinfo on my nslu2 has processor with a capital p 19.52.40 # yes, same here. Also BogoMIPS 19.53.13 # * rasher gives gevaerts two is 19.54.37 # It could try to read /sys/system/cpu first, to get a more reliable number of cores 19.54.47 Join barrywardell [0] (n=barrywar@86-45-11-60-dynamic.b-ras2.prp.dublin.eircom.net) 19.54.50 Quit barrywardell (Remote closed the connection) 19.55.24 # * pixelma wonders if the "sansavista" theme on the c200 themes.rockbox.org is violating any copyrights 19.55.36 Quit linuxstb ("Leaving") 19.55.55 Join webguest91 [0] (n=1824bd5b@gateway/web/cgi-irc/labb.contactor.se/x-e7054cbf0518b93d) 19.57.08 # I have a Sansa e280v2 and I was wondering if I install the bootloader (and rockbox itself) will all of the patches (for disk corruption etc.) be included in the installation or will I have to put them in myself? 19.57.29 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 20.00.40 # I have a Sansa e280v2 and I was wondering if I install the bootloader (and rockbox itself) will all of the patches (for disk corruption etc.) be included in the installation or will I have to put them in myself? 20.04.12 # webguest91, what patches do you mean exactly? 20.04.19 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-c16ad4487b4d809e) 20.04.31 # Will the patches be included in a new installation of rockbox for the ams models? 20.04.50 # the rockbox zip that you download from the rockbox page is up-to-date with the latest version in svn 20.05.33 # Again, what patches? 20.05.41 # JdGordon: the server already pings clients very frequently 20.05.53 # I don't think doing yet another ping to fix dupe clients is going to help much 20.05.53 # webguest91: If you mean patches on open flyspray tasks, then no. 20.06.24 # I do believe there's a bug in the server that causes the dupe error a bit too often 20.06.45 # Oh, we don't have zips for download of ams sansas I think 20.07.24 # well doing an extra ping when a dupe tries to connect hopefully would fix the issue when it cant connect stratight after being disconnected/falling off 20.07.50 # JdGordon: yes, but it'd add a lot of weird extra code for a case that will be sorted out anyway within ~15 secs 20.08.27 # the client needs to keep trying then, which it looks like it doesnt do? 20.08.47 Join funman [0] (n=fun@rockbox/developer/funman) 20.08.48 # yes, but then again I believe this is a server bug 20.09.31 # New commit by 03Ubuntuxer (r21750): FS#10418: Change menu button in Sudoku on Fuze, by Nick Tryon 20.09.56 Quit webguest91 ("CGI:IRC (Ping timeout)") 20.10.14 Join webguest01 [0] (n=1824bd5b@gateway/web/cgi-irc/labb.contactor.se/x-401e080b6cd1df21) 20.10.48 Quit BryanJacobs ("Java user signed off") 20.11.31 # Sorry, I was disconnected, I was refering to the patches under the section "Requirements for release" 20.12.52 # link? 20.13.01 # Sorry, I was disconnected, I was reffering to the patches under "requirements for release" in the ams main page. 20.13.10 # kugel: i don't know in which conditions disk_mount can fail and how SYS_FS_CHANGED event will harm if it failed (in ata-sd-pp.c) 20.13.36 # I was just saying, I haven't looked at it 20.13.50 # my error source was that file :) 20.14.21 # the card initialization is a bit different from code in AMS driver 20.14.39 # Oh sorry 20.14.46 # http://www.rockbox.org/twiki/bin/view/Main/SansaAMS 20.14.46 # it is? 20.14.48 # perhaps with a bit of work the sd_thread() could be moved in the common driver 20.14.51 # Bagder: in some cases $lastcomm stays 0 on my arm client so it gets kicked off. I've now initialised it to time(), which seems to fix things 20.15.07 # I mean, without looking *into* the functions, the general init is mostly the same 20.15.33 # they are not called from the same places, the init is not done in sd_thread for PP 20.15.43 # webguest01: I don't see any patches linked there 20.15.44 # gevaerts: ah, then commit the fix! 20.15.55 # webguest01: I see old ones that have since been committed 20.16.21 # Bagder: I would, but I'm not sure if it's really correct 20.17.05 Quit webguest01 ("CGI:IRC") 20.18.20 # funman: there's no additional init, that's why 20.18.56 # the isr posts to the queue, which does disk_mount (retval not checked for pp) 20.19.54 # New commit by 03gevaerts (r21751): Fixes to make the client work on sheevaplug 20.20.34 # New commit by 03gevaerts (r21752): more fixes to make the client work on sheevaplug 20.20.54 # Bagder: I'm increasingly of the opinion that "hand out hard builds first" is in fact smarter 20.21.09 # check out jupiter-amiconn's performance in the last round for example 20.21.18 # or maybe the mid-range builds first 20.21.40 # rasher: jupiter has the problem that it's running new and old builds in parallel 20.22.11 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 20.22.39 Quit n1s (Read error: 110 (Connection timed out)) 20.22.50 # amiconn: that just means that it rates as slow client, it seems like it should've been able to complete at least one "proper" build 20.22.59 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 20.23.08 # 2 rounds without errors. Push to production! 20.23.21 # New commit by 03gevaerts (r21753): One more "bogomips" match made case insensitive for arm 20.24.28 # * gevaerts thinks that someone more fluent in perl should review these last few commits (that should actually have been a single commit...) 20.25.30 # gevaerts: done :) 20.27.36 # Is there a list of remaining blocker issues somewhere? 20.28.39 # kugel: see sd_init_device() , it still exists (the initialization needs to be made for every card) 20.29.25 # it will be triggered by the call to disk_mount which will make the first I/O operations on the inserted card 20.30.38 # funman: that's in the sd thread then 20.31.51 # yeah, i think moving sd_thread() out of target drivers should be easy 20.32.16 # * ej0rge wonders if what that guy was trying to ask was how up to date the official test build for c200v2 is 20.42.07 # has anyone replaced the battery in the h120? 20.42.14 # i am looking at a guide right now and kind confused 20.42.46 # * rasher has, but it was years ago 20.42.49 # I think I did the wakup_wait/signal wrong for the s5l8700, yet it seems to work ... 20.43.12 # bertrik: how wrong ? 20.43.20 # GreatBeaver: I've done a few, but lets move this to #rockbox-community 20.44.18 # funman, I start a ADC conversion, then do wakeup_wait to wait for the interrupt. The interrupt routine does not clear the interrupt, so I'm surprised to not end up in an endless interrupt loop 20.44.56 # well, the interrupt does get cleared in the interrupt controller, but not in the ADC module 20.45.30 # perhaps there is some latency introducing a delay between 2 interrupts 20.47.39 # funman, the datasheet isn't exactly clear how the interrupts should work 20.47.58 Quit mcuelenaere () 20.48.16 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.49.09 # hm, the samsung s3c6400 datasheet mentions an extra interrupt clear register 20.49.17 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 20.50.33 Quit freqmod (Remote closed the connection) 20.50.39 Join freqmod [0] (i=quasselg@dhcp208-240.ed.ntnu.no) 20.51.00 # Bagder: The duplicate client error doesn't sort itself out - it causes runclient.sh to exit 20.53.15 # * amiconn wonders about obo's driver code mix 20.54.50 # amiconn: that error is fixed in the new (uncommitted) server 20.55.18 # amiconn: code mix? 20.55.39 *** Saving seen data "./dancer.seen" 20.56.08 # amiconn: is your runclient.sh up to date? 20.56.31 # lcd_write_cmd and lcd_write_data look like the equivalents in the mini g2 driver (using the pp mono lcd bridge in serial mode) 20.56.52 # But you're doing bit-banged serial transfers 20.57.09 # Btw, what lcd controller is this? Is there a public datasheet? 20.58.48 # amiconn: AFAIK it's a ILI9320 - the datasheet is on my GSoC wikipage 20.59.04 Join tessarakt [0] (n=jens@e180072202.adsl.alicedsl.de) 21.00.39 # kugel was correct when he said that the GRAM address normally auto-increments - it does on this controller (so that part of lcd_update isn't needed) 21.04.09 # Hmm, a 320x240 colour lcd connected via SPI? Somehow I don't believe this... 21.04.55 Join MrDuck [0] (n=kachna@r4ax178.net.upc.cz) 21.06.23 # amiconn: well there is code in there for talking to it via SPI, which the lcd init routine (at least) uses... 21.06.42 # rasher: shouldn't runclient.sh update "itself"? 21.07.04 # pixelma: it doesn't, I'm not convinced it needs to 21.07.08 # it has barely changed at all 21.07.16 # the perl file is updated, not the .sh file 21.07.26 # when did it change last time? 21.07.40 # I think I haven't changed it since devcon 21.08.32 # You probably should. Probably 21.08.57 # The "exit on fatal errors" was added on june 23rd 21.09.35 # Maximum SPI clock is 10MHz. That means transferring a full 320x240x16 takes 122ms, i.e. a maximum full-screen update frequency of ~8fps 21.09.41 # New commit by 03rob (r21754): D2: Update the battery discharge curve to observed values, and add a crude runtime estimation (this is based on playback from SD card, other usage ... 21.09.50 # The View does video, so there must be an alternative transfer method 21.10.53 # hm 21.10.57 # no build round? 21.11.06 # amiconn: okay, makes sense. Urgh, back to the disassembly then 21.11.07 # Perhaps there is some gpio to select transfer method 21.11.27 # then mine should even be newer, I remember updating both when one of the both caused troubles when adding sdl to the archlist 21.11.35 # SPI would be a good start, because it's simple, and you could work from there 21.12.31 # pixelma, rasher: runclient.sh can't auto-update because it contains those client specific adjustments 21.13.06 # amiconn: it could refer to a standard configfile (in theory) 21.13.41 # (with rbclient -config=client.cfg or such) 21.13.50 Quit evilnick ("Page closed") 21.14.14 # obo: do you have a way to run modified OF code ? if the lcd_init function has no effect (put a return instruction at the start) and LCD still works this is the wrong function 21.14.54 # My copies of runclient.sh are from 25 June, and they do contain exit-on-fatal-error 21.15.06 # funman: it could be initialised again in the firmware 21.15.07 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-fb52fd1466f2a915) 21.15.20 # * JdGordon| probalby also needs the newest runclient.sh 21.15.44 # funman: I could build & sign a modified OF bootloader I guess? 21.15.47 # amiconn: which would make sense, since it was added on the 23rd 21.16.19 # obo: only if you can recover from a bad bootloader ? 21.16.35 Join n1s [0] (n=n1s@rockbox/developer/n1s) 21.16.37 # obo: have you tried to find the lcd_update function? 21.16.37 # I'd only replace the main firmware, not the bootloader 21.16.53 # kugel: tried? yes, but not actually found 21.17.01 # how did you search for it? 21.17.19 # on the samsas you could find it rather easily by searching LCD_WIDTH-1 or LCD_HEIGHT-1 21.17.49 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 21.18.08 # so far all the LCD functions have been grouped together - also grouped together as a collection of offsets near the end of the file 21.19.42 # I've found a single occurance (so far) of LCD_WIDTH next to LCD_HEIGHT 21.20.10 # have you tried searching for 239 and 319? 21.22.34 # they appear in the lcd_init code - but it does nice things like r3=0xFF, add r3 0x40 to create them 21.23.41 # their compiler seems to suck :p 21.24.10 # kugel: it is a limitation of arm instruction set 21.24.23 # what? 21.24.37 # immediate values are 8 bits with a shift 21.25.04 # 0x13F is not representable this way 21.25.22 # I thought they were 12 bits (i.e. 4096) 21.25.31 # 0x140 == 0x14 << 4 can be 21.25.45 # 4095* 21.27.04 # funman: http://www.peter-cockerell.net/aalp/html/frames.html 21.28.24 # i don't know which instructions use the 12 bits for immediate values 21.28.50 # mov use 8 bits + 4 bits for shifting (rotating right by an even amount) 21.29.11 Quit LambdaCalculus37 () 21.29.20 # look for the "ARM Architecture Reference Manual" it has detailed instructions encoding 21.30.20 # kugel: the immediate values encoding is detailed in chapter 3.2 of your link (Immediate operands) 21.30.28 # oh, I see. I read that wrong 21.30.52 # I apparantly stopped after the first paragraph 21.31.13 Quit stoffel (Remote closed the connection) 21.32.48 # obo: alright, that explains this doing then. But you can search for that too, and still for 239 21.34.31 # if the update functions check boundaries before feeding the gram, they probably check for 319 and 239 instead (from becase the hw updates row0 upto row319, etc) 21.34.59 Join matsl [0] (n=matsl@host-90-233-242-98.mobileonline.telia.com) 21.35.49 # kugel: I only see one instance where that value is assigned (rather than a add or sub) 21.39.59 Quit funman ("free(random());") 21.40.20 Quit JdGordon (Read error: 60 (Operation timed out)) 21.41.06 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 21.42.50 # Hmm, the LCD connector to the board has 40 lines - enough for a 16/18 bit interface as well as SPI (plus power/backlight)? 21.43.24 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 21.58.16 # amiconn: ping 21.58.35 # or, anyone 21.59.56 # I've been trying to make the SCALE(x) macro in chopper.c a inline function (because it a) expands its argument 4 times and b) it is often used with expressions instead of plain vars). It gave a nice binsize boost, and likely also some speed bonus but I noticed something werid 22.00.59 # New commit by 03zagor (r21755): Implemeted GIMMEMORE command instead of next-to-build queue. 22.01.27 # Death to unneeded kills! :) 22.01.33 # Zagor: does it just respond and then hand out a build to that command? 22.01.41 # yes 22.01.46 # when I had it as normal inline (non-static) it was *less* binsize than making it a static inline. 22.01.47 # nice 22.02.25 # New commit by 03zagor (r21756): New build distribution concept: Clients get one build at start, and then request more with GIMMEMORE command. 22.02.28 # The disassembly looked weird. In one case, all 6 arguments of a function are used with SCALE(x). Without the static I saw only 5 instances of this inline function + a stack operation, and with the latter I saw 6 instances (1 for each argument) 22.02.36 # umm, I just noticed that running battery bench for checking runtime in FM mode is probably useless since there won't be any disk spinups... or am I wrong? 22.02.39 # New commit by 03rob (r21757): D2: Remove unnecessary ide_power functions. 22.02.41 # that was all over the place, and I can't explain that :( 22.02.48 # Zagor: so when do they stop asking for more? 22.03.02 # ah they only ask once? 22.03.10 # for each completed I mean 22.03.19 # Bagder: yes, they ask for more when they have available resources 22.03.21 # pixelma, it _should_ flush its buffer on power-down on when the buffer gets full 22.03.23 # kugel: is this macro used for the half width/height version? 22.03.29 # yes 22.03.31 # I've added a little provision for single-core builds too 22.03.50 # bertrik: how long can it take entries (how many and what is this in hours)? 22.04.01 # pixelma: doesn't it spin up eventually to log results? 22.04.06 # time for a live test... 22.04.12 # the macro version is doubtlessly the worst version, but I can't figure out what it does with static vs non-static 22.04.47 # kugel: amiconn had the idea of making it use bitmaps anyways and then you can adapt it better to different screen sizes and it will look better. I even drew images... 22.05.21 # chopper really doesn't need bitmaps imo 22.05.22 # * amiconn hrmphs 22.05.51 # pixelma, about 16 hours 22.06.11 # kugel: I think it will look a lot better - and as I said will be easier to adapt to different screen sizes. 22.06.34 # bertrik: what happens on overflow? 22.06.36 # how are bitmaps easier to adapt? It means manually converting every bitmap 22.07.05 # pixelma, it tries to flush the buffer anyway, if it can't it ignores new values 22.07.16 # chopper just uses plain foreground color, without any fancy color shades or something. 22.07.39 # well, can you scale to arbitrary sizes? Like 1.23425 times? 22.09.23 # that would be like using using bitmaps for the line selectors to make be better adapted to different font sizes 22.09.47 # I don't understand what colour shades have to do with that. The images I drew are 2 chopper "states" each (just the rotor a bit differently) 22.10.24 # what? 22.10.35 # anyway, I don't care 22.10.46 # I'm after the SCALE(x) thing, that makes me curious 22.10.53 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 22.11.34 # bertrik: damn... how do I find the FM runtime on my M5L out, in case it can't write the log away... 22.13.57 # gevaerts: yea, I think I made about all bootloader 22.14.09 # Zagor: Btw, I think that adding timestamps to the log output would be a good idea 22.14.21 # * Bagder agrees with amiconn 22.14.27 # sure 22.15.06 # Zagor: I don't seem to get a new build after getting one killed 22.15.25 # ah, that's a client bug 22.15.26 # I see the same here 22.15.43 # it doesn't ask for a new when it gets killed. fixing. 22.16.02 # I'd also find it nice if the commands would be printed more verbosely, is there an option for that? 22.16.05 # svn: Syntax error in revision argument 'mt' 22.16.09 # I don't understand why the bootloaders come on the middle of the round. they should be after sims. 22.16.28 # JdGordon|: that doesn't sound right 22.16.33 # thats my output 22.16.39 # something is FUBAR 22.16.40 # Same error here 22.16.56 # yep, something is wrong. exiting server. 22.17.58 # I'm probably being punished for removing the @buildids array... 22.18.17 # probably 22.18.39 # * amiconn got the same svn error in one client, but a different svn error in the other client 22.18.47 # s/in/on/g 22.18.52 # * rasher saw no svn errors 22.18.54 # But that could be luck 22.19.49 # I was getting those too 22.20.08 # I also got an svn error and a "Server socket disconnected" after removal of builds 22.20.26 # perl is a bit nasty here. if you check for the presence of $hash{key}{value}, suddenly $hash{key} is created... 22.20.46 # unless you use "defined" 22.21.02 # "a bit"? "here"? 22.21.25 # those who don't know perl are doomed to reinvent it :) 22.22.22 Quit amiconn (Remote closed the connection) 22.22.23 Quit pixelma (Remote closed the connection) 22.24.19 # have we got any logging mechanism for the ipod accessories so users can try debbuging ? 22.24.50 # logf... 22.25.07 # i.e. no 22.26.26 # theres a patcht hat logs communications over the port on teh tracker I believe 22.26.34 Join guest001 [0] (n=someone@151-99.106-92.cust.bluewin.ch) 22.27.45 Quit guest001 (Client Quit) 22.28.36 Join pixelma [50] (n=pixelma@rockbox/staff/pixelma) 22.28.38 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 22.30.18 # New commit by 03zagor (r21758): Ask for more after CANCEL. 22.36.44 Join soycamo [0] (n=camo@c-76-115-2-113.hsd1.or.comcast.net) 22.37.54 # New commit by 03bagder (r21759): Add 'Onda VX777' to the mix 22.37.57 # Hi. How do I edit or create fonts for Rockbox? 22.39.23 # Are they just flat bitmap files? 22.40.26 # they are .bdf 22.41.03 Quit n00b81 ("Leaving") 22.41.53 # JdGordon: fnt is bitmap, isn't it? 22.42.41 # jdgordon| all I see are fnt files which I'm not sure what to open with. 22.44.33 # soycamo: they're converted to fnt from bdf 22.44.42 # and bdf is more genericly used for fonts 22.44.48 Quit matsl (Read error: 110 (Connection timed out)) 22.45.08 # bdf is bitmap as well 22.46.29 # badger I can't open it w/ photoshop and Gimp is hella slow on osx 22.46.51 # it's a font format 22.46.56 # why would those tools work with it? 22.47.03 # kugel: what is your build server that has 6x the bogomips of my quad opteron? 22.47.17 # New commit by 03zagor (r21760): Reverted to use of @buildids array. 22.47.34 # badger good point... though uh... tool suggestion? guide? 22.47.34 # saratoga: a octa xeon (>3GHz) 22.47.47 # wow 22.48.10 # saratoga: it's wasted on bootloaders of all things... 22.48.32 # soycamo: I have no idea. A font editor that can read bdf files? 22.48.44 Join funman [0] (n=fun@rockbox/developer/funman) 22.48.45 # Bagder: I found the ping bug in the server btw. it detected it fine, it just didn't do anything about it. :) 22.48.54 # ah, hehe 22.48.58 # nice find 22.49.06 # i saw someone tested the new bootloaders on the H10 finally 22.49.08 # badger: found stuff, n/m 22.49.10 # are we ready to release them then? 22.49.11 # soycamo: I believe people have used fontforge 22.49.20 # and my nick isn't spelled like that 22.49.36 # * kugel hands saratoga a TAB key 22.49.46 # uh 22.49.48 # haha 22.49.49 # hahaha 22.49.51 # haha 22.49.54 # my TAB hangs too 22.50.06 # fontforge is rather crappy imo. I'd suggest gbdfed 22.50.20 # saratoga: everything is tested except H10 20GB. 22.50.39 # ej0rge: RockboxTesting says you have a 20GB H10 :) 22.50.55 # finally this page is useful :) 22.51.12 # The UI is a little kludgy. Who can I report that to? 22.51.16 # kugel: I've used it before. I just don't always say :) 22.51.26 # soycamo: the ui? 22.51.45 # badger: yeah. it's not very intuitive imo 22.52.11 # saratoga: I always wonder why you sound so assured in the forums when giving advice. E.g. do you know for sure that the timestretch mode is really accessible (UI wise) on the c200? I have a c200 and would have to try... although the guy didn't sound like he tried very hard to find out how to use it 22.52.19 # soycamo: UI for what? 22.52.22 # you in vague terms speak 22.52.29 # * Bagder does a yoda impression 22.52.45 # badger: the ui for rockbox, ie when I turn on my c250, it is not obvious what I should do 22.53.07 # "Who do I report it to" haha 22.53.21 # * gevaerts looks around for this badger person 22.53.21 # AlexP: I thought there might be an Awesome UI Super Team 22.53.22 # Feel free to suggest specific improvements 22.53.58 # AlexP: okay. Well, there should be a very easy "Music" menu at the top, because that's most important. 22.53.59 # gevaerts: he might look for someone to badger! 22.54.10 # soycamo: That goes where? 22.54.14 # pixelma: if its on the e200 how would it not be on the c200? 22.54.17 # soycamo: File tree or database? 22.54.28 # soycamo: is it? For everyone? 22.54.28 # soycamo: And if filetree, then which directory? 22.54.30 # gevaerts: Hush, that's our line! 22.54.39 # alexp: A link I guess? It's hard to explain this in text. 22.54.43 # saratoga: because the c200 has a different keymap? 22.54.45 # kugel: (about SCALE(x) in chopper) perhaps one call was optimized? 22.54.51 # there might be problems? 22.54.52 # soycamo: A link where? 22.55.02 # alexp: at the root of Rockbox menu. 22.55.06 # soycamo: Customisable menus are not very highly thought of 22.55.11 # soycamo: To where? 22.55.12 # gevaerts: I do have a 20gb H10 22.55.17 # funman: it didn't look like 22.55.19 # alexp: this is hard to describe in words, I'm sitting here with my c250 22.55.19 # gevaerts: I plan to test the new bootloader on it tonight 22.55.25 # ej0rge: thanks! 22.55.28 # soycamo: i.e. you click on music, what does it show you? 22.55.33 # soycamo: The database? 22.55.35 Join matsl [0] (n=matsl@host-90-233-177-32.mobileonline.telia.com) 22.55.37 # soycamo: The filetree? 22.55.40 *** Saving seen data "./dancer.seen" 22.55.46 # gevaerts: No problem - I've been leeching off this project for years, so I'm happy to help :) 22.56.04 # alexp: the database. 22.56.11 # I don't use the database 22.56.17 # That isn't how I get to music 22.56.29 # Virtually all the devs don't use the database in fact 22.56.36 # alexp: Don't think like a dev 22.56.44 # except Slasheri maybe 22.56.51 # alexp: think like an idiot user. end user just wants music. 22.56.56 # So for all those users that don't use the database, your music label would be wrong 22.57.07 # soycamo: why shpuld we make the life harder for us? 22.57.08 # We don't force people to use a database 22.57.09 # alexp: that could be fixed in settings 22.57.17 # soycamo: also, lots of people use it for non-music audio... 22.57.28 # pixelma: do you ever have that moment when you want it to *work* without thinking? 22.57.33 # It does 22.57.41 # soycamo: what's so hard about choosing "Database"? 22.57.42 # pixelma: yes, and I use it for both 22.57.55 # soycamo: you could also read the manual and maybe find the start screen options... 22.57.55 # gevaerts: how could we optimize what the server is giving a client upin GIMMEMORE? 22.57.58 # I think - I want to use the database, or I want to browse files, so I choose "Database" or "Filetree" 22.58.05 # gevaerts: it is non-obvious. I am approaching this from a user perspective 22.58.12 # or is that a plain linear list now? 22.58.44 # * soycamo feels like she is talking to a wall 22.58.49 # soycamo: And making things either wrong or more complicated 22.59.04 # alexp: okay, sorry, never mind. 22.59.16 # Don't get me wrong, improvements are welcome 22.59.35 # But a big factor of Rockbox is to allow access how people want to what they want 22.59.45 # alexp: and I want it to be stupidly simple 22.59.53 # Rockbox isn't for you then 23.00.00 # alexp: why not? 23.00.08 # It has too many options and possibilities to be stupidly simple 23.00.16 # it won't be stupidly simple if it goes to the database automatically and you don't even use it 23.00.17 # That is why we have a rather fine manual 23.00.35 # it = database here 23.00.40 # alexp: but what if I want to have "zomg easy button" for when I'm on my bicycle, and then use the menus for "srs business" mode 23.00.42 # soycamo: i find a database to be extra complication, i know where my files are on the drive i just want to get to them 23.00.57 # soycamo: That just makes it even worse 23.01.04 # alexp: why? 23.01.16 # soycamo: Why can't I find this setting? Oh, maybe I'm in the wrong mode 23.01.19 # n1s: then why have the database then? 23.01.29 # Do I have to switch modes to be able to do x? 23.01.39 # alexp: I'm just asking for a shortcut to a shuffle mode for when I'm on my bicycle 23.01.40 # soycamo: As some people do use it 23.01.48 # soycamo: Quick screen 23.01.55 # soycamo: i think a few people would whine if i removed it :) 23.02.00 # jesus christ if you all aren't interested in my suggestions fine 23.02.12 # resume button 23.02.27 Part soycamo 23.02.29 # soycamo: your suggestion is "make the ui fit my usage pattern"... 23.02.54 # while the policy is "make the ui fit the developers' usage pattern" 23.03.34 # AlexP: the quickscreen is only easily available from the WPS on the c200 unfortunately 23.03.43 # or at least try to compromise to make if as good asm possible 23.03.56 # for as many people as we can 23.04.02 # pixelma: Ah, I misread e not c 23.04.20 # pixelma: its a standard menu option, why would it need a different keymap? 23.05.11 # saratoga: doesn't it need switching the mode in the pitch screen, I don't know whether that works correctly 23.05.43 # Who can build osx binaries for sansapatcher and e200rpatcher? 23.05.59 # saratoga: Where can you set the timestretch rate in the menus? 23.06.13 # gevaerts: domonoky1 can on my osx box 23.06.17 # rather than just on and off 23.06.31 # I can give you access if you want 23.06.57 # AlexP: well he said it was unimplemented so presumably that refers to the menus . . . 23.07.20 # saratoga: I can imagine it does, since pondlife has a c200 too, if I remember correctly. That was just an example though, but maybe it just bothers me a bit since I'm usually very careful when giving advice 23.07.39 # but what I meant was that its added to the existing screen so its hard to imagine we wouldn't have had a keymap for it 23.07.45 Quit brndyhite (Remote closed the connection) 23.07.45 Quit archstech (Remote closed the connection) 23.07.45 Quit tucsbgns (Read error: 54 (Connection reset by peer)) 23.07.55 # pixelma: is there some specific complaint you have? 23.09.10 # saratoga: There is a difference in having a keymap and having a keymap where all actions are accessible 23.09.19 # sometimes it just sounds too quick too sure to me (but as I said, maybe it's because I'm not) 23.09.19 Quit _zic (Read error: 54 (Connection reset by peer)) 23.09.25 # last chance for people to comment on my clip keymap changes... or ill commit when I get home (3 hours or so) 23.09.53 # I admit I do not have a c200 to test on but I am certain we have implemented time stretching on the c200 23.10.11 Join archstech [0] (n=archstec@206.251.250.215) 23.10.31 # We do. The uncertainty lies in whether it is accessible 23.10.36 # that yes, but is it really "usable"? E.g. there is metronome on the c200 too but you can't really use it 23.12.21 # argh, stupid MacOS 23.12.25 # well i don't mean to imply that we have no playback bugs, so if hes certainly welcome to report one 23.12.40 # "so hes certainly welcome to report one" 23.14.39 # There can be issues with keymaps. Even if an action is mapped that doesn't mean it actually works. It can e.g. be covered by another action in the context - context chaining can hide this pretty well 23.14.51 # New commit by 03bagder (r21761): mktitlepics.pl is a tool for generating a full set of title bitmaps for the ... 23.15.05 # Or there is an electrical or mechanical constraint that causes a combo to be impossible 23.15.22 # Bagder: excellent! 23.15.25 # pixelma: in this case I don't think it changed any keymaps, so if the pitchscreen used to work, the new stretch feature will as well 23.15.39 # Zagor: it'll make them in the same dir right now 23.15.50 Join soycamo [0] (n=camo@c-76-115-2-113.hsd1.or.comcast.net) 23.15.56 # gevaerts: yes, but I don't know if the pitchscreen works 23.15.56 # and I think that the pitchscreen is old enough for us to know if it would be broken 23.16.18 # Bagder: Couldn't we use css for rotating text? 23.16.23 # no 23.16.28 # * amiconn has no real idea whether css allows that 23.16.30 # there's no such thing in css 23.16.44 # only in some very recent version that no browser supports 23.16.53 # haven't seen something like that either 23.17.24 # and this is pretty easy anyway so... 23.17.54 # is ondavx777 harder or easier or the same as ondavx767? 23.18.01 # virtually the same 23.18.05 # afaiu 23.18.10 # I'll give it the same score then 23.18.23 # right, forgot about that 23.19.02 # does 747 have plugins while 767 doesn't? 23.19.12 # 747 is listed as our second heaviest build 23.19.22 # New commit by 03zagor (r21762): Added ondavx777. 23.19.50 # oh 23.19.55 # I don't know the details 23.20.03 # maurus is the man 23.20.18 # (too hard to spell nick for me to try without tab completion) 23.20.23 # gevaerts: and there was a change in WPS keymaps recently (don't remember testing accessibility of the pitchscreen) 23.20.54 # hm, true 23.21.32 Quit DarkDefender ("Leaving") 23.24.03 Quit jgarvey ("Leaving") 23.26.35 # Bagder: I guess we should merge build and buildmaster. the division is a bit messy now. 23.26.57 # right 23.29.51 Quit Thundercloud (Remote closed the connection) 23.32.12 # pixelma: metronome is the reason I'm asking you to test my PLA rework 23.33.04 Nick soycamo is now known as soycamo|duchando (n=camo@c-76-115-2-113.hsd1.or.comcast.net) 23.36.27 # New commit by 03zagor (r21763): Added total build round time. 23.37.43 Quit n1s ("Lämnar") 23.38.13 # what is wrong with metronome on c200 ? 23.38.40 # funman: nearly everything works. Only the button to actually make it make noises doesn't 23.40.04 # ah it's a keymap problem, i thought it was a PCM or DMA hardware problem 23.41.29 # Same problem also exists on the Player 23.41.40 # and Ondio 23.41.57 # Oh? 23.42.01 # * amiconn didn't know 23.44.28 # Zagor: did your commit trigger a build round? 23.44.38 # no 23.45.24 # ok, already thought something was wrong here (also got a few "Server connection stalled" in the backlog 23.45.56 # pixelma: you won't get those anymore. the server disconnects faster than the client now. 23.46.16 # well, they can still happen if the client has lost touch with the server 23.46.37 # in a silent manner I mean 23.46.43 # yes but the server will disconnect first, which the client will react to with a "cleanup + restart" 23.47.04 # ah right, if the net is really borked 23.47.05 # not if someone pulled the cable in a router in between, then the client won't notice the disconnect 23.47.20 # right 23.48.19 # will the new build system handle standby/hibernation mode? 23.49.07 # obo: yes, it handles clients coming and going as they wish 23.50.06 # but when the client powers back up, I'm not sure it reconnects? 23.50.18 # it will 23.50.37 # if it continues, it'll detect the idle connection, disconnect and reconnect again 23.54.15 # saratoga, gevaerts: timestretch is also accessible on the c200, I really had to look up how to enter the pitchscreen in the manual though (or the code) 23.54.51 # New commit by 03zagor (r21764): Added timestamp to printouts. 23.56.46 Quit soycamo|duchando (Read error: 110 (Connection timed out)) 23.57.23 Quit CaptainKwel ("Page closed")