--- Log for 01.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 28 days and 7 hours ago 00.03.04 # kugel: did you commit it yet? My RFA work (as soon as it actually works) could use this 00.03.05 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 00.03.07 Quit ender` (" I bought a supposedly-wireless phone once. I opened it up and it was full of wires.") 00.03.35 # * gevaerts stops coding for the day and leaves FS#10403 as an exercise to interested readers 00.04.14 # no I didnt 00.04.37 Part domonoky 00.04.47 # ok. I won't integrate it yet in my patch then :) 00.06.28 # has anyone made any clip themes? 00.12.00 # Hillshum: There's cabbiev2 00.12.10 Part Ubuntuxer 00.12.16 # rasher: any others? 00.12.28 # No idea 00.13.22 Join User2991 [0] (n=user2991@95.223.157.35) 00.14.10 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.14.52 Quit Xqtftqx (Read error: 60 (Operation timed out)) 00.16.51 Part User2991 00.16.57 Quit stripwax (Read error: 104 (Connection reset by peer)) 00.24.17 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.25.27 # i think vorbis automatically skips to the next packet after parsing comments, so i'm just going to commit my comment patch 00.25.38 # it seems to work fine and i think its ok to do from skimming the code and spec 00.27.50 Quit stripwax (Read error: 104 (Connection reset by peer)) 00.29.18 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.33.35 Join stripwax5443 [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.36.57 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 00.37.14 # New commit by 03saratoga (r21581): Commit rest of fix in FS#9866. Don't parse Vorbis comments again in libtremor. It wastes memory and we already have the comments in memory. Looking ... 00.43.05 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.46.29 Quit flydutch ("/* empty */") 00.48.11 Quit bmbl ("Bye!") 00.48.50 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 00.48.57 Join Strath [0] (n=Strath__@173-23-45-236.client.mchsi.com) 00.50.14 *** Saving seen data "./dancer.seen" 00.51.03 Quit stripwax5443 ("http://miranda-im.org") 00.51.34 Quit stripwax (Read error: 110 (Connection timed out)) 00.52.31 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 00.52.58 Quit Hillshum_ (Read error: 60 (Operation timed out)) 00.54.19 # Hillshum, I haven't seen a hang on my clip since reverting 21577 (although not very thoroughly tested yet) 00.54.42 # bertrik: It won't boot at all 00.55.50 # you can unpatch the changes from a specific revision by doing 'svn diff -c >revision.patch', then doing 'patch -p0 -R Hmm, no Lear around# 01.00.01 # * amiconn wonders how un-inlining functions would significantly change stack usage 01.00.16 # amiconn: the function is recursive 01.00.25 # and? 01.00.46 # Inlined or not - each call will allocate a stack segment 01.00.51 # it allocated 512 bytes on the stack every recursion befoer 01.00.57 # now it does that in a separate function 01.01.12 Join toffe82 [0] (n=chatzill@adsl-75-3-221-137.dsl.frs2ca.sbcglobal.net) 01.01.14 # that memory was only used before the recursive call anyway 01.01.22 # That's still the same stack 01.01.51 # no, the 512 bytes are popped when the (new) separate function returns 01.01.54 Quit cg_ (Read error: 60 (Operation timed out)) 01.02.04 # it used to be push 512 bytes -> call self -> push 512 bytes -> etc 01.02.20 # Yes, and I would expect gcc to free this space as well if the function is inlined 01.02.23 # now it is call new -> push and pop 512 bytes -> call self -> etc 01.02.23 # I can imagine saving memory by reusing the same path buffer (appending and truncating it as you go deeper or shallower) 01.02.48 # amiconn: the recursing function isn't inlined, the one that pushes 512 bytes to the stack is 01.02.56 Join KittenKat [0] (n=mitten@c-76-107-167-95.hsd1.tn.comcast.net) 01.02.58 # I know 01.03.05 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 01.03.25 Quit tessarakt ("Client exiting") 01.03.58 # so i was wondering, has anyone had any luck getting the C200 usb to actually mount under linux? 01.04.25 # If a function gets inlined, its contents basically become a block (at least that's how I understand it). And since the inlined function's variables are declared in that block, the space should be freed again when the function (i.e. the inlined block) ends 01.04.38 # amiconn: it didn't end before it calls itself though 01.04.59 # The *inlined* function does end before the containing function calls itself 01.05.21 # shows up as [265556.612314] generic-usb 0003:0781:7450.0006: input,hidraw0: USB HID v1.10 Device [Rockbox.org Rockbox media player] on usb-0000:00:1d.7-1/input1 in dmesg but wont mount. does charge thou 01.05.31 # right, okay 01.05.46 # i agree it is pretty silly of gcc if it helps to uninline it now that i think about it :) 01.05.58 # KittenKat: ubuntu 9.04? 01.06.00 # i was caught up on the fact that the same commit split out the allocation to a new function 01.06.01 # KittenKat: Ubuntu or an ubuntu derived distro? 01.06.19 # Inlining shouldn't change stack usage (apart from the return address on targets which have no link register, and stack args) 01.06.22 # ubuntu derived distro 01.06.22 # also fails under debian 01.06.22 # and slackware 01.06.34 # If it does, I'd consider that a major gcc bug 01.06.39 # no windows boxes to try it on 01.06.54 # KittenKat: are you running hal? 01.07.16 # yup 01.07.32 # ok. Most probably this gphoto2 bug then... 01.07.33 # The new function makes sense, the explicit __attribute__ ((noinline)) doesn't, afaiu 01.07.49 # didnt auto or manual mount, i tried every variation of the mountpoint 01.09.01 # KittenKat: have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/355998 01.10.20 # gevaerts original firmware works just fine, only the new version 3.3 rockbox fails 01.10.32 Join barrywardell [0] (n=barrywar@79.97.85.223) 01.11.37 # KittenKat: can you pastebin the lsusb -v output for the c200? 01.12.12 # give me like 30 mins, kinda making dinner and chatting here :) 01.12.58 Quit bertrik (Read error: 60 (Operation timed out)) 01.13.21 # I'll probably be asleep by then. Just link to it here though, and I'll have a look tomorrow 01.14.44 # thanks, i just need to eat... been coding all damn day. but i'm sure you know how that is 01.14.51 # yay for stirfry in a bag 01.17.48 # amiconn: the buttonbar... am I going to get strife if it gets removed? 01.18.02 Quit notlistening ("Leaving") 01.18.11 # yes 01.19.08 # arg... why? 01.19.42 # Ahem, it is an established and helpful feature of rockbox? 01.20.01 # Imo viewports should make it significantly easier to implement the button bar, even using the user font (i.e. variable height) 01.20.35 # We don't exactly go out of our way to display what any other button does from screen to screen. Why do those buttons need a special case? In most screens the button use doesn't correspond directly with the label anyway, except WPS. 01.21.20 # Those buttons have *no* labels, and are meant to change meaning. Other buttons are usually close in function to their labels 01.22.12 # amiconn: if they were *always* disaplayed then that would make things much easier 01.22.16 # but they arnt... 01.22.52 # Why would that make things easier? 01.22.55 # amiconn: "A-B", the Windows button on Beasts, the "lines and stuff" submenu button on e200, etc, all have more or less functions we've just decided on. 01.23.27 Quit linuxstb_ (Read error: 110 (Connection timed out)) 01.23.54 # amiconn: have you seen my viewport dev-ml email? 01.24.12 Quit linuxstb (Read error: 110 (Connection timed out)) 01.24.41 # There are other potential targets with soft buttons. It's also a common feature of many mobile devices 01.24.58 # Does anybody know how to convert a float to it's string representation? 01.25.09 # can you give that email a quick read? I'll reconnect in about 10min... heading home 01.25.25 # I would be very happy to force them always on the screen if they are enabled 01.25.34 # ? 01.25.38 # but toherwise i'm going to push for them to be totally removed 01.25.45 # back in 10 01.25.55 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.26.12 # Wouldn't this solve the support issue with configurable buttons? 01.26.28 # Hillshum: What? 01.26.34 # This has nothing to do with configurable buttons. 01.26.49 # The choice is there so people who know the functions (or are willing to do some guessing) and want the extra space can disable them. The display on those targets isn't exactly large 01.27.04 # also - no, thinking about blind users etc. 01.27.09 # amiconn: So why not just expect people to learn what they do like any other buttons? 01.27.25 # We have plenty of buttons with ambiguous uses on many screens. 01.27.30 # Why give up a feature that is already there, and can be kept easily? 01.27.51 # pixelma: surely whether or not the button bar is there is completely irrelevant to blind users? 01.27.52 # ...and which makes sense? 01.28.02 # amiconn: Are you doing the work to keep it around after the rework? 01.28.10 Quit dmb (Read error: 113 (No route to host)) 01.28.16 # Why rework things which work? 01.28.20 # But if a way was there to show whatever each button does, then could we allow users to configure the buttons because they would be able to figure them out easy? 01.28.27 # amiconn: Did you read JdGordon's email? 01.28.50 # Hillshum: It doesn't show what every button does. It's a specific feature for three buttons on a specific target. 01.28.59 # Llorean: Other buttons aren't aligned in a way that allows easy display of their function. 01.29.23 # rasher: that was in response to Hillshum's "idea". Besides the fact that you can't display the button mapping of other targets where the buttons are physically layed ouit differently 01.29.31 # amiconn: My point is more "people have shown a marked ability to actually learn how to control their devices, three more buttons isn't going to break them" 01.29.32 Quit gevaerts (Nick collision from services.) 01.29.44 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 01.30.13 Join courtc_ [0] (n=court@unaffiliated/courtc) 01.30.34 Quit Thundercloud (Remote closed the connection) 01.31.39 Quit courtc (Read error: 113 (No route to host)) 01.31.44 Nick courtc_ is now known as courtc (n=court@unaffiliated/courtc) 01.32.51 # Llorean: So we shouldn't do something we can (and did for several years, and the OF also does, and is like these buttons were *designed*) just because it's a little extra work to keep it? 01.33.02 # Imo that deserves a clear *no*. 01.33.36 # So in this case we do want to mimick the OF? 01.33.39 # * rasher is confused 01.33.39 # Btw, I did read that mail earlier today, but didn't understand all of it. I've checked it again now, and still don't understand... 01.34.02 Quit mcuelenaere () 01.34.02 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 01.34.02 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 01.34.29 # rasher: No, we do want to use the hardware like it's designed (the cases where we can do that are rare enough...) 01.35.00 # Why would the button bar be not part of the ui? It clearly is a logical part of the ui... 01.35.22 # The graphical button bar and the physical buttons are two different things 01.35.28 # The physical buttons are still a part of the UI either way. 01.35.46 # You yourself even mentioned the button bar is expected to be turned off once the user learns the functions, to reclaim the limited screen space 01.35.55 # The button bar shows what functions the softkeys has *in this screen*, so it's clearly related 01.36.10 # s/has/have/ 01.36.32 # Llorean: It's not *expected*, it's a choice 01.36.48 # So why doesn't he get list viewports working, and then if the button bar is important enough, you can reimplement it within the new code? 01.37.11 # This is one of those situations where we're holding everyone back for a *visual effect* that's only useful on, basically, one target. 01.37.34 # It's not one target, it's three. And there are more potential targets 01.37.39 # visual effect plus ease-of-use 01.37.49 # It's a limited amount of users. 01.37.52 Join JdGordon| [0] (i=4600bada@rockbox/developer/JdGordon) 01.37.52 # amiconn: How many of these targets have the buttons positioned properly, as you mentioned? 01.38.23 # And if you're talking about visual effects - viewported lists are much more *only* visual effect than the button bar is 01.38.29 # And what are these three targets? I thought it was just the Recorder line? 01.38.40 # Yes, and there are three recorders 01.38.55 # * Hillshum isn't sure if that counts as three targets 01.39.04 # the BB could be usable on a few more targets, but not perfect like on the recs 01.39.06 # E.g. the AV3xx also has buttons like this (although to the right instead at the bottom) 01.39.10 # We still consider the iPod 5G "one target" when it needs two different builds. 01.39.18 # And the AV3xxx is not a realistic future target at this point, is it? 01.39.47 # As I see it, the button bar and a touchscreen ui are somewhat similar 01.39.49 # And having it to the right just means it's not really going to be the same thing at all 01.40.23 # amiconn: So reimplement the button bar using the touchscreen stuff after the change then? 01.40.25 # so, there is a build for the 5g at somepoint in the distant future? 01.40.33 # KittenKat: 5G what? 01.40.40 # With viewports it shouldn't matter. Left, right, top, bottm - just a matter of viewport allocation. Same for the number of softkeys 01.41.32 # Llorean: Huh? I'm not saying that our current touchscreen stuff works like this, but I can imagine a button bar with touchable buttons for some screens. Vkeyboard would be one example 01.41.35 # someone mentioned those new Samsung port devices have two buttons below the screen - also the H10 and the Beast though. And it was an idea to make the button bar useful on touchscreen targets 01.42.08 # ipod 01.42.26 # amiconn: That doesn't mean it's the same case as the button bar, then, though. The vkeyboard isn't going to be displaying alongside the list. 01.42.34 # KittenKat: The iPod Video has been supported for ages. 01.42.36 # And? 01.43.00 # amiconn: So their "similarity" is what, exactly, other than possibly looking similar? 01.43.01 # That was just one example - of course a touchable button bar could work in other screens too 01.43.32 # Why would the button bar be not part of the ui? It clearly is a logical part of the ui...<- because the ui area might not be exactly at the bottom of the display 01.43.48 # Uh, why that? 01.43.56 # There's not a touchable button bar for touchscreen targets, and having used one, I don't find a particular need. Touchable buttons within the WPS (and, if the WPS can be showed alongside the list, the ability to continue using them) would cover it just fine. 01.44.00 # because it will be up to the user 01.44.06 # Llorean i thought the ipod video is 4g 01.44.17 # the new 120gb ipods are 5g no? 01.44.24 # KittenKat: No, the 4G is the iPod 4G. Then there's the iPod Color/Photo which is a variant of the 4G with color screen. 01.44.30 # The new 120GB iPods are the sixth generation. 01.44.34 Join Hillshum_ [0] (n=chatzill@unaffiliated/hillshum) 01.44.38 # damn my bad 01.44.48 # so is a ipod 6g build in the works? 01.44.51 # No. 01.44.58 # why not? 01.45.12 # Because the people who have them aren't doing the work. 01.45.16 # * amiconn is definitely against giving up functionality for cosmetics 01.45.16 # Llorean: 120gb is actually 7th gen 01.45.27 # KittenKat: Or haven't been able to solve the problems. 01.45.31 # *nods* 01.45.40 # Hillshum: Oh really? They use different firmware and have different hardware beyond the HD? 01.46.13 # Llorean: Sorry, I was just assuming 01.46.13 # amiconn: its really unfair to bassically kill a nice feature for the other 25 targets for a single target which has a userbase of 6 01.46.14 # amiconn: But we're not giving up functionality for cosmetics. We're giving up cosmetics for other cosmetics. 01.46.31 # Hillshum: Please, PLEASE don't make random assumptions like that in here. People read these logs and repeat them elsewhere. 01.46.34 # amiconn: which is why im happy to force the bar always on or always off instead 01.46.38 # The button bar is not just cosmetics 01.47.25 # amiconn: As much as what list viewports can become will be. 01.47.26 # It's an aid for beginners, and for those who easily forget things. But for others it's taking up precious screen space, hence the option 01.47.44 # And I still don't know what's problematic about that 01.47.52 # * JdGordon| questions if htere is such a thing as begginiers to the ajbr's anymore 01.47.56 # god non standard connectors piss me off *looks for the ipod and c200 cable* 01.48.01 # amiconn: If you don't see it as problematic, why not be the one to re-implement it after the change? 01.48.37 Quit faemir (Remote closed the connection) 01.49.02 # amiconn: you said you dont understand bits of the email... respond then please... or we are going to have a situation where the bar *will* be broken and noone will have the energy to fix them 01.49.31 # Because (1) I'm not good at implementing gui stuff, (2) it currently works and hence I would expect it to be kept working in a rework 01.49.48 # And I don't understand why the option is problematic 01.50.05 # amiconn: So basically your argument is "it's too important to get rid of, *I* think it's easy so I'm unwilling to believe it will cause problems or difficulties, but even though I think it's easy I freely admit I don't have the knowledge to do it myself"? 01.50.19 # What's the difference between handling different button bar height, and a disableable bar? The latter just means button_bar_height == 0 ... 01.51.16 # amiconn: ok, the issue is that we cant have the bar at the bottom (outside the ui area) with it being allowed to show up whenever it wants, and we cant really use it in the ui area because the user could size and position that anywhere in the display 01.51.29 # Llorean: No, one of my arguments is that whoever breaks something is responsible for fixing it, unless there was an agreement of giving it up. 01.51.29 # so either its= needs to be static, or removed 01.51.32 # or stay broken 01.52.16 # It doesn't show up whenever it wants. It shows up in all screens it is attached to, if enabled 01.52.41 # right... it needs to be *all*( screens, or none 01.52.53 # That doesn't make sense 01.53.20 # And if your design is not flexible enough, something is wrong with that design 01.53.31 # Sorry to say that 01.53.38 # no, the feature is broken 01.53.45 # the new design is fine 01.53.56 # It's not broken atm, at least not that I know of 01.54.00 # and really... if its broekn then please help to fix it 01.54.37 # * amiconn already postponed several other things which need to be done.... 01.54.45 # * JdGordon| suspects that he can probably just leave it as is, even though it will be technically broken, but nooen will notice 01.55.21 # where? 01.55.52 # where what? 01.56.08 Quit zitune[afk] ("Coyote finally caught me") 01.57.41 # * JdGordon| admits that the buttonbar would be bloody useful on the touchscreen so thinks he will end up forcing it on the screen at all times 01.58.17 # which shold simplify things a bit 01.58.59 # I guess then you'll notice 01.59.22 # notice what? 01.59.39 # umm... add a "if enabled" somewhere 02.01.14 # that makes a difference 02.03.31 # Forcing it always is a big no-no either 02.03.37 # * JdGordon| back in 10 02.04.04 # Besides, if your ui area doesn't go to the bottom (minus button bar), what would be around it? 02.05.06 # Nothing, I assume? 02.05.06 # if I understabd the description correctly, either nothing or parts of the WPS 02.05.10 # The backdrop.. 02.05.24 # understand too 02.06.00 # I think it's part of the WPS. 02.06.38 Quit JdGordon| (Ping timeout: 180 seconds) 02.07.20 Quit at0m (Read error: 110 (Connection timed out)) 02.08.27 # Wasting precious screen space? That may be acceptable on large colour screens (I'd say 220x176 and larger), but on small screens it's just plain nonsense 02.13.54 # which is why I'm going to be happy leaving it in a tehcnially broken state 02.14.14 # ? 02.14.34 # I mean the area around your 'ui' area, not the button bar 02.14.49 # it will be up to the user (or themer) to make sure the buttonbar will be where it needs to be 02.15.11 # * amiconn would expect several different things from viewportification 02.16.18 # you know what the answer there is going to be... 02.17.01 # Flexible statusbar (user font, maybe themable icons), flexible list that adapts to rtl languages (scrollbar, icons and text switching horizontal position), flexible button bar (user font, maybe scrolling labels if they're too long) 02.17.35 # so is gevaerts a coder for the project? 02.17.38 Part robin0800 ("Leaving") 02.19.58 # KittenKat: yes 02.21.15 # *nods* 02.21.25 # think i figured out the c200 problem i'm having 02.21.37 # rockbox reports a different product id vs the standard firmware 02.21.39 # http://pastebin.com/m19e4bdae 02.22.28 # now to find the source download ^.^ 02.22.29 # KittenKat: hm, that's the pid of a c200 in MTP mode.. 02.23.06 # it's set to MSC in the factory firmware 02.23.11 # amiconn: yes and all that is coming.... right now we are discussin the buttonbar which is very legacy and causes issues in the new fun stuff 02.24.33 # rasher: which one the working or non working pid? 02.25.14 # KittenKat: the non-working one 02.25.34 # rasher i thought that rockbox is alawys in MSC mode 02.25.35 # 0781:7450 = C200 in MTP mode 02.25.55 # KittenKat: Yeah, I mean in the OF, it reports a different pid depending on whether it's in MSC or MTP mode 02.26.00 # the question is why the pid would matter when it's a standard ums device? 02.26.05 # and 7450 is what the OF reports when in MTP mode 02.26.19 # Mikachu: well it shouldn't 02.26.51 # Looks like it was misreported in the DeviceDetection wiki page 02.27.04 # under every distro of linux i have installed around the house it just sits there when connecting via rockbox firmware and does nothing. not allowing me to mount it in any way 02.27.29 # it does 02.28.02 # Which could mean Rockbox is using the "wrong" value, which means some software thinks it's an mtp device, based on the pid, and doesn't even see that it is in fact MSC 02.28.07 # in the oe firmware it works good 02.28.08 # at least OF in MSC gets a differnt PID than OF in MTP mode 02.28.23 # works well* 02.28.25 # pixelma: and Rockbox appears to be using the MTP one 02.28.31 # damn i'm sleepy again 02.28.33 # i doubt linux would care about this though 02.28.48 # Which *shouldn't* matter, but hal could be basing its decision on the pid 02.28.51 # Technically it's still the fault of the host software, since PID isn't supposed to be a valid way to decide what to use. 02.29.01 # unless it's the Ubuntu bug 02.29.08 # Llorean: Certainly. 02.29.09 # It sounds like it's just a variant of the ubuntu bug 02.29.11 # or hal 02.29.15 # technically there could be both an ums endpoint and an mtp endpoint on it, right? 02.29.21 # Same faulty design idea, but used somewhere else. 02.29.29 Join AlexP_ [0] (n=alex@rockbox/staff/AlexP) 02.29.44 Quit AlexP (Read error: 104 (Connection reset by peer)) 02.29.59 # There's no reason to open us up for more software bugs by using the pid that is known to mean "MTP device" 02.30.04 Join dmb [0] (n=dmb@unaffiliated/dmb) 02.30.17 # dosent matter who droped the ball, shouldent the rockbox firmware report the proper pid since it's known that some software uses pid to determine mtp/msc? 02.30.52 # should be a simple single line of code change on the rockbox end 02.30.56 # rasher: the reported PIDs had been wrong on the DeviceDetection page for the c200 until recently. I slightly doubt that's the reason Rockbox uses the "wrong" one though 02.31.17 # pixelma: If I were to find a pid for the c200, I'd look there.. 02.32.03 # well, just thought gevaerts had an c200 himself and would have checked but yeah, there's a chance it explains it 02.32.22 # KittenKat: Well, it does matter who dropped the ball if someone, like you, still needs to report the bug to the people who are *actually* doing it wrong. 02.32.43 # pixelma: It was added by zagor it seems 02.32.53 # pixelma: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=15758 02.32.55 # In many cases we're going to have to use PIDs that are normally used for MTP devices as UMS devices 02.33.00 # For example, the Gigabeat S 02.33.08 # We can't solve the problem there, and we're doing nothing wrong n the first place. 02.33.19 # rasher: ah, and Zagor also put the wrong ones on the wiki page 02.33.37 # So, yeah, who dropped the ball kinda does matter in the longer term 02.33.49 # Should I commit this change? There's no harm in it, and if it turns out it fixes it, that's even more to point the finger at in a bugreport 02.34.00 # rasher: Yeah, it should be fixed. 02.34.08 # Llorean i've been coding for a long time... two wrongs dont make a right. if your firmware reports incorrectly and the software uses an unreliable detection method both parties should fix their problems 02.34.10 # But whatever's doing the detection based on PID really needs to be identified. 02.34.17 # was the problem only reported for c200s or also e200s? 02.34.19 # KittenKat: Our firmware doesn't report incorrectly 02.34.28 # KittenKat: PIDs identify hardware, not capabilities. So, the PID is 100% correct. 02.34.29 # New commit by 03rasher (r21582): Use the USB pid normally used by the OF when in UMS mode. This might make misbehaving pc software play nice. 02.34.50 # pixelma: also e200s I believe 02.34.59 # *shrugs* 02.35.09 # KittenKat: You complaining to the other people as well, or just us? 02.35.22 # i'm complaining to the hal ppl also 02.35.56 # KittenKat: See if the next round of builds "fix" it and use that to point more of a finger at the hal dudes 02.36.10 # i think it's a hal problem 02.36.19 # it's kinda a 2 part problem 02.36.34 # The USB-IF gave us no uncertain terms that it's allowable to use the same PIDs even if we switch a device that was previously MTP to UMS. 02.36.59 # It's not a 2 part problem at all. 02.37.21 # HAL is not using the proper mechanisms to check the capabilities of the device. That's all there is to it. 02.37.49 # rasher OE firmware works fine 02.37.53 Join dmb_ [0] (n=dmb@ool-4573a3fb.dyn.optonline.net) 02.37.53 # rasher Rockbox firmware dosent 02.38.00 # That doesn't mean it's our problem. 02.38.02 Quit dmb (Client Quit) 02.38.22 # KittenKat: Because HAL is tweaked to expect what the OF does based on *the wrong metrics* 02.38.37 # HAL doesn't use USB properly, and the fact that we do happens to expose that. 02.38.38 Quit efyx (Remote closed the connection) 02.38.44 # aka 2 part problem. factory device works fine, your firmware dosent since it gives the mtp pid when it's using ums 02.39.00 # KittenKat: it's not an "mtp pid". It's a pid belonging to that device 02.39.02 # your firmware should follow the OE pid shit 02.39.12 # KittenKat: There's no rule at all saying we should 02.39.17 # so non patched computers work fine, hal should fix their shit 02.39.20 # The bug is in HAL. Squarely. 02.39.32 # it doesn't anymore - and it would be even allowed to use the same 02.39.53 # KittenKat: There are cases where the OF doesn't even support UMS where we do. In those cases the problem still exists, because HAL is broken 02.40.16 # i've been coding a long time you cant alawys get the true cause of the problem fixed and therefor you need to patch yours to work around the bug you cant fix 02.40.44 # * rasher facedesks 02.40.48 # i expect hal to be broken for a while 02.40.50 # That doesn't mean there is *any sort of problem* 02.41.00 # KittenKat: We shouldn't introduce a bug to fix someone else's bug. 02.41.12 # *shrugs* 02.41.26 # you guys should be doctors lol 02.41.39 # Llorean: Why is it a bug for us to use the same PID as the OF in UMS mode? 02.42.02 # linuxstb: No, it's a bug for us to code around this behaviour in other cases though. 02.42.15 # linuxstb because it's not their "problem" 02.42.34 # linuxstb: " [...] There are cases where the OF doesn't even support UMS where we do.", so then we have to use the mtp pid i suppose 02.42.35 # Llorean: Are we talking about other cases? 02.42.42 # Mikachu: Yes, I know that. 02.42.52 # linuxstb: KittenKat seems to suggest the goal should be "make it work no matter what" 02.42.55 # Mikachu: Please see if http://build.rockbox.org/dist/build-sansac200/rockbox.zip "fixes" your issue 02.43.01 # rasher: wrong nick :) 02.43.05 # er 02.43.12 # KittenKat: Please see if http://build.rockbox.org/dist/build-sansac200/rockbox.zip "fixes" your issue 02.43.18 # On all other devices where there are two different IDs for MTP/USB, Rockbox uses the USB one. It doesn't seem the intention that we don't on the C200. 02.43.19 # If it does, rain hellfire on the HAL people 02.43.27 # s/USB/UMS/ 02.44.13 # * linuxstb sees rasher's commit, so doesn't know what we're all arguing about... 02.46.23 # if the reports are for e200 too and Rockbox uses the correct MSC PID there though then there must be another reason for HAL to fail 02.46.47 # pixelma: I think hal expects mtp for the e200 because of the magic mode 02.46.52 Join at0m [0] (n=at0m@94-225-90-23.access.telenet.be) 02.47.03 # Not sure if that's speculation though 02.47.17 # magic mode? 02.47.19 # hal or not, can't you always just mount the device in /dev manually? 02.47.40 # pixelma: mtp/msc autodetect shenanigans 02.47.56 # Mikachu: Isn't the point that you only get a disk device in /dev if it's been detected as UMS? 02.48.12 # linux should do that at the kernel level 02.48.49 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/freenode/x-25f494ed50507ef9) 02.48.53 # if linux tells hal "here's a scsi disc device at /dev/sda1" and hal ignores it because the pid is wrong, i don't even know where to start :) 02.49.06 # rasher: the MTP mode in the c200 OF is called "autodetect" as well... 02.49.25 # pixelma: maybe the e200 autodetect mode uses the msc pid. I've no idea 02.50.15 *** Saving seen data "./dancer.seen" 02.50.24 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 02.50.28 # btw i'm chewing out hal now 02.51.06 # if you're mentioning rockbox in the report, try to keep it civil :) 02.51.13 # Mikachu every attempt to mount it manually failed 02.51.30 # KittenKat: did it work with the new build that has the other pid? 02.51.34 # yup 02.51.37 # like a charm 02.51.37 # pixelma: It's Autodetect vs MSC on my c250 02.51.50 # auto mounts, manually mounts, etc 02.52.20 # pixelma: oops, misread you, sorry 02.52.31 # that's what I meant 02.53.49 # thanks rasher :) 02.57.10 # now i just need to make a headphone amplifier because it sounds great on my cheap headphones and like shit on my aux input in my friends car... 02.57.26 # * KittenKat slinks off to etch some boards 02.57.47 # KittenKat: is there a bugreport we can follow? 03.00.01 # i'm tryin to find a non distro specific but report page for HAL 03.01.53 # KittenKat: https://bugs.freedesktop.org/ 03.02.02 # https://bugs.freedesktop.org/enter_bug.cgi?product=hal 03.02.04 # oops 03.02.13 # Yours was better 03.02.22 # does mtp have assigned protocol numbers? 03.02.51 # good god what is it with invalid security certs 03.02.56 # * KittenKat adds an exception 03.03.06 # if the hal xml files could be cleaned up to detect if rockbox was running somehow it could expose the device differently 03.03.22 # KittenKat: my guess is that you can just better judge the real "quality" of the c200's sound output through aux in the car 03.03.26 # since we are stuck with native vid/pid 03.03.55 Quit barrywardell () 03.04.12 # rockbox does not currently use mtp at all right? (at least on sansas) 03.04.46 # pixelma the aux in on the car is a larger load then my shitty headphones which sound great but are a light load 03.05.33 # most portable devices choke under high loads eg very high quality studio monitors, some aux inputs, etc 03.05.46 Quit Plerg (Read error: 110 (Connection timed out)) 03.05.50 # KittenKat: also interesting is if you enabled things like EQ or adjusted bass or treble and whether you turn that off (or set to 0) when used in the car and let the car's stereo do the work 03.06.33 # pixelma it's not the only mp3 player i've had with poor output power 03.06.49 # that's why people sell headphone amps for quite a bit of money 03.07.09 # i happen to have a bunch of insturmentation amplifiers lying around so i'm just going to make a simple amp 03.08.57 Quit vedlith (Read error: 104 (Connection reset by peer)) 03.18.15 Quit shadearg (Read error: 60 (Operation timed out)) 03.18.53 Quit Hillshum_ (Read error: 110 (Connection timed out)) 03.21.37 Join shadearg [0] (i=arg@ipv4.panoptix.net) 03.22.28 # https://bugs.freedesktop.org/show_bug.cgi?id=20717 is not terribly promising of HAL's willingness to work with us 03.23.03 # so what's a good way to put that your team was kind enough to compile me a rockbox with the pid set to 751? 03.23.52 # KittenKat: it wasn't for you, it's changed in svn :) 03.24.10 # really? 03.24.19 # Just that. We changed the pid to 7541 since it wasn't supposed to be 7540, but that this still doesn't mean they aren't in the wrong from making assumptions based on the pid. 03.24.20 # not only for you, anyway 03.27.03 # Man, I've not missed wrasslin' with Bojira 03.27.07 # rasher: That seems to be about identifying actual capabilities. Wouldn't we more or less prefer the host *not* care about our capabilities and just accept the fact we're a UMS device? 03.27.35 # Llorean: Sure, but hal also puts hints like supported audio formats etc for programs 03.28.46 # Well, we can decline to provide that package but still at least expect it to honor UMS, right? 03.29.12 # It certainly should 03.29.15 # If their project wants to provide information, fine, whatever, but it shouldn't get in the way of standard USB stuff. 03.29.24 # https://bugs.freedesktop.org/show_bug.cgi?id=22569 < yay first official bug report 03.32.09 Join perrikwp [0] (n=Keith@rrcs-96-10-92-195.se.biz.rr.com) 03.45.04 # thanks a ton guys :) 03.45.27 Quit Riku (Read error: 54 (Connection reset by peer)) 03.47.34 Quit SUSaiyan (Read error: 110 (Connection timed out)) 03.52.08 Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) 03.52.28 Quit pixelma (Nick collision from services.) 03.52.30 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 03.52.47 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 03.53.28 Quit amiconn (Nick collision from services.) 03.53.33 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 03.53.41 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 04.18.53 # New commit by 03lowlight (r21583): Philips SA9200. Add LCD features: enable, sleep, flip, contrast, and invert. 04.50.19 *** Saving seen data "./dancer.seen" 04.59.57 Quit dmb_ (Read error: 113 (No route to host)) 05.02.06 Quit patmulchrone (Read error: 110 (Connection timed out)) 05.05.13 Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 05.08.53 Quit Cory` () 05.12.35 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 05.22.17 Quit HBK (Read error: 104 (Connection reset by peer)) 05.22.30 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 05.29.09 Quit Beta2K (Remote closed the connection) 05.30.36 Join pat_mulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 05.31.19 Quit patmulchrone (Read error: 104 (Connection reset by peer)) 05.34.24 Join dmb [0] (n=dmb@unaffiliated/dmb) 05.38.19 # * JdGordon loves the notes with FS#10403 05.38.33 Quit yosafbridge ("Coyote finally caught me") 05.38.45 Join yosafbridge [0] (n=yosafbri@ludios.net) 05.40.12 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 05.50.36 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 05.51.48 Quit Hillshum (Client Quit) 05.57.08 # from a quick glance playback.c looks like its interaction with playlist isnt *too* bad... 05.57.16 # well.. better than I thought I remembered 06.16.59 Quit JdGordon ("Leaving.") 06.22.00 Join JdGordon [0] (n=Miranda@c-67-160-44-90.hsd1.wa.comcast.net) 06.30.53 Quit toffe82 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 06.47.39 # New commit by 03FlynDice (r21584): AMSSansa: Corrects bug introduced with r21577 causing random lockups on AMSSansas. ... 06.47.42 Join dlenski [0] (n=dlenski@c-69-255-193-94.hsd1.md.comcast.net) 06.50.22 *** Saving seen data "./dancer.seen" 06.54.30 Join beta_ [0] (i=1000@d24-36-78-223.home1.cgocable.net) 06.56.15 Nick beta_ is now known as Beta2K (i=1000@d24-36-78-223.home1.cgocable.net) 07.02.27 Join cg_ [0] (n=cromos@cable-kmi-fe71de00-186.dhcp.inet.fi) 07.31.00 Quit cg_ (Read error: 110 (Connection timed out)) 07.41.20 Join ForumJunkie [0] (n=ilovefor@S0106001731ba3ab8.va.shawcable.net) 07.41.48 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.43.31 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.43.33 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.48.26 Quit kugel (Read error: 110 (Connection timed out)) 07.49.35 Quit dlenski (Read error: 110 (Connection timed out)) 07.52.44 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 08.03.40 Quit intrados () 08.03.55 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 08.05.35 Join Rob2222 [0] (n=Miranda@p4FDCCB64.dip.t-dialin.net) 08.09.02 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 08.15.27 Join padd1 [0] (n=patrick@58.167.91.66) 08.17.49 # hi guys 08.18.02 # Just thought I'd alert some of you to my project 08.18.09 # It's cracking the 6g 08.18.32 # the page for now can be found at http://www.ipodwizard.net/showthread.php?t=46206&page=8 08.18.43 # Any help would be appreciated 08.23.13 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.23.50 # padd1: what's the CPU? Is powered by the S5L8700 by any chance? 08.24.17 # hmm... let me check 08.26.33 Quit ForumJunkie () 08.29.20 # padd1: when I google I just see that it's ARM based and made by Samsung 08.29.34 # cool thanks 08.29.36 # yeah 08.29.52 # basically, the project doesn't need this though 08.29.58 # the idea is not to find holes 08.30.05 # we've searched hard for this 08.30.12 # and come up with nothing 08.30.13 # what are you trying to do then? 08.30.16 # due to lack of devs 08.30.23 # so, we are trying to brute force 08.30.32 # to guess the encryption key 08.30.51 # and, we link computers together to form a sort of supercomputer 08.30.54 # what is the goal of the project? 08.30.57 # like a web of computers 08.31.02 # spitting out tonnes 08.31.08 # then, we crack the 6g 08.31.15 # we have hold of the firmware 08.31.29 # we can do whatever eg rockbox 08.32.04 # well, if you want to port rockbox it's nice to at least know what CPU it is using. 08.32.29 # but I guess you don't have to worry about that for a while 08.34.05 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.34.28 Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) 08.36.52 Quit safetydan ("Leaving.") 08.36.52 # yeah, We're going to port rockbox once we've cracked it... we need to focus on cracking it now. Just thought, If anydevs could help, it would be really useful 08.45.50 Quit JdGordon (Read error: 104 (Connection reset by peer)) 08.48.06 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 08.49.07 Join petur [50] (n=petur@rockbox/developer/petur) 08.50.26 *** Saving seen data "./dancer.seen" 08.52.28 Quit BHSPitMonkey (Read error: 113 (No route to host)) 08.53.54 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 08.54.38 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.54.47 Join funman [0] (n=fun@rockbox/developer/funman) 08.55.13 # padd1: do you know which encryption algorithm is used on ipod classic? 08.55.20 # * GodEater was just going to ask that 08.55.30 # no 08.55.36 # we think either 128 08.55.42 # or 256 08.55.49 # 128/256 what ? 08.55.54 # we plan to get an old 6g and dump the ram and take it apart 08.55.56 # to find out 08.56.00 # oh bit 08.56.15 # AES / Blowfish / Twofish ? 08.56.29 # 08.56.53 # hmm 08.57.05 # that's what we are dumping the ram to find out 08.57.12 # that's the only way, right 08.57.20 # but, probs AES 08.57.34 # unfortunately, dumping Ram destroys the ipod 08.58.14 # do you want to dump RAM content while the iPod is running? I don't understand how that can help figuring out the algorithm used 08.58.35 # I don't understand how dumping the RAM helps *at all* 08.59.19 # at least giving some strings to be expected in the decrypted firmware, to help bruteforcing 09.00.36 # padd1: have you seen this ? http://home.gna.org/linux4nano/ongoing.html <-- these guys have been working on the Nano 2G for years, and STILL haven't figured out the algorithm used. 09.04.28 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 09.04.57 # FlynDice, how about we simply use adc_read (with has proper locking) to get the core voltage? 09.07.31 # if adc_read is used in a tick task i think locking just can not work 09.07.48 Quit padd1 (Read error: 60 (Operation timed out)) 09.08.32 # and r21584 is incorrect anyway 09.08.46 # since the adc input could be changed anytime 09.09.25 # instead the interrupts should be disabled to ensure only the adc reading code in set_cpu_frequency() is running 09.10.13 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 09.10.29 # welcome back Zagor. Nice holiday I hope ? 09.12.09 Join padd1 [0] (n=patrick@58.167.91.66) 09.12.09 # thanks. I got lots of sun, but had to endure the greece (lack of) infrastructure. pretty much every mode of transport I booked was cancelled at least once... :-/ --> #*community 09.12.21 # sorry guys 09.12.26 # had to reboot 09.12.36 # so, how do I determine the algorithm 09.13.08 # padd1: i think that's your job to find out how 09.13.22 # lol, do U guys know 09.13.40 # we'd tell you if we knew 09.14.02 # ask the zune linux mob :D 09.14.17 # i would suppose the decryption code is stored somewhere in a ROM 09.14.19 # lol 09.14.26 # theyve gone so far 09.14.31 # yeah 09.14.35 # JdGordon: the unencrypted-frimware-zune? 09.14.39 # the way it works 09.14.57 # (I know it's signed) 09.15.23 # is why is that the RAM, in update has the key 09.15.29 # that is taken from the rom 09.15.40 # the rom is too hard to take out 09.16.20 # if their software is well codec the key wouldn't be kept in RAM, and having the key still doesn't tell you which algorithm is used 09.16.27 # well coded* 09.16.33 # you can't take the ROM out if it's inside the CPU (as with the ipod nano 2g) 09.17.11 # markun: so what "ROM" did the linux4nano guys dump then ? :) 09.17.33 # GodEater: I thought it was the 1MB firmware flash 09.17.55 # markun: could be, I really didn't know :) 09.18.12 # "The SST39WF800A device is a 512K x16 CMOS Multi-Purpose Flash (MPF)" < it is what they dumped 09.18.25 Quit thegeek (Read error: 110 (Connection timed out)) 09.19.29 # GodEater: http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=212&partnum=S5L8700 09.19.40 # "50KB Embedded Boot ROM" 09.19.50 # I assume that's what they would have liked to have 09.20.27 # https://mail.gna.org/public/linux4nano-dev/2009-06/threads.html : they are now using a JTAG setup to dump RAM contents (in the aim of exploiting an identified buffer overflow) 09.21.00 Quit gevaerts (Nick collision from services.) 09.21.12 # still far away from something suitable for rockbox 09.21.12 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 09.22.26 # I suspect the 6g is using something very similar if not exactly the same as the 2G Nano 09.28.45 Quit bertrik (Read error: 60 (Operation timed out)) 09.38.29 # New commit by 03zagor (r21585): Devcon is over 09.38.43 # only slightly late ;) 09.39.49 Quit padd1 (Read error: 110 (Connection timed out)) 09.42.30 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 09.53.33 Quit GodEater ("Terminated with extreme prejudice - dircproxy 1.0.5") 09.53.47 # I found 2 headers which each include the other one. Looks quite ugly to me, is that a common practice? 09.54.41 # namely ata_mmc.h (which needs the definition of tCardInfo typedefed struct) and hotswap.h which needs specific functions definition (either sd or mmc) 09.57.53 Join GodEater [0] (n=bibble@rockbox/staff/GodEater) 10.08.48 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 10.10.58 # * GodEater hoses the mud off pondlife 10.12.05 # * pondlife hopes GodEater et al had a good drink 10.12.29 # * GodEater can't complain 10.12.48 # * pondlife has rather more sunburn than mud for a change 10.17.46 Join Guest [0] (n=chatzill@dslb-088-072-246-028.pools.arcor-ip.net) 10.19.09 Quit Guest (Client Quit) 10.38.47 Join PaulJam [0] (i=Paule@vpn-3127.gwdg.de) 10.42.04 # I don't understand how the speed is calculated in ata-sd-pp.c card_get_info_target() 10.42.30 # The bits used just do not have any meaning, wether taken out from the first 32 bits or the last 32 bits of CSD register 10.43.05 # 3 bits starting from bit 29 (or 125) and 4 bits starting from bit 25 (or 121) 10.46.01 # if someone with a c200v1 or e200v1 could give me a dump of her/his card_info[0].csd that would help 10.47.05 # funman: if you don't get one before, I'll try and get you one from my c200 this evening 10.47.38 # thanks, i suspect it's the same layout than on sansa ams but verifying wouldn't hurt ^^ 10.50.28 *** Saving seen data "./dancer.seen" 10.53.36 # does 12MBit/s sound like a reasonable transfer speed for SD cards ? 10.54.31 # reported by both my Sansa Fuze and my 2GB µSD card 10.56.28 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 10.59.01 Join TheSphinX^ [0] (n=cold@p54A5C57A.dip.t-dialin.net) 11.01.22 Quit ze (Remote closed the connection) 11.02.16 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 11.03.05 Quit cool_walking_ ("Page closed") 11.03.10 # amiconn: I see you committed a lot to ata_mmc.c , what is "TSAC" ? I find mentions of "TAAC" in the SD specification (asynchronous part of the data access time), and googling a bit makes me wonder if this timeout isn't named "TAAC" as well for MMC cards 11.07.54 Join ze [0] (n=ze@76.91.72.105) 11.10.41 # in fact I can find mention of TAAC in the MultiMediaCard Product Manual but not "TSAC" so I think it's just a typo 11.18.59 # drivers/ata_mmc.c:451 : conversion from clocks cycles to "bytes" ? 11.34.42 Join ForumJunkie [0] (n=ilovefor@S0106001731ba3ab8.va.shawcable.net) 11.35.05 # ata is because the driver was historically cf/ide? 11.35.14 # yes 11.35.21 # okay 11.35.46 # the files haven't been renamed but that's not a big deal I think 11.37.04 # funman: TSAC should be TAAC indeed. It's not a typo, it's a misread on my side it seems 11.37.13 # yeah, was just a little confused because mmc is not ata/scsi I think 11.37.34 # amiconn: thanks, I have put this change into my diff 11.37.40 # tmzt: SD neither ;) 11.37.44 # somebody from google reported 50mbps for sd card 11.37.56 # on msm7k hardware 11.38.13 # 12mbps makes sense then (same order) 11.38.13 # not sure how targets' dma compares to that 11.38.18 # Conversion from clocks to bytes is SPI specific. The timeout is given in clock cycles, but SPI *always* transfers bytes 11.38.29 # So dividing by 8 makes things easier 11.38.32 # the interface is 2bit? 11.38.34 # tmzt: 12mbps is what the card reports, not a measurement at all 11.38.47 # okay 11.39.11 # that was probably 4bit at 46mhz 11.39.40 # amiconn: i merged the tCardInfo (mmc) and tSDCardInfo structures, now i need to make read_timeout and write_timeout meaningful on both SD & MMC drivers. timeout is not used by SD drivers at the moment but I will change that soon for Sansa AMS 11.40.01 # though that doesn't seem to add up 11.40.46 # amiconn: well I would think timeout is expressed in time units (clock cycles or seconds) 11.42.31 # hmm 11.42.32 # is the timeout dependant on the size of data transferred ? 11.42.46 # in seconds per bits (or bytes) 11.43.18 Join mt [0] (n=mt@41.233.147.176) 11.44.14 # since it's only used internally in drivers the unit doesn't need to be precise (SD would use seconds) 11.47.59 # who is Wincent Balin on irc ? 11.48.17 # Me iz. 11.48.42 # What do you want to ask me? 11.48.46 # hi ;) could you add yourself to IrcNicks wiki page? 11.48.55 # Someone compile me RB with a patch =.= 11.48.59 # I wanted to know which problems you have with pdbox makefile 11.49.28 # The .c files seem not to depend on plugin.h while they should. 11.51.13 # did you look at make.dep ? 11.51.46 # Yes, and it confirmed my suspicions. 11.52.36 # But nevertheless, I could not find any error in pdbox.make. 11.52.51 # I modelled it after zxbox.make. 11.52.55 # is plugin.h inside an #ifdef block? perhaps gcc wouldn't include it when generating the dependencies 11.53.07 # and zxbox dependencies are rebuilt fine? 11.53.45 # Yes, I saw after some updates of plugin.h that zxbox was recompiled completely and pdbox was relinked only. 11.54.33 # And yes, #include "plugin.h" is everywhere in #ifdef ROCKBOX ... #endif . 11.55.29 # Zagor: mkdepfile should use gcc -DROCKBOX then ? 11.55.55 # PPCFLAGS should include -DROCKBOX rather 12.02.08 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 12.05.15 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.05.35 Quit KittenKat (Excess Flood) 12.05.59 Join KittenKat [0] (n=mitten@c-76-107-167-95.hsd1.tn.comcast.net) 12.07.25 # New commit by 03funman (r21586): Merge tCardInfo struct (MMC) and tSDCardInfo struct (SD) ... 12.18.42 # If I might ask a not very on-topic question, what would you think about the STM Primer2 (http://www.stm32circle.com/resources/stm32primer2.php) as a target for Rockbox? 12.19.07 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 12.19.12 # JdGordon (or anyone who understands the UI code): The parameter to quick_screen_quick() is sometimes a button, and sometimes an action - is this correct? 12.19.35 # I'd guess it should always be an action 12.19.48 Quit martian67_ (SendQ exceeded) 12.21.04 # New commit by 03mcuelenaere (r21587): Also cleanup Onda VX747 ata-sd-target.h file 12.24.55 # mcuelenaere: oops i missed that one 12.25.08 # funman: np :) 12.28.23 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 12.28.25 Quit martian67 (Success) 12.29.42 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 12.30.38 Quit martian67_ (SendQ exceeded) 12.31.15 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 12.34.08 # pretty big binsize increase on my last commit .. i'll check why 12.41.24 # when using objdiff.py I see: card_get_info_target 300bytes smaller, sd_select_bank 4 bytes bigger, sd_init_card 40 bytes bigger, sd_transfer_sectors 4 bytes bigger 12.41.37 # New commit by 03mcuelenaere (r21588): Add (better IMO) alternative for utils/analyis/objdiff.py (taken from Linux kernel, scripts/bloat-o-meter.py) 12.42.11 # mcuelenaere: wow you are fast to help me ;) 12.42.24 # heh, just timing coincidence :) 12.44.04 # sd_mantissa takes 800 bytes instead of the previous 16, and sd_exponent 320 bytes instead of 40 .. 12.45.02 # I was hoping gcc wouldn't embed it in each file using it 12.45.30 # looking at the elf file I only see 1 instance 12.46.23 # hum no, I see several instances 12.47.42 # we could create a firmware/drivers/sd.c which would contain common functions (such as csd bits extraction) and define sd_mantissa & sd_exponent here (and perhaps not even export them) 12.50.29 *** Saving seen data "./dancer.seen" 12.51.13 Quit pabs (Read error: 110 (Connection timed out)) 12.51.41 # funman: I've been thinking of doing that too (also creating and managing the SD thread there) 12.52.07 # and creating some kind of general SD interface to communicate with the target driver 13.11.18 Join barrywardell [0] (n=barrywar@79.97.85.223) 13.17.08 # I can't use card_extract_bits() .. 13.20.25 # yes it's definitely weird 13.21.04 # instead of (p, start_msb, n) I have to use (p, start_msb+1+n, n) 13.22.03 # New commit by 03alle (r21589): Provide a context sensitive default file name when saving settings (FS#10399) 13.26.54 # amiconn: what were you sinking about in r5193? the extracted bits do not match with the MMC spec 13.29.18 # example: r5192: speed = mantissa[csd[3] & 0x78 >> 3] * .. is correct, you extract bits 6:3 of csd[3], a.k.a bits 102(3*32+6):99(3*32+3) of CSD 13.29.46 # r5192: speed = mantissa[mmc_extract_bits(csd, 25, 4)] * .. 13.29.59 # I do not see a relation between starting bit 102 and starting bit 25 .. 13.34.34 # 25 = 127 - 102 though 13.36.41 # amiconn: ideally extract_bits would use the bits position printed in the specification. 13.37.25 # Even if that requires reversing the order in which csd 32-bits words are stored (they are stored ls-word first for PP SD and AMS SD at least) 13.42.00 # SH1 is big endian, and the function works properly on that 13.42.18 # Yes, it counts from the other end 13.42.26 # pretty disturbing 13.42.57 # There is no consistent documentation. Some datasheets list it this way, some the other way round 13.42.59 # works fine on little endian when the words are in the right order 13.43.24 # the MMC Product Manual from SanDisk says 127 is the msb which seems fine 13.44.35 # which datasheets counts from the other end (msb is 1st bit) ? 13.46.00 Quit parafin (Read error: 60 (Operation timed out)) 13.46.01 Quit markun (Read error: 60 (Operation timed out)) 13.46.05 Join markun [50] (n=markun@rockbox/developer/markun) 13.46.27 # can you tell before rewriting the code if counting from the other way would make the code more complex? If it doesn't then I will change the way for consistency with the SanDisk datasheets 13.47.11 # big endian/little endian doesn't change the way bits are stored. We'd have to reverse the csd register when reading it though 13.47.18 # reverse the words order 13.47.36 Join parafin [0] (i=parafin@paraf.in) 13.49.19 # or add a start = 127 - start in card_extract_bits which seems simpler .. :) 13.56.55 # Hmm, my H300 has needed 2 paperclip resets today... 13.57.34 # Both times after skipping a track, and apparently showing the "paused" icon. 13.59.24 # I think it's also buffering and updating the database. Will reinit the database and try again. 14.06.44 Quit funman (Remote closed the connection) 14.06.55 Join funman [0] (n=fun@rockbox/developer/funman) 14.17.12 Join kugel [0] (i=kugel@rockbox/developer/kugel) 14.25.26 # New commit by 03mcuelenaere (r21590): utils/analysis/find_addr.pl: also add support for plugins & codecs 14.33.34 Quit robin0800 (Remote closed the connection) 14.37.51 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-8f05add532f7ef84) 14.45.59 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 14.50.32 *** Saving seen data "./dancer.seen" 15.12.14 Quit DarkDefender (Read error: 110 (Connection timed out)) 15.14.29 # amiconn: any argument against changing the starting bit of card_extract_bits() to 127 - start_bit? 15.15.20 Join faemir [0] (n=faemir@78.33.109.163) 15.23.17 # pulling the microsd out while buffering is not a good idea :) 15.31.35 Quit barrywardell () 15.37.16 Quit mcuelenaere (Read error: 110 (Connection timed out)) 15.44.47 Quit linuxstb (Read error: 113 (No route to host)) 15.44.47 Quit linuxstb_ (Read error: 113 (No route to host)) 15.45.24 Quit bmbl (Read error: 60 (Operation timed out)) 15.53.22 # New commit by 03mcuelenaere (r21591): Onda VX747 bootloader: don't init storage twice 15.56.46 Join funman_ [0] (n=fun@rockbox/developer/funman) 15.56.58 # New commit by 03mcuelenaere (r21592): Ingenic Jz4740 SD driver: fix SD clock init (fixes problems with SDHC cards) 15.57.18 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 15.58.36 Quit funman ("Reconnecting") 15.58.41 Nick funman_ is now known as funman (n=fun@rockbox/developer/funman) 15.59.56 Quit PaulJam (Nick collision from services.) 16.00.00 Join PaulJam_ [0] (n=Paule@vpn-3127.gwdg.de) 16.03.13 Join evert_ [0] (n=evert@static.133.75.46.78.clients.your-server.de) 16.03.33 # I'm having a strange problem, in 'database' all my music numbers are double in the artist/album/* list :/ 16.03.42 # is there any possible fix for this? :) 16.04.09 # yhou mean all the tracks are appearing in the db twice? 16.04.18 # yeah 16.04.20 # or more ;) 16.04.46 # when did you last initialise/update the db? 16.04.59 # very recent, but it didn't solve the problem 16.05.07 # even reinitialising it from scratch? 16.05.53 # database -> initiliaze: now updating in background 16.05.59 # how can i do it from scratch? :) 16.06.01 Quit PaulJam_ (Nick collision from services.) 16.06.04 Join PaulJam [0] (n=Paule@vpn-3127.gwdg.de) 16.06.20 # mount it over usb and delete database*.* from .rockbox :) 16.06.30 # then shut down and restart, the db will be blank 16.06.36 # ok 16.06.48 # if that doesn't work you have a very interesting bug indeed 16.07.14 # database_tcd.* even 16.07.20 # database.ignore can be useful 16.07.25 # oh, er, yeah 16.07.29 # Initialize now should be from scratch. 16.07.47 # rasher: yah, but evidently *something* isn't working, so i figure it's worth a try 16.08.00 # evert_: which revision are you using? Also, are you sure there's no trash directory or similar on the player? 16.09.02 # double entries in the database do not happen (only) because of trashes directories 16.09.45 # 16:05 < Torne> even reinitialising it from scratch? 16.09.54 # has that bug been fixed ? 16.10.29 # funman: indeed not, but it's one of the options :) 16.10.59 # 'that bug'? 16.11.00 Quit mcuelenaere ("Reboot...") 16.11.18 # Torne: well. the duplicated database entries 16.11.24 # * Torne was only being paranoid, rather than aware of a particular bug 16.11.34 # ah. alrighty 16.11.42 # it seems that no, i'm not sure a cause have been found 16.12.12 # ok, thanks, it seems fixed by deleting the database_tcd* files and then initializing it again :) 16.12.24 # evert_: do you have auto-update enabled? 16.12.43 # i think so 16.12.45 # normally yes 16.12.47 # I'm almost willing to bet that it's not just a single bug. Much like "the Firefox memory leak" 16.12.49 # FrankTM: there's been some recent (post 3.3) database work that should make it a lot better 16.13.19 # ah. i'll upgrade tonight then 16.15.35 # yah, that was what i was assuming 16.16.33 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 16.18.37 Part pondlife 16.28.21 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 16.32.12 # I have an e200v2 with a broken screen, needles to say it does not seem to work any more. It will plug in and bring up the internal disk. I am going to put a modified update on it and see if i can get rockbox to load. Does rockbox rely on the screen working properly? 16.34.27 # no, but the screen controller must work right 16.34.50 # would you be able to see the button light for example? 16.36.11 # I think he he's blind 16.36.20 # (IIRC) 16.39.41 # New commit by 03mcuelenaere (r21593): Onda VX747: clean up bootloader a bit and make sure storage doesn't get init'd twice 16.39.44 # not totally blind (just some of the time) the button light yes i can 16.40.42 # my concern is the OF going to like it? We will see ;) 16.40.53 # i think it would be the same 16.41.07 # i could boot a fuze with the screen removed, plug it again and see the image 16.41.30 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) 16.44.10 # ahh just the OF does not seem to behave quite right but i can not tell at all 16.48.17 # OK. My host spent 54 seconds per gigabeat f build on average in my database. 22 seconds of that is dependencies 16.48.32 # (real data, no synthetic same-revision builds) 16.50.28 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.50.36 *** Saving seen data "./dancer.seen" 16.52.08 # My measurements show that -j1 builds are more or less 4 times slower than -j builds for the non-dependency part. 16.52.56 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.53.14 # That means that running 5 single core builds instead of 1 -j build will finish 10 builds in 308 seconds instead of 550 (assuming enough RAM is available) 16.53.29 # wish me luck ;) 16.53.39 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 16.54.53 # lights off restart? 16.55.22 # I think that that means that the build system shouldn't use -j (unless the dependency generation gets fixed to allow multi-core operation), and run more builds instead 16.56.05 # That would also give single-core hosts a fairer chance of not getting their builds killed, which means even more savinmgs 16.58.11 Quit fyre^OS (Read error: 110 (Connection timed out)) 16.59.41 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 17.00.45 Quit linuxstb_ (Client Quit) 17.01.48 Quit Zagor ("Don't panic") 17.05.09 # it failsto boot unsure why no feedback at all ;) 17.06.32 # perhaps not only the screen is broken, can you plug it on usb? 17.07.13 # yup, loads then 17.09.42 # there is a file called upgrade.fin there 17.10.02 # the bootloader is worrking now but it just dies after about 3 seconds 17.12.00 # how do you know it died? 17.12.42 # i guess as the screen goes off there is a small light that i can see from the backlight 17.13.19 # might be a sign that rockbox crashed 17.13.46 # the OF does the same i think 17.13.50 Join {phoenix} [0] (n=dirk@84.180.121.254) 17.15.13 # Think its ready for the bin bar the battery ;) 17.15.13 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 17.15.19 Part evert_ 17.15.46 # perhaps you might need the buttons in the future, i keep preciously my dead sansas 17.16.39 Part n00b81 ("Leaving") 17.16.57 # sansas. as in multiple? 17.17.09 # good idea funman in the rubbish to keep box ;) 17.18.42 # FrankTM: yes, plural 17.21.05 # funman: you bricked them? 17.21.33 # i bricked 2, fried 2, broke 1 17.22.17 Join toffe82 [0] (n=chatzill@74.0.180.178) 17.23.31 # hehe 17.23.39 # im currently on my first one ;p 17.24.13 Join {-phoenix-} [0] (n=dirk@p54B4635C.dip.t-dialin.net) 17.25.26 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 17.25.37 Part n00b81 ("Leaving") 17.29.46 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 17.29.53 Join cg_ [0] (n=cromos@cable-kmi-fe71de00-186.dhcp.inet.fi) 17.30.11 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 17.37.15 Quit {phoenix} (Read error: 110 (Connection timed out)) 17.37.33 Quit flydutch ("/* empty */") 17.39.48 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.47.15 Join barrywardell [0] (n=barrywar@86-45-14-110-dynamic.b-ras2.prp.dublin.eircom.net) 17.47.38 Quit suom1 (simmons.freenode.net irc.freenode.net) 17.47.38 NSplit simmons.freenode.net irc.freenode.net 17.47.38 Quit bmbl (simmons.freenode.net irc.freenode.net) 17.47.38 Quit HBK (simmons.freenode.net irc.freenode.net) 17.47.38 Quit Strath (simmons.freenode.net irc.freenode.net) 17.47.38 Quit Zarggg (simmons.freenode.net irc.freenode.net) 17.47.38 Quit killan (simmons.freenode.net irc.freenode.net) 17.47.38 Quit scorche (simmons.freenode.net irc.freenode.net) 17.48.04 NHeal simmons.freenode.net irc.freenode.net 17.48.04 NJoin bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.48.04 NJoin HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 17.48.04 NJoin Strath [0] (n=Strath__@173-23-45-236.client.mchsi.com) 17.48.04 NJoin Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 17.48.04 NJoin killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 17.48.04 NJoin scorche [50] (n=scorche@rockbox/administrator/scorche) 17.48.04 NJoin suom1 [0] (i=markus@viitamaki.net) 17.49.41 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 18.02.48 Join JdGordon| [0] (i=ad7eb975@gateway/web/freenode/x-08d960cfdd148cf3) 18.04.47 Quit funman ("free(random());") 18.07.04 # early works with the Lua plugin: http://fezzik.free.fr/tmp/lua-grahack.zip any advice welcome 18.07.22 # Grahack: (continuing from PM) I don't think I'm the only person to decide over these things 18.09.54 # (to decide about inclusion of my work), ok but you are like the Lua plugin maintainer to me, with a kind of power about that 18.12.50 Quit notlistening (Remote closed the connection) 18.12.54 # what's that 18.12.55 # ? 18.13.47 # Grahack: I think it's currently too early to decide whether your work should be included or not, IIUC it only is a small part of what the Micro Lua framework consists? 18.13.54 # it is currently only* 18.14.09 Quit petur ("work->home") 18.17.18 # Grahack: also, if libtxtdisp depends on actions why don't you require() it in libtxtdisp.lua? 18.18.08 # I tried once and it complained. Did you try ? 18.18.45 # Inclusion: Yes, it is early early works. What I showed you here has no name. µ Lua is a port of Lua to the Nintendo-DS. I plan to make a common API for simple text based scripts. And about my question about inclusion, I just wanted to say that my foles were maybe not ready with Rockbox guidelines. 18.19.34 # I don't think there's any Rockbox guidelins regarding Lua scripts :) 18.20.58 # ok, but the rockbox header is nice (helloworld.lua) 18.23.05 Quit Bawitdaba (Read error: 104 (Connection reset by peer)) 18.23.20 Join Bawitdaba [0] (n=Sphinx@cpe-74-70-40-135.nycap.res.rr.com) 18.28.54 Quit JdGordon| ("Page closed") 18.31.40 # mcuelenaere: there aren't any C specific guidelines either. There just is "Write all code in C." :) 18.32.20 # gevaerts: docs/CONTRIBUTING? 18.32.59 # yes 18.33.54 # Those are more specific than "Write all code in C." 18.35.39 # rasher: there's no indication that the rest is C specific! 18.37.14 # Grahack: did you actually test those scripts in the sim? 18.37.28 # and shouldn't line 19 of test_actions.lua be rb.lcd_clear_display() ? 18.37.47 # (also there's no print() defined in Rockbox Lua by default) 18.38.04 # gevaerts: yea, never typedef in lua too :) 18.38.22 # kugel: also don't make it look like C++! 18.39.32 # gevaerts: we have a problem with the comments I think 18.40.15 # funman: kugel: re r21584 How's this look ? http://pastie.org/530922 18.40.33 # kugel: you could redefine the language, but then that's not allowed either :) 18.42.20 # FlynDice: should work, I assume adc_read(ADC_CVDD) does the job too? 18.42.50 # yes been running for 2 hrs now and no lockups 18.43.20 # is that dependant on something? 18.43.54 # iirc the problem was that the input could be changed in an interrupt while reading the voltage 18.44.03 Quit jon-kha (Read error: 131 (Connection reset by peer)) 18.44.14 # but as there's no "setting the input" anymore 18.44.52 # I hope you know what I mean 18.45.35 # the input is set in adc_read and then read... much cleaner to read and there is a lock done in adc_read also 18.46.28 # I ran about 1.5 hrs with just adc_read and no disable_irq() with no lockups also 18.46.57 # Grahack: also, the placement of the argument to string.rep() in test_libtxtdisp.lua is wrong; it should be within the string.rep() call and not in the .print_clear() 18.47.06 Join JdGordon| [0] (n=Miranda@rockbox/developer/JdGordon) 18.47.49 # Any objections to FS#10403? 18.48.05 # I OBJECT! 18.48.31 # Grahack: hmm you shouldn't lcd_update() after drawing each line, just do one after drawing all the lines; makes it more smoother 18.48.48 Join froggyman [0] (n=Froggyma@pool-72-69-217-158.chi01.dsl-w.verizon.net) 18.48.50 # JdGordon|: I meant, from anyone but you :P 18.49.13 # mcuelenaere: agreed, and sorry I must have been in the middle of something, test_actions.lua doesn't quite work. Gonnaupdate the zip soon 18.49.22 # gevaerts: say what you mean :D 18.50.36 # gevaerts: after looking at it last night I was gong to suggest a really easy way of doing it by manually fudging with the .playlist_control file, but apparently it doesnt have a "add directory" command like I thought it did 18.50.39 *** Saving seen data "./dancer.seen" 18.51.18 # JdGordon|: well, it works now. Adding the rb->playlist_create() was the most important bit 18.51.57 # gevaerts: that sounds like a good feature, but i havne't looked at the patch 18.52.14 # i would but i need to leave veyr soon :) 18.53.25 # JdGordon|: stopping playback first shouldn't be needed, as the plugin grabs the audio buffer anyway. That's also the reason why I made it exit immediately. It would have to reinitialise everything 18.53.57 # ah yes 18.54.14 # Grahack: also don't lcd_update() after lcd_clear_display(), that way it doesn't flicker that much :) 18.54.16 # and playlist)_create() presumably resets the resume info which was another problem 18.54.26 # (when scrolling) 18.54.38 # FlynDice: disable_irq shouldn't be needed then I guess 18.55.00 # I think so, yes. I had assumed that playlist_remove_all_tracks() would leave the playlist in a clean state, but that's apparently not the case 18.55.19 # I then went to look at how pictureflow does this, and stole some code 18.56.10 # gevaerts: is the playlist stored over a reboot? I was having problems with this while doing this on PF 18.56.34 # oh, I didn't read your last sentence :P 18.56.44 # pictureflow uses the tagcache way of building a playlist 18.57.14 # Anyway, this is purely new code so it can't break anything existing, so I think it 18.57.18 # s safe to commit 18.57.24 # go for it... 18.57.31 # I OBJECT 18.57.34 # not :) 18.57.43 # new features in plugins are almost never contentious 18.57.55 # *and* you added the manual change! 18.58.00 # you damned wierdo! 18.58.59 # kugel: it does survive reboots, yes 18.59.32 Quit PaulJam (".") 18.59.46 # New commit by 03gevaerts (r21594): Add "Play Shuffled" menu item to random_folder_advance_config, which adds all configured configured directories to the current playlist in random ... 18.59.54 Quit TheSphinX^ ("XChat@Linux") 19.00.30 # gevaerts: wait...oh 19.00.56 # you aren't really checking the return value, why give it one it the first place? 19.01.15 # kugel: that's the coding style of the file :) 19.01.25 # New commit by 03mcuelenaere (r21595): Lua: because Rockbox doesn't support any current working directory functionality, 'hack' loadlib so it replace '$' in LUA_PATH_DEFAULT with the ... 19.01.51 # checking the return value would allow for a fancy "Plugin returned error" splash :) 19.02.40 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.03.05 # and now I guess you want me to finish off the plugin goto wps thing? 19.03.10 # gevaerts: configured configured? :) 19.03.45 # I might do that now as there's a second plugin that could use it 19.03.56 # New commit by 03mcuelenaere (r21596): Ingenic Jz4740 SD driver: remove some unneeded stuff + fill the OCR field in card_get_info_target() 19.04.01 # it doesn't require much hacking actually 19.04.15 # JdGordon|: yes. You first make the list of where to look, and then the second pass transforms that to another configuration file, so it's configured twice! 19.04.31 # except if you want to do that from plugins executed from the core's context menu or "open with..." menu 19.05.23 # the simplelist just isn't able to do that sort of stuff from what I've seen 19.05.28 # well, it's not too urgent. It's just one keypress after all 19.05.32 # mcuelenaere: updated http://fezzik.free.fr/tmp/lua-grahack.zip. About lcd_update() after lcd_clear_display(), I fixed some but left the ones in libutils.clearscreen(). 19.05.52 # must leavenow, thanks for everything 19.06.01 # gevaerts: aren't you running this plugin from the normal filebrowser? 19.06.19 # I am, yes 19.06.19 Part Grahack 19.06.41 Join funman [0] (n=fun@rockbox/developer/funman) 19.06.41 # I was just thinking that your plans for pictureflow may be to not do that 19.06.49 # Grahack (logs): libutils.clearscreen() should indeed do lcd_update(), otherwise it wouldn't have the effect the name implies :) 19.07.02 # I see yet another color target has lcd invert, /me is tempted to add it to the c200 too now 19.07.16 # * mcuelenaere wonders what the use is of that 19.07.48 # because we can 19.08.10 # and besides that? :) 19.08.57 # gevaerts: no problem from the tag browser too, it's just the simplelist making problems 19.09.02 # but that might be solved later 19.09.15 Join funman_ [0] (n=fun@rockbox/developer/funman) 19.09.17 # ah, ok 19.09.20 # FlynDice: yes looks fine 19.09.40 # kugel: disable_irq() is required, a tick task might change the adc input 19.09.52 # mcuelenaere, no reason really, maybe because everyone else is doing it 19.09.55 # funman_: ascodec is locked in adc_read 19.10.10 # i am not sure mutexes work for tick tasks 19.10.18 # they should 19.10.25 # why shouldn't they? 19.10.31 # a tick task is not a thread 19.10.37 # running in a thread* 19.10.47 # hm, not good 19.11.05 Quit funman (Read error: 54 (Connection reset by peer)) 19.11.29 # bertrik: ah ok, I just wondered because the Onda's don't do this and I thought it would've been a needed feature :) 19.11.47 # kugel: all code using mutexes in a tick task is wrong 19.11.57 # I remember someone saying that too, yes 19.12.15 # and what tick task changes the adc input? 19.12.41 Join TheSphinX^ [0] (n=cold@p54A5C57A.dip.t-dialin.net) 19.13.49 # the one calling battery_adc_voltage, but in fact it seems to be done in the power thread 19.15.15 # then i don't understand why the input was changed at all .. 19.15.42 # so we don't need to disable irq? 19.16.09 # if there's no tick task reading battery, no. but we need to understand what is going on before changing the code again 19.16.25 # New commit by 03gevaerts (r21597): Assume a smaller plugin binsize, so MAX_SHUFFLE_SIZE actually fits on archos 19.16.51 # I think there's also a bug in the adc read code, the datasheet suggests that there's a ADC-ready bit, maybe we should wait for that before getting the ADC value 19.16.52 # ascodec on AMS doesn't yield() 19.17.41 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 19.17.56 # bertrik: right, bit 0 of IRQ_ENRD_2 19.18.14 # Grahack: do you read the logs? 19.20.23 # is it possible that ascodec-pp is misnamed? 19.21.01 # kugel: if it's the case, ascodec-as3514 as well 19.21.21 # where is adc_read() defined for as3514 ? 19.21.25 # ascodec-pp has nothing to do with ascodec imo 19.21.37 # adc-as3514.c 19.22.00 # hum right 19.22.16 # should go in sandisk/audio* 19.22.20 Quit barrywardell () 19.23.22 # do I read correctly, from the linked email in the latest post to the Nano 2G thread, that fxb is involved in the efforts to get code running on it ? 19.23.31 Quit mt (Read error: 113 (No route to host)) 19.24.22 # amiconn: anything against http://pastie.org/530998 ? 19.25.00 # funman_: uhm, we compile adc-as3514.c? it should be renamed also then 19.25.48 # kugel: renamed to what? 19.25.54 # funman_, one thing I always found weird in the rockbox csd handling, is the fact that it is kept in 4 32-bit words, instead of a simple byte-array 19.26.06 # no idea, it's a single function anyway 19.26.23 # or at least adc-as35xx.c or so 19.26.25 # bertrik: hum well the card_extract_bits() function works fine with the 4 32-bit words 19.26.41 # kugel: it's specific to as3514 (sansa e200v1 and c200v1 use it) 19.26.57 # mcuelenaere: yes I read the logs. I updated the string.rep thing. I cameback to know your general idea about my files too. Wo what do you think ? 19.27.13 # kugel: and the sd_command() functions use this kind of data array 19.27.20 # sorry my last comment was for bertrik 19.27.40 # funman_, I wasn't criticising your patch :) 19.27.50 # funman_: we use it too 19.28.00 # bertrik: well i wasn't thinking it's a critic, but your question is interesting 19.28.13 # adc-ascodec.c is probably a better name 19.28.17 # the SD controllers use 32 bits registers so it's easier to copy into a 32bits integer type 19.28.17 # I just see no good reason to store it as a couple of 32-bit words 19.28.38 # this looks like pretty good news: http://forums.rockbox.org/index.php?topic=6518.msg152565#msg152565 19.29.15 # hopefully it will be possible to decrypt, but also to encrypt firmwares for the nano 2g 19.29.38 # the linux4nano people claim to have got thier code to run on the Nano2G 19.29.40 # * bertrik needs to hurry up with s5l8700 stuff 19.29.52 # i thought the notes vulnerability was not exploitable 19.30.26 # * bertrik mumbles something about pudding 19.30.30 # we'll see what they have soon enough I guess 19.30.35 # saratoga_: that's pretty cool, but then I don't understand why this dump was so difficult 19.30.37 # but they claim: "tof, Taylor Gordon, Cory Walker and Dan Andrews (donator of the iPod nano) succeed to inject some working ARM assembly code within the iPod Nano firmware (victory message here" 19.30.59 # bertrik: checking the bit 0 in IRQ_ENRD_2 results in a dead lock, I think it can only be used with interrupts ? 19.31.13 # the pp ascodec seems to yield indeed 19.31.31 # bertrik: I'll try to get you another S5L8700 target soon then :) 19.31.51 # (the M6SL in case you tink I have a nano for you..) 19.32.09 # funman_, the datasheet says (edge) for this bit, so maybe this bit is only high for 1 read (i.e. clear-on-read) 19.33.22 Quit Rob2222 () 19.33.48 Join Rob2222 [0] (n=Miranda@p4FDCCB64.dip.t-dialin.net) 19.33.55 Quit funman_ ("Reconnecting") 19.34.27 Quit Grahack ("Leaving.") 19.35.13 # saratoga_: Well, there's one way to find out. I have my 2nd gen nano still sitting and waiting for some action. 19.35.24 Join funman [0] (n=fun@rockbox/developer/funman) 19.35.35 # hm, this doesn't look so good: https://mail.gna.org/public/linux4nano-dev/2009-07/msg00008.html 19.35.56 # bertrik: i used a while loop: while (!(ascodec_read(AS3514_IRQ_ENRD2) & (1<<0))) ; 19.36.12 # * mcuelenaere wonders why linux4nano-dev 403'd their logs 19.36.16 # IRC logs* 19.36.23 # or are they talking about their own writig and not the dump? 19.37.17 # mcuelenaere: That sounds a little fishy if you ask me. 19.37.33 # LambdaCalculus37: probably just because the dump is there 19.37.51 # mcuelenaere: And I want to see that dump! :) 19.38.07 # Maybe we can finally figure out how to get something running on the 2nd gen nano! 19.38.14 # And we should get bertrik one, too! :P 19.38.50 # for the goodness of Sansa AMS port, NO ! 19.39.07 # LambdaCalculus37: try asking in #ipodlinux, they mention "felix burns" in their post, which I *assume* is meant to be "felix bruns", which is fxb :) 19.40.51 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 19.40.52 # mcuelenaere: they're freakishly paranoid 19.41.44 # why that? like Apple is going to sue individual persons for just a ROM dump.. 19.41.58 # and on a 2 generations old model 19.43.33 # mcuelenaere: that's why I say "freakishly" 19.44.29 # if they live in the us i can understand :) 19.44.55 # yeah the law in the US is definately against them on this point, so I can understand some caution 19.45.49 Join stripwax [0] (n=fircuser@genkt-048-005.t-mobile.co.uk) 19.46.53 # the Ipod2G and Mezui players have the same SOC right? 19.47.41 # Yep. 19.48.05 # saratoga_: meizu_dfu did send test code to the nano2G. 19.48.52 Quit stripwax (Read error: 104 (Connection reset by peer)) 19.48.55 # saratoga_: nano 2G 19.49.06 # ipod 2G is something different :/ 19.49.44 # FlynDice: why did you suspect the ADC input was changed ? (r21584) 19.51.00 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.51.48 # funman: because there were no problems without the voltage reading code, about 3 battery benches worth... 19.52.33 # FlynDice: perhaps the adc input is reset after a read 19.52.54 # I had understood 'changed' as in changed by our software, not by the as3514 chip 19.54.06 # I found that when it locked up it was still running, ie I had to hold the power button for 6 secs to turn it off, so I suspected the new loop 19.54.20 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 19.54.36 # and when I remmoved the loop the problems disappeared 19.55.24 # so my guess was that something else was changing the input. I addressed that problem and there were no more lockups. 19.55.49 # gotta go for a few hours, be back later 19.56.28 # see you 19.56.36 # we should check what the input is reset to 20.01.04 Quit Xerion (" ") 20.01.54 Quit Horscht (Nick collision from services.) 20.02.03 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 20.02.11 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 20.02.19 Join arohtar [0] (n=faemir@78.33.109.163) 20.02.27 Quit Horscht ("Verlassend") 20.02.35 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 20.06.06 Join petur [0] (n=peter@94-225-45-136.access.telenet.be) 20.09.53 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.10.10 Quit faemir (Nick collision from services.) 20.10.29 Quit arohtar (Client Quit) 20.10.46 Join faemir [0] (n=faemir@78.33.109.163) 20.12.33 Quit funman ("free(random());") 20.16.23 Quit CaptainKwel (Read error: 60 (Operation timed out)) 20.20.43 Join CaptainKwel [0] (n=jason@cpe-68-173-40-122.nyc.res.rr.com) 20.28.01 Quit kugel ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 20.29.22 # gevaerts: ah yes, thats what I wanted to say..... why use a static buffer size? use plugin_get_buffer() and figure out how big it can be from that... 20.29.51 # JdGordon|: ah yes. That's because I'm not used to dealing with plugins I guess 20.30.00 # * gevaerts starts to fix 20.30.24 # it probably wont make much difference, but its nice to use the whole buffer so people can have massive lists 20.30.38 # that is possibly happening in rfa.rock already 20.31.33 # it won't make much difference, but it's break-proof 20.32.08 # as long as you dont break the needed maths :) 20.32.48 # * gevaerts can divide by sizeof(int), tyvm :) 20.33.37 # showoff :p 20.38.01 Join PaulPosition [0] (n=now@modemcable013.174-56-74.mc.videotron.ca) 20.38.34 Quit PaulPosition (Client Quit) 20.42.55 # New commit by 03gevaerts (r21598): Remove the static order[] allocation in favour of plugin_get_buffer() 20.43.40 # JdGordon|: on 512k plugin buffer targets, you have room for about 125k directories. I'm pretty sure that's plenty :) 20.44.05 # careful with those sort of statements 20.44.57 # and you dont anyway... unless they all take up 0 bytes? 20.45.18 # lowmem targets will have to make do with 6977 folders 20.46.02 # hmm... you're using the plugin buffer for the order array and the audio buffer for the folder name buffer? 20.46.07 # JdGordon|: I allocate an array of ints, and shuffle that. The list of directories is actually in the audio buffer 20.46.15 # snap! 20.46.22 # right, yeah that should be sweet 20.46.45 # I briefly thought about shuffling in place, but that would have required lots of memcpys 20.48.02 Quit linuxstb (Read error: 113 (No route to host)) 20.48.51 Quit flydutch ("/* empty */") 20.49.54 # New commit by 03gevaerts (r21599): clarify error message a bit 20.50.43 *** Saving seen data "./dancer.seen" 20.50.53 Join Xerion [0] (n=xerion@82-170-197-160.ip.telfort.nl) 20.52.12 Quit faemir (Remote closed the connection) 20.54.52 Join kugel [0] (i=kugel@rockbox/developer/kugel) 20.55.16 # JdGordon|: if someone actually hits the limit (which I guess is just about possible on the archoses assuming short albums, low bitrate and/or weird directory structures), there's always good old random folder advance :) 20.55.52 # wouldnt they hit some FAT 20.55.56 # umm.. 20.56.04 # fat limitation first on the small disk? 20.56.19 # JdGordon|: archos disks can be giant 20.57.53 # hm, the actual limit for random folder advance itself is probably smaller (+-4000 if the audio buffer is 1M) 21.02.35 Join funman [0] (n=fun@rockbox/developer/funman) 21.04.04 # anyway, that's plenty. If you assume that a normal album takes about 100MB (about 192kbit,1 hour), you'd need a 400GB disk to reach that limit. The largest disk I know of you can actually buy is 320GB 21.04.28 # pretty close already 21.04.55 # just grab dbestfit from PDa and use malloc :p 21.05.06 # yes, but they're probably not going to make new bigger PATA disks 21.06.16 # Anyway, I've never heard complaints from people who hit that limit 21.06.20 # and 100MB is pretty much for an album 21.06.32 # but we shouldnt go out of our way to set artificial limitis 21.06.35 # but they could make bigger flash drives, and there are flash->PATA adapters :-P 21.06.42 # kugel: not if it's FLAC 21.06.57 # BryanJacobs: he's assuming 192kbit/s 21.07.14 # 192k MP3s are like 1.5MB/min, no? 21.07.25 # 95% of my albums are less than 100MB 21.07.41 # All limits in rockbox are tradeoffs, and those which have a significant impact on memory usage are therefore configurable 21.07.44 # my whole music collection fits in 12GB if I convert to MP3 21.07.51 # BryanJacobs: 1.37 21.08.01 # JdGordon|: this one isnt't very artificial. The only way to fix it would be to use dynamic sizing for the directory names, and not just allocate MAX_PATH bytes for them 21.08.16 # gevaerts: that's what pf is doing 21.08.18 # Mikachu: I was pretty close :-P 21.08.18 # amiconn: (sorry for repeating) anything against http://pastie.org/530998 ? 21.08.24 # funman: how big are they on average? 21.08.52 # you might want to look into that (unless you feel comfortable with that high limit, which sounds reasonable) 21.09.05 # funman: Not really, but I don't see the necessity. 21.09.18 # kugel: it's an old limit. I'm not very bothered by it, as long as what I 21.09.26 # The extra calculation is small though. Btw, did you try replacing / with >> and % with & ? 21.09.27 # 'm doing doesn't decrease it :) 21.09.28 # amiconn: consistency with docs and established bit order 21.09.37 # Sometimes gcc is too dumb to even optimise that 21.09.37 # no i didn't touch the function 21.09.57 # it's not very important, only called at card init / or in debug menu 21.10.13 # binsize... 21.10.23 # to save 3 instructions ? 21.10.34 # clearly even 12bytes are important 21.10.43 Quit __lifeless (Read error: 60 (Operation timed out)) 21.10.47 # Well, in this cases gcc *should* manage, as the involved variables are unsigned 21.10.48 # but, if it's trivial, why not 21.11.01 # gevaerts: 61.6MB 21.11.03 # In case of signed division it's not just 3 instructions 21.11.24 # funman: ok. You need a 250GB disk to hit the limit then :) 21.11.32 # you can get that! 21.11.35 # well i didn't look at binsize 21.11.44 # x / y != x >> log2(y) 21.11.55 # similiar but not exact for corner cases 21.12.01 # gevaerts: just poke Unhelpful, he'll gladly convert to his alloc library for you :) 21.12.09 Join aaron424 [0] (n=410d02d8@gateway/web/cgi-irc/labb.contactor.se/x-f692b0e9d1f42e7f) 21.12.37 # kugel: I don't think that will really help actually. We're already using the entire audio buffer 21.12.39 # wincent: ping 21.12.41 # BryanJacobs: For positive results and y being a power of two it is, but not if the result is negative 21.12.51 # amiconn: like I said... 21.12.57 # gevaerts: you don't need MAX_PATH per directory 21.13.04 # New commit by 03funman (r21600): card_extract_bits() take the start bit argument as defined in public SanDisk specifications for SD and MMC, i.e. bit 0 is the lsb 21.13.12 # The difference is that integer division is supposed to round towards zero, while >> rounds towards negative infinity 21.13.14 # you can alloc the actual length (+ \0) 21.13.20 # kugel: true, but we also don't need an alloc library to avoid it 21.13.32 Join faemir [0] (n=faemir@78.33.109.163) 21.13.47 # kugel: as soon as someone complains, we'll fix it. I don't think we should bother before that though 21.14.23 # gevaerts: The file browser does allocate the strings dynamically (within its static buffer which assumes an average name length) 21.14.24 Quit aaron424 (Client Quit) 21.14.29 # * kugel goes posting a bug report 21.14.50 # :p 21.16.46 Join perrikwp1 [0] (n=Keith@rrcs-96-10-92-195.se.biz.rr.com) 21.17.47 # There's also this slight issue with compatibility here. The binary data structure gets written to disk, and that file gets used by playlist.c to dothe actual random folder advance. All that would need to be re-done, and people would have to regenerate the file 21.18.33 Join barrywardell_ [0] (n=barrywar@rockbox/developer/barrywardell) 21.18.34 Quit BryanJacobs ("Java user signed off") 21.19.03 # it was done that way for speed and simplicity reasons 21.19.29 # being able to do buffer[i*MAX_PATH] makes things dead simple 21.19.56 # indeed 21.20.33 # well, you could have the plugin write the same format whatever it's internal structure, but that gets even more complicated 21.21.24 # it would also slow down the writing of that file 21.21.47 # how about leaving it as it is for now? :) 21.22.06 # hm, maybe we could try that :) 21.26.38 Join p3tur [50] (n=petur@rockbox/developer/petur) 21.30.54 Join Lear [0] (i=chatzill@rockbox/developer/lear) 21.35.24 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.35.52 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 21.38.01 Quit perrikwp (Read error: 110 (Connection timed out)) 21.41.36 Quit faemir (Read error: 110 (Connection timed out)) 21.45.20 Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) 21.51.54 Join _lifeless [0] (n=lifeless@188.16.113.228) 21.52.39 Quit funman ("free(random());") 21.55.22 Quit Beta2K (Remote closed the connection) 21.55.34 Join beta_ [0] (i=1000@d24-36-78-223.home1.cgocable.net) 21.57.42 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 21.58.35 Quit barrywardell_ () 21.58.51 Quit LambdaCalculus37 () 21.59.27 # FlynDice: for the logs, http://pastie.org/530922 does not help microsd problems on e200v2 22.09.00 # mc2739: that's weird 22.09.10 # I have no sorts of microsd problems 22.09.24 # I tried pluging in and out in several situations 22.09.50 # what good is it for the logs if the paste disappears? 22.10.23 # what? 22.12.12 # kugel: I also tried the v2 patch from FS#10344(with the 1.05v setting) and get the same behavior 22.13.42 # with clean svn r21600 and reverting r21584 and r21577 microsd works again 22.21.51 Join FlynDice_ [0] (n=FlynDice@c-76-121-18-103.hsd1.wa.comcast.net) 22.22.36 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 22.22.45 # tmzt: since the message was directed at the creator of the paste, he should know what it is even if it disappears 22.23.12 Quit {-phoenix-} (Remote closed the connection) 22.24.26 # mc2739: are you stilll having msd problems? 22.24.30 Quit froggyman (Read error: 104 (Connection reset by peer)) 22.24.46 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 22.25.23 # FlynDice_: yes 22.26.24 # I'm playing off my 8GB msd right now with no problems, but I have had problems in the past 22.27.09 # I found formatting will let the card work but is not necessary 22.27.47 # I wonder if this maight be the same sort of problem as the FM radio - different hardware versions 22.27.57 # I also found that going back to the OF and playing off of the card would then let me use it in rockbox 22.28.59 # I could try that, but the OF takes so long to rebuild it's database 22.29.08 # I was getting this behavior unrelated to the core voltage patch though 22.29.30 Join faemir [0] (n=faemir@78.33.109.163) 22.30.14 # Yes, I had that same feeling so I was skipping that and my card wouldn't work 22.31.31 Join n00b81 [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 22.32.49 # FlynDice_: my problems are caused the core voltage change - I reverted that and it works fine again 22.33.02 Part n00b81 ("Leaving") 22.35.13 # I'm not argueing that I'm just telling you my experience, and that I'm playing off of my msd with no problem right now 22.39.31 # kugel said his is working fine too, which is why I started wondering about the possibility of different hardware versions. 22.39.53 Quit bertrik (Remote closed the connection) 22.40.20 # mc2739: did you try adding some mci_delay()s in sd_init_card? 22.41.33 # kugel: no, I have not tried that 22.42.21 # mc2739: I expect that cards are making the problems. I've never had problems with my card, but others so we kept adding mci_delays there 22.42.21 Quit lilltiger (Read error: 104 (Connection reset by peer)) 22.42.53 # mc2739: have you tried inserting the card while boosted, such as when buffering or in boosting plugins like pictureflow? 22.43.20 Quit efyx (Remote closed the connection) 22.43.36 # no, but I can try that now 22.45.58 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 22.46.13 Join lilltiger [0] (n=lilltige@82.145.152.217) 22.46.18 Part n00b81 ("Leaving") 22.47.03 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 22.48.32 # gevaerts: you going to fix the dir skip actions in the wps to work with your new playlists? 22.48.58 # JdGordon|: are they broken as such? 22.49.25 # well,. they dont work with playlist playlists 22.49.30 # umm... non dirplay playlists 22.50.46 *** Saving seen data "./dancer.seen" 22.50.49 Join funman [0] (n=fun@rockbox/developer/funman) 22.51.29 # kugel: that seems to work. I boosted from the CPU frequency debug screen and then inserted the card. It reads the card without problems. 22.51.44 # mcuelenaere: does onda support both SD and MMC cards ? 22.51.58 # gevaerts: see, now what i want to go with your nice random folder playlist thing is a skip to next album button :) 22.52.06 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 22.52.11 # funman: the SoC does, but the physical card holder is SD-only (for the current devices using that SoC) 22.52.18 # microSD that is 22.52.34 # mcuelenaere: i'm a bit disturbed by the references to "mmc" in ata-sd-jz4740.c :) 22.52.43 # yeah, that's not really my code 22.52.47 # I know, it's a mess .. :( 22.52.50 # ok :/ 22.52.59 # Torne: there's still plain old random folder advance :) 22.53.01 Join efyx__ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 22.53.05 # do you know in which word-order the cid & csd are stored in memory ? 22.53.06 # mc2739: can you try a build using 192MHz (there's a patch somewhere around offering such profiles which automate frequency selection), I'm wondering if the boosting act as such, or the voltage causes the problems 22.53.14 # gevaerts: that doesn't help though does it? 22.53.30 # or is there some trick i'm missing 22.53.40 # funman: no idea, I saw that the code stores it in the way the SD interface receives it 22.53.43 # 192MHz as CPUFREQ_MAX 22.53.45 # or in other words does the debug screen -> disk info look correct for manufacturing date / product id serial number .. 22.53.50 # nope 22.53.59 # that's why there's a TODO at that function ;) 22.54.13 # disk info debug menu read this info directly from the registers 22.54.17 # some of them look/looked correct, but most don't 22.54.18 Quit bertrik (Read error: 104 (Connection reset by peer)) 22.55.13 Quit efyx (Read error: 104 (Connection reset by peer)) 22.55.36 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.55.56 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 22.56.16 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 22.56.47 # why is mmc_request->response 18 bytes and not 16 ? 22.57.05 # the real data seems to start after the 1st byte 22.57.09 # Torne: /me thinks that Torne should have another look at the manual :) 22.57.17 # * Torne grumbles :) 22.57.30 # i want to reverse the order in which cid/csd registers are stored and i need to correct the uses in all drivers 22.57.52 # to avoid touching this driver I could write another implementation of card_extract_bits for SD 22.57.57 # gevaerts: aha 22.58.06 # so that picks the next directory from the fs? 22.58.13 # my last commit is wrong : the cid/csd registers need to be stored most significant word first 22.58.14 # kugel: it already works at 62mhz and 248mhz without the voltage change 22.58.33 # back later 22.58.34 # Torne: depends on your settings. It can also pick a random one 22.58.55 # mc2739: I know, but now changing the frequency isn't instant anymore, and more complex 22.59.35 # i was gonna say "but then you have to rebuffer" but i guess with a big playlist like your code generates then it's likely to have to rebuffer to skip by a whole album ayway 22.59.37 # mc2739: i just noticed a lock up with my microsd card 22.59.40 # unless it's a pretty short album 22.59.54 Quit robin0800 (Remote closed the connection) 23.00.19 # I'm wondering if we need to boost on (microsd) data transfers, just to keep the voltage up 23.00.30 # Torne: yes. If you never skip, the new feature is better. Otherwise not 23.01.04 # what does next folder do if you're playing a tagcache playlist then? 23.01.07 # nothing? 23.01.45 # that probably wouldn't even cost much 23.01.47 # funman: I didn't really change much in the code, just adapted it to Rockbox 23.01.51 # I'm not sure. probably not what you want 23.01.57 # on most transfers (rebuffering), we're boosting anyway 23.02.07 # * mcuelenaere should really write a new SD driver but doesn't really feel like doing so.. 23.02.10 # * gevaerts uses neither the next directory keys nor the database 23.02.24 # yah, i meant with your playlist thingy 23.02.25 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 23.02.39 # kugel: isn't microsd transfer dma so should the processor core voltage even matter? 23.03.05 # obviously, it's affecting more than only the core voltage 23.03.08 # I guess the same thing. It's not really meant to be used with multi-directory playlists, so who knows what will happen? 23.03.15 # so did anyone around here get to see any nano2g romdump ? 23.03.39 # * gevaerts just wrote some code to generate a playlist, and suddenly people assume that he knows how playback works... 23.03.42 # hehe 23.03.46 # ok, i'll have a look/fiddle later 23.04.03 # if it does something useless it might be nice if it went to the next file that was in a different directory to the currently playing one? 23.04.16 # which would do soemthing useful for nonshuffled playlists 23.04.18 # Torne: you can't dirskip in tagcache playlists 23.04.28 # kugel: right. 23.04.44 # mcuelenaere: would you help me cleaning it if i break it with my changes? 23.04.59 # Bagder: did you see my -j calculations at http://www.rockbox.org/irc/log-20090701#16:48:17 ? 23.05.38 # funman: you mean the Ingenic driver or the generic part in Rockbox? 23.05.46 # gevaerts: now I did! 23.05.48 # thanks 23.06.54 # Torne: that would be useful, yes. Not sure how easy it would be though 23.07.39 Join funman_ [0] (n=fun@rockbox/developer/funman) 23.07.44 # gevaerts: how do you mean it would affect single-core hosts? 23.07.55 # kugel: pong 23.08.47 # mcuelenaere: the ingenic part 23.08.54 # funman: sure 23.09.03 # though i can commit for PP & as3525 and then work on ingenic on flyspray 23.09.15 # "C++ library exception" ... 23.09.19 # in the bootrom? 23.09.21 # ;-) 23.09.29 Quit funman ("Reconnecting") 23.09.29 Quit Horscht (Read error: 110 (Connection timed out)) 23.09.33 # Zagor: hm, now I think about that particular bit a bit more, it doesn't make much sense... 23.10.19 # wincent: I was just wondering if you can use the sin/cos table that's in rockbox (instead of that giant one which bloating the plugin buffer) 23.10.38 # gevaerts: could probably be done, get_next_dir in playlist.c already does a huge amoutn of messing around to search the dircache for it, i doubt scanning the playlist would be any worse :) 23.10.51 # Zagor: currently if a multicore host and a single-core host are doing the same build, the single-core one will likely get killed. If all builds are done with -j1, chances will be evened out, but I don't think (now) that this will make much difference in total time 23.10.53 # funman_: just commit, I'll shout when you broke something ;) 23.11.03 # kugel: Where does this table reside? 23.11.23 # mcuelenaere: well i just won't use the common code on ingenic 23.11.35 # Torne: indeed. Just some strrchrs and strncmps I guess 23.11.43 # i'm still looking at PP code, then i'll move some code out from PP & AMS code into sd.c 23.11.53 # wincent: in several places :) see http://www.rockbox.org/tracker/task/10400 23.12.09 # funman_: have you had time to test my mkamsboot patch? 23.12.24 # rasher, if you have a minute this one is stopping me at the moment http://pastebin.com/d4ffb1625 23.13.29 # gevaerts: I think it would make a difference until we have 106 build clients or have the clients to parallel builds 23.13.58 # kugel: no :/ where is it ? 23.14.31 # kugel: Thank you very much for pointing this out, I think I will change to the sin/cos table of rockbox later. 23.14.35 # kugel: but we actually don't want multiple clients building the same target it we can avoid it. hence it's better to do each build quickly instead of doing many builds slowly. 23.14.44 # funman_: http://www.rockbox.org/tracker/task/10397 23.15.05 # Zagor: no, I mean 1 client doing multiple builds :) 23.15.17 # Zagor: maybe we should just try both ways. It's going to be hard to work out the numbers from scratch 23.15.19 # kugel: yes, that means each build will be slower 23.15.22 # instead of -j, since gevaerts showed the depgen limits 23.15.42 # gevaerts: true. statistics rule. 23.16.20 # wincent: I don't know what accuracy you need though, the rockbox' one has only 90 values 23.17.13 # If you never allocate the same build to different clients, the -j1 approach will win. If you multiple-allocate lots of builds, the -j approach will get a lot closer and maybe win. That means it also depends on the build client vs builds ratio 23.18.25 # we should focus on getting it up and running at all, so we can collect statistics 23.18.26 # hm, the romdump is little endian? 23.18.46 # Zagor: the main problem atm is the client's too frequent dyings 23.18.53 # kugel: Yes, the one from Pure Data is way greater. I will look into this later. 23.18.57 # Bagder: dying? 23.19.05 # yes the 0-length pipe thing 23.19.09 # * Torne still needs someone who nderstands the beast to explain some of the boot process :) 23.19.29 # that, and the make process not being killed properly 23.19.41 # oh, I see that now. oddness. 23.19.45 # Bagder: did we actually try my latest patch for that? 23.19.55 # no, not yet 23.20.40 Join funman [0] (n=fun@rockbox/developer/funman) 23.20.56 Quit bmbl ("Bye!") 23.21.50 # hm, what was my latest patch? negative signal or negative pid? 23.22.10 # :q 23.22.16 # * kugel suddenly feels motivated to try out rfa and working on plugin-goto-wps 23.22.30 Quit funman_ ("Reconnecting") 23.22.53 # * JdGordon| isnt sure plugin-goto-wps is a good idea.... 23.23.02 # negative signal I beleive 23.23.20 # JdGordon|: why? 23.23.57 # hm, timestamps seem to show the opposite 23.24.08 # it doesnt sit well with me.. 23.24.22 # but you can't explain that? 23.24.50 # yeah :/ 23.25.07 Quit FlynDice_ (Remote closed the connection) 23.25.49 # Bagder: I now have one of each running, so maybe we can just try? 23.26.38 # Also one core each to increase my chances of killed builds 23.26.39 # oh wait! dont start any runs 23.27.39 # ok, my client is giong again, you can start them 23.27.58 # sorry, but I don't have time to play with that atm 23.28.06 # how rude! 23.28.07 # :p 23.28.18 # * gevaerts looks at Zagor instead :) 23.28.19 # jarjargordon 23.28.58 # gevaerts: what is the patch you are talking about? 23.30.30 # Zagor: http://pastie.org/524770.txt which didn't solve it, and then http://pastie.org/524789.txt on top of that (untried, and a bit voodoo) 23.31.18 # basically the problem is that you just kill the shell, but not any childprocesses of that 23.31.50 # the second patch is reversed 23.32.10 # ah, right. so how do we kill the whole process tree? iterate through the pids? 23.32.38 # -$pid or -signal seems a bit... arbitrary. is that documented anywhere? 23.32.50 # From /bin/kill, just use the negative of the parent pid. In perl, it's a bit confusing 23.33.29 # so maybe `kill -9 -$pid`? :) 23.33.43 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.34.00 # * gevaerts tries to slowly transform this nice perl script into a shell script 23.34.21 Join tessarakt [0] (n=jens@e180072091.adsl.alicedsl.de) 23.35.03 # yeah perl does not do what /bin/kill does 23.35.42 # Bagder: did you change the server location or is it still running from the same place? 23.36.06 # I've been running it in my own dir during my tests 23.36.12 # it's weird actually. kill(2) should behave the same as /bin/kill 23.36.23 # Zagor: it needs a data subdir, where it moves the completed builds 23.36.34 # so I don't know why perl is different 23.36.48 # gevaerts: yes but perl has to deal with inter-system portability. bsd != posix for instance. 23.38.13 # true. We need to be careful with that as well... How do osx and freebsd behave? 23.38.26 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.40.27 # I don't know 23.40.36 # any osx people here? 23.40.56 # Bagder: can you disable your test server so I can run one? 23.41.07 # http://nixdoc.net/man-pages/FreeBSD/kill.1.html and http://nixdoc.net/man-pages/FreeBSD/man2/kill.2.html seem to suggest that it's safe on freebsd at least 23.41.17 # ah sorry, done now 23.43.48 Join lee321987 [0] (n=chatzill@adsl-76-250-135-220.dsl.dytnoh.sbcglobal.net) 23.43.56 # Zagor: lambda, lostlogic and preglow I tihnk are our resident turtleneck wearing hippies :D 23.43.57 # http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/kill.2.html shows that osx kill(2) is safe as well. http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/kill.1.html seems to be unclear 23.44.27 # Sansa e200 devices: anyone know if the numbers that look like this "SDMX4-2048-A70" can be used to determine v1/v2 version? 23.45.30 # gevaerts: I guess there's only one way to find out :-) 23.45.50 # Zagor: I also found http://books.google.com/books?id=hP4IRp8xwTkC&pg=PA653&lpg=PA653&dq=perl+killpg&source=bl&ots=ti6Ttym4z9&sig=kXUgRgkWAbSTGQ2E-okcZgaOU3A&hl=en&ei=2dhLSpmvOtLW-QaehtDeBQ&sa=X&oi=book_result&ct=result&resnum=6 23.46.10 # lee321987: original firmware version is the only really safe way we know 23.46.36 # so perl seems to use negative signal numbers instead of negative pids to do this 23.47.28 # gevaerts: aha. is that what your test client does now? 23.47.38 # one of them, yes 23.47.45 Quit lee321987 (Client Quit) 23.49.18 # New commit by 03funman (r21601): add firmware/driver/sd.c which contains common code between SD drivers ... 23.53.41 # Zagor: we did get some funny results the other day when some build clients deliver builds that already were completed by another client 23.54.01 # that's fixed now though 23.54.29 # ok 23.54.55 # and it now rejects duplicate client names (from the same user) 23.55.23 # good 23.56.06 Quit bluebrother ("leaving")