| 00:03:04 | gevaerts | 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 | kugel | no I didnt |
| 00:04:37 | | Part domonoky |
| 00:04:47 | gevaerts | ok. I won't integrate it yet in my patch then :) |
| 00:06:28 | Hillshum | has anyone made any clip themes? |
| 00:12:00 | rasher | Hillshum: There's cabbiev2 |
| 00:12:10 | | Part Ubuntuxer |
| 00:12:16 | Hillshum | rasher: any others? |
| 00:12:28 | rasher | 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 | saratoga_ | 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 | saratoga_ | 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 | CIA-69 | New commit by saratoga (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 | bertrik | Hillshum, I haven't seen a hang on my clip since reverting 21577 (although not very thoroughly tested yet) |
| 00:54:42 | Hillshum | bertrik: It won't boot at all |
| 00:55:50 | bertrik | you can unpatch the changes from a specific revision by doing 'svn diff -c <revision> >revision.patch', then doing 'patch -p0 -R <revision.patch' |
| 00:56:02 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 00:58:15 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 00:59:01 | | Quit DarkDefender ("Leaving") |
| 00:59:41 | amiconn | Hmm, no Lear around# |
| 01:00 |
| 01:00:01 | * | amiconn wonders how un-inlining functions would significantly change stack usage |
| 01:00:16 | Mikachu | amiconn: the function is recursive |
| 01:00:25 | amiconn | and? |
| 01:00:46 | amiconn | Inlined or not - each call will allocate a stack segment |
| 01:00:51 | Mikachu | it allocated 512 bytes on the stack every recursion befoer |
| 01:00:57 | Mikachu | 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 | Mikachu | that memory was only used before the recursive call anyway |
| 01:01:22 | amiconn | That's still the same stack |
| 01:01:51 | Mikachu | 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 | Mikachu | it used to be push 512 bytes -> call self -> push 512 bytes -> etc |
| 01:02:20 | amiconn | Yes, and I would expect gcc to free this space as well if the function is inlined |
| 01:02:23 | Mikachu | now it is call new -> push and pop 512 bytes -> call self -> etc |
| 01:02:23 | bertrik | I can imagine saving memory by reusing the same path buffer (appending and truncating it as you go deeper or shallower) |
| 01:02:48 | Mikachu | 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 | amiconn | 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 | KittenKat | so i was wondering, has anyone had any luck getting the C200 usb to actually mount under linux? |
| 01:04:25 | amiconn | 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 | Mikachu | amiconn: it didn't end before it calls itself though |
| 01:04:59 | amiconn | The *inlined* function does end before the containing function calls itself |
| 01:05:21 | KittenKat | 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 | Mikachu | right, okay |
| 01:05:46 | Mikachu | i agree it is pretty silly of gcc if it helps to uninline it now that i think about it :) |
| 01:05:58 | gevaerts | KittenKat: ubuntu 9.04? |
| 01:06:00 | Mikachu | i was caught up on the fact that the same commit split out the allocation to a new function |
| 01:06:01 | Llorean | KittenKat: Ubuntu or an ubuntu derived distro? |
| 01:06:19 | amiconn | Inlining shouldn't change stack usage (apart from the return address on targets which have no link register, and stack args) |
| 01:06:22 | KittenKat | ubuntu derived distro |
| 01:06:22 | KittenKat | also fails under debian |
| 01:06:22 | KittenKat | and slackware |
| 01:06:34 | amiconn | If it does, I'd consider that a major gcc bug |
| 01:06:39 | KittenKat | no windows boxes to try it on |
| 01:06:54 | gevaerts | KittenKat: are you running hal? |
| 01:07:16 | KittenKat | yup |
| 01:07:32 | gevaerts | ok. Most probably this gphoto2 bug then... |
| 01:07:33 | amiconn | The new function makes sense, the explicit __attribute__ ((noinline)) doesn't, afaiu |
| 01:07:49 | KittenKat | didnt auto or manual mount, i tried every variation of the mountpoint |
| 01:09:01 | gevaerts | KittenKat: have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/355998 |
| 01:10:20 | KittenKat | 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 | gevaerts | KittenKat: can you pastebin the lsusb -v output for the c200? |
| 01:12:12 | KittenKat | 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 | gevaerts | I'll probably be asleep by then. Just link to it here though, and I'll have a look tomorrow |
| 01:14:44 | KittenKat | thanks, i just need to eat... been coding all damn day. but i'm sure you know how that is |
| 01:14:51 | KittenKat | yay for stirfry in a bag |
| 01:17:48 | JdGordon| | amiconn: the buttonbar... am I going to get strife if it gets removed? |
| 01:18:02 | | Quit notlistening ("Leaving") |
| 01:18:11 | amiconn | yes |
| 01:19:08 | JdGordon| | arg... why? |
| 01:19:42 | amiconn | Ahem, it is an established and helpful feature of rockbox? |
| 01:20:01 | amiconn | Imo viewports should make it significantly easier to implement the button bar, even using the user font (i.e. variable height) |
| 01:20:35 | Llorean | 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 | amiconn | Those buttons have *no* labels, and are meant to change meaning. Other buttons are usually close in function to their labels |
| 01:22:12 | JdGordon| | amiconn: if they were *always* disaplayed then that would make things much easier |
| 01:22:16 | JdGordon| | but they arnt... |
| 01:22:52 | amiconn | Why would that make things easier? |
| 01:22:55 | Llorean | 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 | JdGordon| | amiconn: have you seen my viewport dev-ml email? |
| 01:24:12 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 01:24:41 | amiconn | There are other potential targets with soft buttons. It's also a common feature of many mobile devices |
| 01:24:58 | wincent | Does anybody know how to convert a float to it's string representation? |
| 01:25:09 | JdGordon| | can you give that email a quick read? I'll reconnect in about 10min... heading home |
| 01:25:25 | JdGordon| | I would be very happy to force them always on the screen if they are enabled |
| 01:25:34 | amiconn | ? |
| 01:25:38 | JdGordon| | but toherwise i'm going to push for them to be totally removed |
| 01:25:45 | JdGordon| | back in 10 |
| 01:25:55 | | Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 01:26:12 | Hillshum | Wouldn't this solve the support issue with configurable buttons? |
| 01:26:28 | Llorean | Hillshum: What? |
| 01:26:34 | Llorean | This has nothing to do with configurable buttons. |
| 01:26:49 | amiconn | 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 | pixelma | also - no, thinking about blind users etc. |
| 01:27:09 | Llorean | amiconn: So why not just expect people to learn what they do like any other buttons? |
| 01:27:25 | Llorean | We have plenty of buttons with ambiguous uses on many screens. |
| 01:27:30 | amiconn | Why give up a feature that is already there, and can be kept easily? |
| 01:27:51 | rasher | pixelma: surely whether or not the button bar is there is completely irrelevant to blind users? |
| 01:27:52 | amiconn | ...and which makes sense? |
| 01:28:02 | Llorean | 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 | amiconn | Why rework things which work? |
| 01:28:20 | Hillshum | 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 | Llorean | amiconn: Did you read JdGordon's email? |
| 01:28:50 | Llorean | Hillshum: It doesn't show what every button does. It's a specific feature for three buttons on a specific target. |
| 01:28:59 | amiconn | Llorean: Other buttons aren't aligned in a way that allows easy display of their function. |
| 01:29:23 | pixelma | 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 | Llorean | 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 | amiconn | 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 | amiconn | Imo that deserves a clear *no*. |
| 01:33:36 | rasher | So in this case we do want to mimick the OF? |
| 01:33:39 | * | rasher is confused |
| 01:33:39 | amiconn | 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 | amiconn | 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 | amiconn | Why would the button bar be not part of the ui? It clearly is a logical part of the ui... |
| 01:35:22 | Llorean | The graphical button bar and the physical buttons are two different things |
| 01:35:28 | Llorean | The physical buttons are still a part of the UI either way. |
| 01:35:46 | Llorean | 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 | amiconn | The button bar shows what functions the softkeys has *in this screen*, so it's clearly related |
| 01:36:10 | amiconn | s/has/have/ |
| 01:36:32 | amiconn | Llorean: It's not *expected*, it's a choice |
| 01:36:48 | Llorean | 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 | Llorean | 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 | amiconn | It's not one target, it's three. And there are more potential targets |
| 01:37:39 | Hillshum | visual effect plus ease-of-use |
| 01:37:49 | rasher | It's a limited amount of users. |
| 01:37:52 | | Join JdGordon| [0] (i=4600bada@rockbox/developer/JdGordon) |
| 01:37:52 | Llorean | amiconn: How many of these targets have the buttons positioned properly, as you mentioned? |
| 01:38:23 | amiconn | And if you're talking about visual effects - viewported lists are much more *only* visual effect than the button bar is |
| 01:38:29 | Llorean | And what are these three targets? I thought it was just the Recorder line? |
| 01:38:40 | amiconn | Yes, and there are three recorders |
| 01:38:55 | * | Hillshum isn't sure if that counts as three targets |
| 01:39:04 | JdGordon| | the BB could be usable on a few more targets, but not perfect like on the recs |
| 01:39:06 | amiconn | E.g. the AV3xx also has buttons like this (although to the right instead at the bottom) |
| 01:39:10 | Llorean | We still consider the iPod 5G "one target" when it needs two different builds. |
| 01:39:18 | Llorean | And the AV3xxx is not a realistic future target at this point, is it? |
| 01:39:47 | amiconn | As I see it, the button bar and a touchscreen ui are somewhat similar |
| 01:39:49 | rasher | And having it to the right just means it's not really going to be the same thing at all |
| 01:40:23 | Llorean | amiconn: So reimplement the button bar using the touchscreen stuff after the change then? |
| 01:40:25 | KittenKat | so, there is a build for the 5g at somepoint in the distant future? |
| 01:40:33 | Llorean | KittenKat: 5G what? |
| 01:40:40 | amiconn | 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 | amiconn | 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 | pixelma | 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 | KittenKat | ipod |
| 01:42:26 | Llorean | 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 | Llorean | KittenKat: The iPod Video has been supported for ages. |
| 01:42:36 | amiconn | And? |
| 01:43:00 | Llorean | amiconn: So their "similarity" is what, exactly, other than possibly looking similar? |
| 01:43:01 | amiconn | That was just one example - of course a touchable button bar could work in other screens too |
| 01:43:32 | JdGordon| | <amiconn> 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 | amiconn | Uh, why that? |
| 01:43:56 | Llorean | 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 | JdGordon| | because it will be up to the user |
| 01:44:06 | KittenKat | Llorean i thought the ipod video is 4g |
| 01:44:17 | KittenKat | the new 120gb ipods are 5g no? |
| 01:44:24 | Llorean | 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 | Llorean | The new 120GB iPods are the sixth generation. |
| 01:44:34 | | Join Hillshum_ [0] (n=chatzill@unaffiliated/hillshum) |
| 01:44:38 | KittenKat | damn my bad |
| 01:44:48 | KittenKat | so is a ipod 6g build in the works? |
| 01:44:51 | Llorean | No. |
| 01:44:58 | KittenKat | why not? |
| 01:45:12 | Llorean | 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 | Hillshum | Llorean: 120gb is actually 7th gen |
| 01:45:27 | Llorean | KittenKat: Or haven't been able to solve the problems. |
| 01:45:31 | KittenKat | *nods* |
| 01:45:40 | Llorean | Hillshum: Oh really? They use different firmware and have different hardware beyond the HD? |
| 01:46:13 | Hillshum | Llorean: Sorry, I was just assuming |
| 01:46:13 | JdGordon| | 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 | Llorean | amiconn: But we're not giving up functionality for cosmetics. We're giving up cosmetics for other cosmetics. |
| 01:46:31 | Llorean | Hillshum: Please, PLEASE don't make random assumptions like that in here. People read these logs and repeat them elsewhere. |
| 01:46:34 | JdGordon| | amiconn: which is why im happy to force the bar always on or always off instead |
| 01:46:38 | amiconn | The button bar is not just cosmetics |
| 01:47:25 | Llorean | amiconn: As much as what list viewports can become will be. |
| 01:47:26 | amiconn | 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 | amiconn | 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 | KittenKat | god non standard connectors piss me off *looks for the ipod and c200 cable* |
| 01:48:01 | Llorean | 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 | JdGordon| | 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 | amiconn | 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 | amiconn | And I don't understand why the option is problematic |
| 01:50:05 | Llorean | 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 | amiconn | 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 | JdGordon| | 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 | amiconn | 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 | JdGordon| | so either its= needs to be static, or removed |
| 01:51:32 | JdGordon| | or stay broken |
| 01:52:16 | amiconn | It doesn't show up whenever it wants. It shows up in all screens it is attached to, if enabled |
| 01:52:41 | JdGordon| | right... it needs to be *all*( screens, or none |
| 01:52:53 | amiconn | That doesn't make sense |
| 01:53:20 | amiconn | And if your design is not flexible enough, something is wrong with that design |
| 01:53:31 | amiconn | Sorry to say that |
| 01:53:38 | JdGordon| | no, the feature is broken |
| 01:53:45 | JdGordon| | the new design is fine |
| 01:53:56 | amiconn | It's not broken atm, at least not that I know of |
| 01:54:00 | JdGordon| | 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 | JdGordon| | where? |
| 01:55:52 | Mikachu | 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 | JdGordon| | which shold simplify things a bit |
| 01:58:59 | pixelma | I guess then you'll notice |
| 01:59:22 | JdGordon| | notice what? |
| 01:59:39 | JdGordon| | umm... add a "if enabled" somewhere |
| 02:00 |
| 02:01:14 | pixelma | that makes a difference |
| 02:03:31 | amiconn | Forcing it always is a big no-no either |
| 02:03:37 | * | JdGordon| back in 10 |
| 02:04:04 | amiconn | Besides, if your ui area doesn't go to the bottom (minus button bar), what would be around it? |
| 02:05:06 | rasher | Nothing, I assume? |
| 02:05:06 | pixelma | if I understabd the description correctly, either nothing or parts of the WPS |
| 02:05:10 | rasher | The backdrop.. |
| 02:05:24 | pixelma | understand too |
| 02:06:00 | Llorean | 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 | amiconn | 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 | JdGordon | which is why I'm going to be happy leaving it in a tehcnially broken state |
| 02:14:14 | amiconn | ? |
| 02:14:34 | amiconn | I mean the area around your 'ui' area, not the button bar |
| 02:14:49 | JdGordon | 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 | JdGordon | you know what the answer there is going to be... |
| 02:17:01 | amiconn | 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 | KittenKat | so is gevaerts a coder for the project? |
| 02:17:38 | | Part robin0800 ("Leaving") |
| 02:19:58 | Hillshum | KittenKat: yes |
| 02:21:15 | KittenKat | *nods* |
| 02:21:25 | KittenKat | think i figured out the c200 problem i'm having |
| 02:21:37 | KittenKat | rockbox reports a different product id vs the standard firmware |
| 02:21:39 | KittenKat | http://pastebin.com/m19e4bdae |
| 02:22:28 | KittenKat | now to find the source download ^.^ |
| 02:22:29 | rasher | KittenKat: hm, that's the pid of a c200 in MTP mode.. |
| 02:23:06 | KittenKat | it's set to MSC in the factory firmware |
| 02:23:11 | JdGordon | 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 | KittenKat | rasher: which one the working or non working pid? |
| 02:25:14 | rasher | KittenKat: the non-working one |
| 02:25:34 | KittenKat | rasher i thought that rockbox is alawys in MSC mode |
| 02:25:35 | rasher | 0781:7450 = C200 in MTP mode |
| 02:25:55 | rasher | 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 | Mikachu | the question is why the pid would matter when it's a standard ums device? |
| 02:26:05 | rasher | and 7450 is what the OF reports when in MTP mode |
| 02:26:19 | rasher | Mikachu: well it shouldn't |
| 02:26:51 | rasher | Looks like it was misreported in the DeviceDetection wiki page |
| 02:27:04 | KittenKat | 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 | pixelma | it does |
| 02:28:02 | rasher | 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 | KittenKat | in the oe firmware it works good |
| 02:28:08 | pixelma | at least OF in MSC gets a differnt PID than OF in MTP mode |
| 02:28:23 | KittenKat | works well* |
| 02:28:25 | rasher | pixelma: and Rockbox appears to be using the MTP one |
| 02:28:31 | KittenKat | damn i'm sleepy again |
| 02:28:33 | Mikachu | i doubt linux would care about this though |
| 02:28:48 | rasher | Which *shouldn't* matter, but hal could be basing its decision on the pid |
| 02:28:51 | Llorean | 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 | pixelma | unless it's the Ubuntu bug |
| 02:29:08 | rasher | Llorean: Certainly. |
| 02:29:09 | Llorean | It sounds like it's just a variant of the ubuntu bug |
| 02:29:11 | pixelma | or hal |
| 02:29:15 | Mikachu | technically there could be both an ums endpoint and an mtp endpoint on it, right? |
| 02:29:21 | Llorean | 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 | rasher | 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 | KittenKat | 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 | KittenKat | should be a simple single line of code change on the rockbox end |
| 02:30:56 | pixelma | 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 | rasher | pixelma: If I were to find a pid for the c200, I'd look there.. |
| 02:32:03 | pixelma | well, just thought gevaerts had an c200 himself and would have checked but yeah, there's a chance it explains it |
| 02:32:22 | Llorean | 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 | rasher | pixelma: It was added by zagor it seems |
| 02:32:53 | rasher | pixelma: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=15758 |
| 02:32:55 | Llorean | In many cases we're going to have to use PIDs that are normally used for MTP devices as UMS devices |
| 02:33:00 | Llorean | For example, the Gigabeat S |
| 02:33:08 | Llorean | We can't solve the problem there, and we're doing nothing wrong n the first place. |
| 02:33:19 | pixelma | rasher: ah, and Zagor also put the wrong ones on the wiki page |
| 02:33:37 | Llorean | So, yeah, who dropped the ball kinda does matter in the longer term |
| 02:33:49 | rasher | 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 | Llorean | rasher: Yeah, it should be fixed. |
| 02:34:08 | KittenKat | 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 | Llorean | But whatever's doing the detection based on PID really needs to be identified. |
| 02:34:17 | pixelma | was the problem only reported for c200s or also e200s? |
| 02:34:19 | Llorean | KittenKat: Our firmware doesn't report incorrectly |
| 02:34:28 | Llorean | KittenKat: PIDs identify hardware, not capabilities. So, the PID is 100% correct. |
| 02:34:29 | CIA-69 | New commit by rasher (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 | rasher | pixelma: also e200s I believe |
| 02:34:59 | KittenKat | *shrugs* |
| 02:35:09 | Llorean | KittenKat: You complaining to the other people as well, or just us? |
| 02:35:22 | KittenKat | i'm complaining to the hal ppl also |
| 02:35:56 | rasher | 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 | KittenKat | i think it's a hal problem |
| 02:36:19 | KittenKat | it's kinda a 2 part problem |
| 02:36:34 | Llorean | 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 | rasher | It's not a 2 part problem at all. |
| 02:37:21 | rasher | HAL is not using the proper mechanisms to check the capabilities of the device. That's all there is to it. |
| 02:37:49 | KittenKat | rasher OE firmware works fine |
| 02:37:53 | | Join dmb_ [0] (n=dmb@ool-4573a3fb.dyn.optonline.net) |
| 02:37:53 | KittenKat | rasher Rockbox firmware dosent |
| 02:38:00 | Llorean | That doesn't mean it's our problem. |
| 02:38:02 | | Quit dmb (Client Quit) |
| 02:38:22 | rasher | KittenKat: Because HAL is tweaked to expect what the OF does based on *the wrong metrics* |
| 02:38:37 | Llorean | 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 | KittenKat | 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 | rasher | KittenKat: it's not an "mtp pid". It's a pid belonging to that device |
| 02:39:02 | KittenKat | your firmware should follow the OE pid shit |
| 02:39:12 | rasher | KittenKat: There's no rule at all saying we should |
| 02:39:17 | KittenKat | so non patched computers work fine, hal should fix their shit |
| 02:39:20 | rasher | The bug is in HAL. Squarely. |
| 02:39:32 | pixelma | it doesn't anymore - and it would be even allowed to use the same |
| 02:39:53 | Llorean | 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 | KittenKat | 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 | KittenKat | i expect hal to be broken for a while |
| 02:40:50 | rasher | That doesn't mean there is *any sort of problem* |
| 02:41:00 | Llorean | KittenKat: We shouldn't introduce a bug to fix someone else's bug. |
| 02:41:12 | KittenKat | *shrugs* |
| 02:41:26 | KittenKat | you guys should be doctors lol |
| 02:41:39 | linuxstb | Llorean: Why is it a bug for us to use the same PID as the OF in UMS mode? |
| 02:42:02 | Llorean | linuxstb: No, it's a bug for us to code around this behaviour in other cases though. |
| 02:42:15 | KittenKat | linuxstb because it's not their "problem" |
| 02:42:34 | Mikachu | linuxstb: "<Llorean> [...] 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 | linuxstb | Llorean: Are we talking about other cases? |
| 02:42:42 | linuxstb | Mikachu: Yes, I know that. |
| 02:42:52 | Llorean | linuxstb: KittenKat seems to suggest the goal should be "make it work no matter what" |
| 02:42:55 | rasher | Mikachu: Please see if http://build.rockbox.org/dist/build-sansac200/rockbox.zip "fixes" your issue |
| 02:43:01 | Mikachu | rasher: wrong nick :) |
| 02:43:05 | rasher | er |
| 02:43:12 | rasher | KittenKat: Please see if http://build.rockbox.org/dist/build-sansac200/rockbox.zip "fixes" your issue |
| 02:43:18 | linuxstb | 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 | rasher | If it does, rain hellfire on the HAL people |
| 02:43:27 | linuxstb | s/USB/UMS/ |
| 02:44:13 | * | linuxstb sees rasher's commit, so doesn't know what we're all arguing about... |
| 02:46:23 | pixelma | 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 | rasher | 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 | rasher | Not sure if that's speculation though |
| 02:47:17 | pixelma | magic mode? |
| 02:47:19 | Mikachu | hal or not, can't you always just mount the device in /dev manually? |
| 02:47:40 | rasher | pixelma: mtp/msc autodetect shenanigans |
| 02:47:56 | linuxstb | Mikachu: Isn't the point that you only get a disk device in /dev if it's been detected as UMS? |
| 02:48:12 | Mikachu | 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 | Mikachu | 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 | pixelma | rasher: the MTP mode in the c200 OF is called "autodetect" as well... |
| 02:49:25 | rasher | 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 | KittenKat | btw i'm chewing out hal now |
| 02:51:06 | Mikachu | if you're mentioning rockbox in the report, try to keep it civil :) |
| 02:51:13 | KittenKat | Mikachu every attempt to mount it manually failed |
| 02:51:30 | Mikachu | KittenKat: did it work with the new build that has the other pid? |
| 02:51:34 | KittenKat | yup |
| 02:51:37 | KittenKat | like a charm |
| 02:51:37 | obo | pixelma: It's Autodetect vs MSC on my c250 |
| 02:51:50 | KittenKat | auto mounts, manually mounts, etc |
| 02:52:20 | obo | pixelma: oops, misread you, sorry |
| 02:52:31 | pixelma | that's what I meant |
| 02:53:49 | KittenKat | thanks rasher :) |
| 02:57:10 | KittenKat | 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 | rasher | KittenKat: is there a bugreport we can follow? |
| 03:00 |
| 03:00:01 | KittenKat | i'm tryin to find a non distro specific but report page for HAL |
| 03:01:53 | rasher | KittenKat: https://bugs.freedesktop.org/ |
| 03:02:02 | Mikachu | https://bugs.freedesktop.org/enter_bug.cgi?product=hal |
| 03:02:04 | Mikachu | oops |
| 03:02:13 | rasher | Yours was better |
| 03:02:22 | tmzt | does mtp have assigned protocol numbers? |
| 03:02:51 | KittenKat | good god what is it with invalid security certs |
| 03:02:56 | * | KittenKat adds an exception |
| 03:03:06 | tmzt | 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 | pixelma | 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 | tmzt | since we are stuck with native vid/pid |
| 03:03:55 | | Quit barrywardell () |
| 03:04:12 | tmzt | rockbox does not currently use mtp at all right? (at least on sansas) |
| 03:04:46 | KittenKat | 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 | KittenKat | 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 | pixelma | 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 | KittenKat | pixelma it's not the only mp3 player i've had with poor output power |
| 03:06:49 | KittenKat | that's why people sell headphone amps for quite a bit of money |
| 03:07:09 | KittenKat | 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 | rasher | https://bugs.freedesktop.org/show_bug.cgi?id=20717 is not terribly promising of HAL's willingness to work with us |
| 03:23:03 | KittenKat | 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 | Mikachu | KittenKat: it wasn't for you, it's changed in svn :) |
| 03:24:10 | KittenKat | really? |
| 03:24:19 | rasher | 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 | Mikachu | not only for you, anyway |
| 03:27:03 | rasher | Man, I've not missed wrasslin' with Bojira |
| 03:27:07 | Llorean | 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 | rasher | Llorean: Sure, but hal also puts hints like supported audio formats etc for programs |
| 03:28:46 | Llorean | Well, we can decline to provide that package but still at least expect it to honor UMS, right? |
| 03:29:12 | rasher | It certainly should |
| 03:29:15 | Llorean | If their project wants to provide information, fine, whatever, but it shouldn't get in the way of standard USB stuff. |
| 03:29:24 | KittenKat | 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 | KittenKat | 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:00 |
| 04:18:53 | CIA-69 | New commit by lowlight (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:00 |
| 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 | JdGordon | from a quick glance playback.c looks like its interaction with playlist isnt *too* bad... |
| 05:57:16 | JdGordon | well.. better than I thought I remembered |
| 06:00 |
| 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 | CIA-69 | New commit by FlynDice (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:00 |
| 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:00 |
| 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 | padd1 | hi guys |
| 08:18:02 | padd1 | Just thought I'd alert some of you to my project |
| 08:18:09 | padd1 | It's cracking the 6g |
| 08:18:32 | padd1 | the page for now can be found at http://www.ipodwizard.net/showthread.php?t=46206&page=8 |
| 08:18:43 | padd1 | Any help would be appreciated |
| 08:23:13 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 08:23:50 | markun | padd1: what's the CPU? Is powered by the S5L8700 by any chance? |
| 08:24:17 | padd1 | hmm... let me check |
| 08:26:33 | | Quit ForumJunkie () |
| 08:29:20 | markun | padd1: when I google I just see that it's ARM based and made by Samsung |
| 08:29:34 | padd1 | cool thanks |
| 08:29:36 | padd1 | yeah |
| 08:29:52 | padd1 | basically, the project doesn't need this though |
| 08:29:58 | padd1 | the idea is not to find holes |
| 08:30:05 | padd1 | we've searched hard for this |
| 08:30:12 | padd1 | and come up with nothing |
| 08:30:13 | markun | what are you trying to do then? |
| 08:30:16 | padd1 | due to lack of devs |
| 08:30:23 | padd1 | so, we are trying to brute force |
| 08:30:32 | padd1 | to guess the encryption key |
| 08:30:51 | padd1 | and, we link computers together to form a sort of supercomputer |
| 08:30:54 | markun | what is the goal of the project? |
| 08:30:57 | padd1 | like a web of computers |
| 08:31:02 | padd1 | spitting out tonnes |
| 08:31:08 | padd1 | then, we crack the 6g |
| 08:31:15 | padd1 | we have hold of the firmware |
| 08:31:29 | padd1 | we can do whatever eg rockbox |
| 08:32:04 | markun | well, if you want to port rockbox it's nice to at least know what CPU it is using. |
| 08:32:29 | markun | 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 | padd1 | 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 | funman | 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 | padd1 | no |
| 08:55:36 | padd1 | we think either 128 |
| 08:55:42 | padd1 | or 256 |
| 08:55:49 | GodEater | 128/256 what ? |
| 08:55:54 | padd1 | we plan to get an old 6g and dump the ram and take it apart |
| 08:55:56 | padd1 | to find out |
| 08:56:00 | padd1 | oh bit |
| 08:56:15 | GodEater | AES / Blowfish / Twofish ? |
| 08:56:29 | GodEater | <insert other crypto agolorithm of your choice> |
| 08:56:53 | padd1 | hmm |
| 08:57:05 | padd1 | that's what we are dumping the ram to find out |
| 08:57:12 | padd1 | that's the only way, right |
| 08:57:20 | padd1 | but, probs AES |
| 08:57:34 | padd1 | unfortunately, dumping Ram destroys the ipod |
| 08:58:14 | funman | 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 | GodEater | I don't understand how dumping the RAM helps *at all* |
| 08:59:19 | funman | at least giving some strings to be expected in the decrypted firmware, to help bruteforcing |
| 09:00 |
| 09:00:36 | GodEater | 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 | bertrik | FlynDice, how about we simply use adc_read (with has proper locking) to get the core voltage? |
| 09:07:31 | funman | 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 | funman | and r21584 is incorrect anyway |
| 09:08:46 | funman | since the adc input could be changed anytime |
| 09:09:25 | funman | 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 | GodEater | welcome back Zagor. Nice holiday I hope ? |
| 09:12:09 | | Join padd1 [0] (n=patrick@58.167.91.66) |
| 09:12:09 | Zagor | 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 | padd1 | sorry guys |
| 09:12:26 | padd1 | had to reboot |
| 09:12:36 | padd1 | so, how do I determine the algorithm |
| 09:13:08 | funman | padd1: i think that's your job to find out how |
| 09:13:22 | padd1 | lol, do U guys know |
| 09:13:40 | funman | we'd tell you if we knew |
| 09:14:02 | JdGordon | ask the zune linux mob :D |
| 09:14:17 | funman | i would suppose the decryption code is stored somewhere in a ROM |
| 09:14:19 | padd1 | lol |
| 09:14:26 | padd1 | theyve gone so far |
| 09:14:31 | padd1 | yeah |
| 09:14:35 | markun | JdGordon: the unencrypted-frimware-zune? |
| 09:14:39 | padd1 | the way it works |
| 09:14:57 | markun | (I know it's signed) |
| 09:15:23 | padd1 | is why is that the RAM, in update has the key |
| 09:15:29 | padd1 | that is taken from the rom |
| 09:15:40 | padd1 | the rom is too hard to take out |
| 09:16:20 | funman | 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 | funman | well coded* |
| 09:16:33 | markun | you can't take the ROM out if it's inside the CPU (as with the ipod nano 2g) |
| 09:17:11 | GodEater | markun: so what "ROM" did the linux4nano guys dump then ? :) |
| 09:17:33 | markun | GodEater: I thought it was the 1MB firmware flash |
| 09:17:55 | GodEater | markun: could be, I really didn't know :) |
| 09:18:12 | funman | "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 | markun | GodEater: http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=212&partnum=S5L8700 |
| 09:19:40 | markun | "50KB Embedded Boot ROM" |
| 09:19:50 | markun | I assume that's what they would have liked to have |
| 09:20:27 | funman | 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 | funman | still far away from something suitable for rockbox |
| 09:21:12 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 09:22:26 | GodEater | 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 | CIA-69 | New commit by zagor (r21585): Devcon is over |
| 09:38:43 | Zagor | 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 | funman | I found 2 headers which each include the other one. Looks quite ugly to me, is that a common practice? |
| 09:54:41 | funman | 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:00 |
| 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 | funman | I don't understand how the speed is calculated in ata-sd-pp.c card_get_info_target() |
| 10:42:30 | funman | 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 | funman | 3 bits starting from bit 29 (or 125) and 4 bits starting from bit 25 (or 121) |
| 10:46:01 | funman | 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 | GodEater | funman: if you don't get one before, I'll try and get you one from my c200 this evening |
| 10:47:38 | funman | 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 | funman | does 12MBit/s sound like a reasonable transfer speed for SD cards ? |
| 10:54:31 | funman | 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:00 |
| 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 | funman | 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 | funman | 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 | funman | 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 | tmzt | ata is because the driver was historically cf/ide? |
| 11:35:14 | funman | yes |
| 11:35:21 | tmzt | okay |
| 11:35:46 | funman | the files haven't been renamed but that's not a big deal I think |
| 11:37:04 | amiconn | funman: TSAC should be TAAC indeed. It's not a typo, it's a misread on my side it seems |
| 11:37:13 | tmzt | yeah, was just a little confused because mmc is not ata/scsi I think |
| 11:37:34 | funman | amiconn: thanks, I have put this change into my diff |
| 11:37:40 | funman | tmzt: SD neither ;) |
| 11:37:44 | tmzt | somebody from google reported 50mbps for sd card |
| 11:37:56 | tmzt | on msm7k hardware |
| 11:38:13 | funman | 12mbps makes sense then (same order) |
| 11:38:13 | tmzt | not sure how targets' dma compares to that |
| 11:38:18 | amiconn | Conversion from clocks to bytes is SPI specific. The timeout is given in clock cycles, but SPI *always* transfers bytes |
| 11:38:29 | amiconn | So dividing by 8 makes things easier |
| 11:38:32 | tmzt | the interface is 2bit? |
| 11:38:34 | funman | tmzt: 12mbps is what the card reports, not a measurement at all |
| 11:38:47 | tmzt | okay |
| 11:39:11 | tmzt | that was probably 4bit at 46mhz |
| 11:39:40 | funman | 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 | tmzt | though that doesn't seem to add up |
| 11:40:46 | funman | amiconn: well I would think timeout is expressed in time units (clock cycles or seconds) |
| 11:42:31 | amiconn | hmm |
| 11:42:32 | funman | is the timeout dependant on the size of data transferred ? |
| 11:42:46 | funman | in seconds per bits (or bytes) |
| 11:43:18 | | Join mt [0] (n=mt@41.233.147.176) |
| 11:44:14 | funman | since it's only used internally in drivers the unit doesn't need to be precise (SD would use seconds) |
| 11:47:59 | funman | who is Wincent Balin on irc ? |
| 11:48:17 | wincent | Me iz. |
| 11:48:42 | wincent | What do you want to ask me? |
| 11:48:46 | funman | hi ;) could you add yourself to IrcNicks wiki page? |
| 11:48:55 | ForumJunkie | Someone compile me RB with a patch =.= |
| 11:48:59 | funman | I wanted to know which problems you have with pdbox makefile |
| 11:49:28 | wincent | The .c files seem not to depend on plugin.h while they should. |
| 11:51:13 | funman | did you look at make.dep ? |
| 11:51:46 | wincent | Yes, and it confirmed my suspicions. |
| 11:52:36 | wincent | But nevertheless, I could not find any error in pdbox.make. |
| 11:52:51 | wincent | I modelled it after zxbox.make. |
| 11:52:55 | funman | is plugin.h inside an #ifdef block? perhaps gcc wouldn't include it when generating the dependencies |
| 11:53:07 | funman | and zxbox dependencies are rebuilt fine? |
| 11:53:45 | wincent | Yes, I saw after some updates of plugin.h that zxbox was recompiled completely and pdbox was relinked only. |
| 11:54:33 | wincent | And yes, #include "plugin.h" is everywhere in #ifdef ROCKBOX ... #endif . |
| 11:55:29 | funman | Zagor: mkdepfile should use gcc -DROCKBOX then ? |
| 11:55:55 | funman | PPCFLAGS should include -DROCKBOX rather |
| 12:00 |
| 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 | CIA-69 | New commit by funman (r21586): Merge tCardInfo struct (MMC) and tSDCardInfo struct (SD) ... |
| 12:18:42 | wincent | 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 | pondlife | 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 | pondlife | I'd guess it should always be an action |
| 12:19:48 | | Quit martian67_ (SendQ exceeded) |
| 12:21:04 | CIA-69 | New commit by mcuelenaere (r21587): Also cleanup Onda VX747 ata-sd-target.h file |
| 12:24:55 | funman | mcuelenaere: oops i missed that one |
| 12:25:08 | mcuelenaere | 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 | funman | pretty big binsize increase on my last commit .. i'll check why |
| 12:41:24 | funman | 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 | CIA-69 | New commit by mcuelenaere (r21588): Add (better IMO) alternative for utils/analyis/objdiff.py (taken from Linux kernel, scripts/bloat-o-meter.py) |
| 12:42:11 | funman | mcuelenaere: wow you are fast to help me ;) |
| 12:42:24 | mcuelenaere | heh, just timing coincidence :) |
| 12:44:04 | funman | sd_mantissa takes 800 bytes instead of the previous 16, and sd_exponent 320 bytes instead of 40 .. |
| 12:45:02 | funman | I was hoping gcc wouldn't embed it in each file using it |
| 12:45:30 | funman | looking at the elf file I only see 1 instance |
| 12:46:23 | funman | hum no, I see several instances |
| 12:47:42 | funman | 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 | mcuelenaere | funman: I've been thinking of doing that too (also creating and managing the SD thread there) |
| 12:52:07 | mcuelenaere | and creating some kind of general SD interface to communicate with the target driver |
| 13:00 |
| 13:11:18 | | Join barrywardell [0] (n=barrywar@79.97.85.223) |
| 13:17:08 | funman | I can't use card_extract_bits() .. |
| 13:20:25 | funman | yes it's definitely weird |
| 13:21:04 | funman | instead of (p, start_msb, n) I have to use (p, start_msb+1+n, n) |
| 13:22:03 | CIA-69 | New commit by alle (r21589): Provide a context sensitive default file name when saving settings (FS #10399) |
| 13:26:54 | funman | amiconn: what were you sinking about in r5193? the extracted bits do not match with the MMC spec |
| 13:29:18 | funman | 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 | funman | r5192: speed = mantissa[mmc_extract_bits(csd, 25, 4)] * .. |
| 13:29:59 | funman | I do not see a relation between starting bit 102 and starting bit 25 .. |
| 13:34:34 | funman | 25 = 127 - 102 though |
| 13:36:41 | funman | amiconn: ideally extract_bits would use the bits position printed in the specification. |
| 13:37:25 | funman | 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 | amiconn | SH1 is big endian, and the function works properly on that |
| 13:42:18 | amiconn | Yes, it counts from the other end |
| 13:42:26 | funman | pretty disturbing |
| 13:42:57 | amiconn | There is no consistent documentation. Some datasheets list it this way, some the other way round |
| 13:42:59 | funman | works fine on little endian when the words are in the right order |
| 13:43:24 | funman | the MMC Product Manual from SanDisk says 127 is the msb which seems fine |
| 13:44:35 | funman | 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 | funman | 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 | funman | 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 | funman | reverse the words order |
| 13:47:36 | | Join parafin [0] (i=parafin@paraf.in) |
| 13:49:19 | funman | or add a start = 127 - start in card_extract_bits which seems simpler .. :) |
| 13:56:55 | pondlife | Hmm, my H300 has needed 2 paperclip resets today... |
| 13:57:34 | pondlife | Both times after skipping a track, and apparently showing the "paused" icon. |
| 13:59:24 | pondlife | I think it's also buffering and updating the database. Will reinit the database and try again. |
| 14:00 |
| 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 | CIA-69 | New commit by mcuelenaere (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:00 |
| 15:12:14 | | Quit DarkDefender (Read error: 110 (Connection timed out)) |
| 15:14:29 | funman | 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 | kugel | 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 | CIA-69 | New commit by mcuelenaere (r21591): Onda VX747 bootloader: don't init storage twice |
| 15:56:46 | | Join funman_ [0] (n=fun@rockbox/developer/funman) |
| 15:56:58 | CIA-69 | New commit by mcuelenaere (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 |
| 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 | evert_ | I'm having a strange problem, in 'database' all my music numbers are double in the artist/album/* list :/ |
| 16:03:42 | evert_ | is there any possible fix for this? :) |
| 16:04:09 | Torne | yhou mean all the tracks are appearing in the db twice? |
| 16:04:18 | evert_ | yeah |
| 16:04:20 | FrankTM | or more ;) |
| 16:04:46 | Torne | when did you last initialise/update the db? |
| 16:04:59 | evert_ | very recent, but it didn't solve the problem |
| 16:05:07 | Torne | even reinitialising it from scratch? |
| 16:05:53 | evert_ | database -> initiliaze: now updating in background |
| 16:05:59 | evert_ | 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 | Torne | mount it over usb and delete database*.* from .rockbox :) |
| 16:06:30 | Torne | then shut down and restart, the db will be blank |
| 16:06:36 | evert_ | ok |
| 16:06:48 | Torne | if that doesn't work you have a very interesting bug indeed |
| 16:07:14 | funman | database_tcd.* even |
| 16:07:20 | funman | database.ignore can be useful |
| 16:07:25 | Torne | oh, er, yeah |
| 16:07:29 | rasher | Initialize now should be from scratch. |
| 16:07:47 | Torne | rasher: yah, but evidently *something* isn't working, so i figure it's worth a try |
| 16:08:00 | gevaerts | evert_: which revision are you using? Also, are you sure there's no trash directory or similar on the player? |
| 16:09:02 | funman | double entries in the database do not happen (only) because of trashes directories |
| 16:09:45 | FrankTM | 16:05 < Torne> even reinitialising it from scratch? |
| 16:09:54 | FrankTM | has that bug been fixed ? |
| 16:10:29 | gevaerts | funman: indeed not, but it's one of the options :) |
| 16:10:59 | Torne | 'that bug'? |
| 16:11:00 | | Quit mcuelenaere ("Reboot...") |
| 16:11:18 | FrankTM | Torne: well. the duplicated database entries |
| 16:11:24 | * | Torne was only being paranoid, rather than aware of a particular bug |
| 16:11:34 | FrankTM | ah. alrighty |
| 16:11:42 | funman | it seems that no, i'm not sure a cause have been found |
| 16:12:12 | evert_ | ok, thanks, it seems fixed by deleting the database_tcd* files and then initializing it again :) |
| 16:12:24 | FrankTM | evert_: do you have auto-update enabled? |
| 16:12:43 | evert_ | i think so |
| 16:12:45 | evert_ | normally yes |
| 16:12:47 | rasher | I'm almost willing to bet that it's not just a single bug. Much like "the Firefox memory leak" |
| 16:12:49 | gevaerts | FrankTM: there's been some recent (post 3.3) database work that should make it a lot better |
| 16:13:19 | FrankTM | ah. i'll upgrade tonight then |
| 16:15:35 | Torne | 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 | notlistening | 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 | funman | no, but the screen controller must work right |
| 16:34:50 | funman | would you be able to see the button light for example? |
| 16:36:11 | kugel | I think he he's blind |
| 16:36:20 | kugel | (IIRC) |
| 16:39:41 | CIA-69 | New commit by mcuelenaere (r21593): Onda VX747: clean up bootloader a bit and make sure storage doesn't get init'd twice |
| 16:39:44 | notlistening | not totally blind (just some of the time) the button light yes i can |
| 16:40:42 | notlistening | my concern is the OF going to like it? We will see ;) |
| 16:40:53 | funman | i think it would be the same |
| 16:41:07 | funman | 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 | notlistening | ahh just the OF does not seem to behave quite right but i can not tell at all |
| 16:48:17 | gevaerts | OK. My host spent 54 seconds per gigabeat f build on average in my database. 22 seconds of that is dependencies |
| 16:48:32 | gevaerts | (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 | gevaerts | 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 | gevaerts | 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 | notlistening | wish me luck ;) |
| 16:53:39 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 16:54:53 | notlistening | lights off restart? |
| 16:55:22 | gevaerts | 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 | gevaerts | 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 |
| 17:00:45 | | Quit linuxstb_ (Client Quit) |
| 17:01:48 | | Quit Zagor ("Don't panic") |
| 17:05:09 | notlistening | it failsto boot unsure why no feedback at all ;) |
| 17:06:32 | funman | perhaps not only the screen is broken, can you plug it on usb? |
| 17:07:13 | notlistening | yup, loads then |
| 17:09:42 | notlistening | there is a file called upgrade.fin there |
| 17:10:02 | notlistening | the bootloader is worrking now but it just dies after about 3 seconds |
| 17:12:00 | funman | how do you know it died? |
| 17:12:42 | notlistening | i guess as the screen goes off there is a small light that i can see from the backlight |
| 17:13:19 | funman | might be a sign that rockbox crashed |
| 17:13:46 | notlistening | the OF does the same i think |
| 17:13:50 | | Join {phoenix} [0] (n=dirk@84.180.121.254) |
| 17:15:13 | notlistening | 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 | funman | perhaps you might need the buttons in the future, i keep preciously my dead sansas |
| 17:16:39 | | Part n00b81 ("Leaving") |
| 17:16:57 | FrankTM | sansas. as in multiple? |
| 17:17:09 | notlistening | good idea funman in the rubbish to keep box ;) |
| 17:18:42 | funman | FrankTM: yes, plural |
| 17:21:05 | FrankTM | funman: you bricked them? |
| 17:21:33 | funman | i bricked 2, fried 2, broke 1 |
| 17:22:17 | | Join toffe82 [0] (n=chatzill@74.0.180.178) |
| 17:23:31 | FrankTM | hehe |
| 17:23:39 | FrankTM | 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:00 |
| 18:02:48 | | Join JdGordon| [0] (i=ad7eb975@gateway/web/freenode/x-08d960cfdd148cf3) |
| 18:04:47 | | Quit funman ("free(random());") |
| 18:07:04 | Grahack | early works with the Lua plugin: http://fezzik.free.fr/tmp/lua-grahack.zip any advice welcome |
| 18:07:22 | mcuelenaere | Grahack: (continuing from PM) I don't think I'm the only person to decide over these things |
| 18:09:54 | Grahack | (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 | kugel | what's that |
| 18:12:55 | kugel | ? |
| 18:13:47 | mcuelenaere | 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 | mcuelenaere | it is currently only* |
| 18:14:09 | | Quit petur ("work->home") |
| 18:17:18 | mcuelenaere | Grahack: also, if libtxtdisp depends on actions why don't you require() it in libtxtdisp.lua? |
| 18:18:08 | Grahack | I tried once and it complained. Did you try ? |
| 18:18:45 | Grahack | 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 | mcuelenaere | I don't think there's any Rockbox guidelins regarding Lua scripts :) |
| 18:20:58 | Grahack | 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 | gevaerts | mcuelenaere: there aren't any C specific guidelines either. There just is "Write all code in C." :) |
| 18:32:20 | rasher | gevaerts: docs/CONTRIBUTING? |
| 18:32:59 | gevaerts | yes |
| 18:33:54 | rasher | Those are more specific than "Write all code in C." |
| 18:35:39 | gevaerts | rasher: there's no indication that the rest is C specific! |
| 18:37:14 | mcuelenaere | Grahack: did you actually test those scripts in the sim? |
| 18:37:28 | mcuelenaere | and shouldn't line 19 of test_actions.lua be rb.lcd_clear_display() ? |
| 18:37:47 | mcuelenaere | (also there's no print() defined in Rockbox Lua by default) |
| 18:38:04 | kugel | gevaerts: yea, never typedef in lua too :) |
| 18:38:22 | gevaerts | kugel: also don't make it look like C++! |
| 18:39:32 | kugel | gevaerts: we have a problem with the comments I think |
| 18:40:15 | FlynDice | funman: kugel: re r21584 How's this look ? http://pastie.org/530922 |
| 18:40:33 | gevaerts | kugel: you could redefine the language, but then that's not allowed either :) |
| 18:42:20 | kugel | FlynDice: should work, I assume adc_read(ADC_CVDD) does the job too? |
| 18:42:50 | FlynDice | yes been running for 2 hrs now and no lockups |
| 18:43:20 | kugel | is that dependant on something? |
| 18:43:54 | kugel | 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 | kugel | but as there's no "setting the input" anymore |
| 18:44:52 | kugel | I hope you know what I mean |
| 18:45:35 | FlynDice | 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 | FlynDice | I ran about 1.5 hrs with just adc_read and no disable_irq() with no lockups also |
| 18:46:57 | mcuelenaere | 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 | gevaerts | Any objections to FS #10403? |
| 18:48:05 | JdGordon| | I OBJECT! |
| 18:48:31 | mcuelenaere | 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 | gevaerts | JdGordon|: I meant, from anyone but you :P |
| 18:49:13 | Grahack | 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 | JdGordon| | gevaerts: say what you mean :D |
| 18:50:36 | JdGordon| | 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 | gevaerts | JdGordon|: well, it works now. Adding the rb->playlist_create() was the most important bit |
| 18:51:57 | Torne | gevaerts: that sounds like a good feature, but i havne't looked at the patch |
| 18:52:14 | Torne | i would but i need to leave veyr soon :) |
| 18:53:25 | gevaerts | 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 | JdGordon| | ah yes |
| 18:54:14 | mcuelenaere | Grahack: also don't lcd_update() after lcd_clear_display(), that way it doesn't flicker that much :) |
| 18:54:16 | JdGordon| | and playlist)_create() presumably resets the resume info which was another problem |
| 18:54:26 | mcuelenaere | (when scrolling) |
| 18:54:38 | kugel | FlynDice: disable_irq shouldn't be needed then I guess |
| 18:55:00 | gevaerts | 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 | gevaerts | I then went to look at how pictureflow does this, and stole some code |
| 18:56:10 | kugel | gevaerts: is the playlist stored over a reboot? I was having problems with this while doing this on PF |
| 18:56:34 | kugel | oh, I didn't read your last sentence :P |
| 18:56:44 | kugel | pictureflow uses the tagcache way of building a playlist |
| 18:57:14 | gevaerts | Anyway, this is purely new code so it can't break anything existing, so I think it |
| 18:57:18 | gevaerts | s safe to commit |
| 18:57:24 | JdGordon| | go for it... |
| 18:57:31 | kugel | I OBJECT |
| 18:57:34 | kugel | not :) |
| 18:57:43 | JdGordon| | new features in plugins are almost never contentious |
| 18:57:55 | JdGordon| | *and* you added the manual change! |
| 18:58:00 | JdGordon| | you damned wierdo! |
| 18:58:59 | gevaerts | kugel: it does survive reboots, yes |
| 18:59:32 | | Quit PaulJam (".") |
| 18:59:46 | CIA-69 | New commit by gevaerts (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 |
| 19:00:30 | kugel | gevaerts: wait...oh |
| 19:00:56 | kugel | you aren't really checking the return value, why give it one it the first place? |
| 19:01:15 | gevaerts | kugel: that's the coding style of the file :) |
| 19:01:25 | CIA-69 | New commit by mcuelenaere (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 | kugel | 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 | kugel | and now I guess you want me to finish off the plugin goto wps thing? |
| 19:03:10 | JdGordon| | gevaerts: configured configured? :) |
| 19:03:45 | kugel | I might do that now as there's a second plugin that could use it |
| 19:03:56 | CIA-69 | New commit by mcuelenaere (r21596): Ingenic Jz4740 SD driver: remove some unneeded stuff + fill the OCR field in card_get_info_target() |
| 19:04:01 | kugel | it doesn't require much hacking actually |
| 19:04:15 | gevaerts | 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 | kugel | except if you want to do that from plugins executed from the core's context menu or "open with..." menu |
| 19:05:23 | kugel | the simplelist just isn't able to do that sort of stuff from what I've seen |
| 19:05:28 | gevaerts | well, it's not too urgent. It's just one keypress after all |
| 19:05:32 | Grahack | 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 | Grahack | must leavenow, thanks for everything |
| 19:06:01 | kugel | gevaerts: aren't you running this plugin from the normal filebrowser? |
| 19:06:19 | gevaerts | I am, yes |
| 19:06:19 | | Part Grahack |
| 19:06:41 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 19:06:41 | gevaerts | I was just thinking that your plans for pictureflow may be to not do that |
| 19:06:49 | mcuelenaere | Grahack (logs): libutils.clearscreen() should indeed do lcd_update(), otherwise it wouldn't have the effect the name implies :) |
| 19:07:02 | bertrik | 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 | bertrik | because we can |
| 19:08:10 | mcuelenaere | and besides that? :) |
| 19:08:57 | kugel | gevaerts: no problem from the tag browser too, it's just the simplelist making problems |
| 19:09:02 | kugel | but that might be solved later |
| 19:09:15 | | Join funman_ [0] (n=fun@rockbox/developer/funman) |
| 19:09:17 | gevaerts | ah, ok |
| 19:09:20 | funman_ | FlynDice: yes looks fine |
| 19:09:40 | funman_ | kugel: disable_irq() is required, a tick task might change the adc input |
| 19:09:52 | bertrik | mcuelenaere, no reason really, maybe because everyone else is doing it |
| 19:09:55 | kugel | funman_: ascodec is locked in adc_read |
| 19:10:10 | funman_ | i am not sure mutexes work for tick tasks |
| 19:10:18 | kugel | they should |
| 19:10:25 | kugel | why shouldn't they? |
| 19:10:31 | funman_ | a tick task is not a thread |
| 19:10:37 | funman_ | running in a thread* |
| 19:10:47 | gevaerts | hm, not good |
| 19:11:05 | | Quit funman (Read error: 54 (Connection reset by peer)) |
| 19:11:29 | mcuelenaere | 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 | funman_ | kugel: all code using mutexes in a tick task is wrong |
| 19:11:57 | kugel | I remember someone saying that too, yes |
| 19:12:15 | kugel | and what tick task changes the adc input? |
| 19:12:41 | | Join TheSphinX^ [0] (n=cold@p54A5C57A.dip.t-dialin.net) |
| 19:13:49 | funman_ | the one calling battery_adc_voltage, but in fact it seems to be done in the power thread |
| 19:15:15 | funman_ | then i don't understand why the input was changed at all .. |
| 19:15:42 | kugel | so we don't need to disable irq? |
| 19:16:09 | funman_ | 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 | CIA-69 | New commit by gevaerts (r21597): Assume a smaller plugin binsize, so MAX_SHUFFLE_SIZE actually fits on archos |
| 19:16:51 | bertrik | 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 | funman_ | 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 | funman_ | bertrik: right, bit 0 of IRQ_ENRD_2 |
| 19:18:14 | mcuelenaere | Grahack: do you read the logs? |
| 19:20:23 | kugel | is it possible that ascodec-pp is misnamed? |
| 19:21:01 | funman_ | kugel: if it's the case, ascodec-as3514 as well |
| 19:21:21 | funman_ | where is adc_read() defined for as3514 ? |
| 19:21:25 | kugel | ascodec-pp has nothing to do with ascodec imo |
| 19:21:37 | kugel | adc-as3514.c |
| 19:22:00 | funman_ | hum right |
| 19:22:16 | funman_ | should go in sandisk/audio* |
| 19:22:20 | | Quit barrywardell () |
| 19:23:22 | GodEater | 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 | funman_ | amiconn: anything against http://pastie.org/530998 ? |
| 19:25:00 | kugel | funman_: uhm, we compile adc-as3514.c? it should be renamed also then |
| 19:25:48 | funman_ | kugel: renamed to what? |
| 19:25:54 | bertrik | 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 | kugel | no idea, it's a single function anyway |
| 19:26:23 | kugel | or at least adc-as35xx.c or so |
| 19:26:25 | funman_ | bertrik: hum well the card_extract_bits() function works fine with the 4 32-bit words |
| 19:26:41 | funman_ | kugel: it's specific to as3514 (sansa e200v1 and c200v1 use it) |
| 19:26:57 | Grahack | 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 | funman_ | kugel: and the sd_command() functions use this kind of data array |
| 19:27:20 | funman_ | sorry my last comment was for bertrik |
| 19:27:40 | bertrik | funman_, I wasn't criticising your patch :) |
| 19:27:50 | kugel | funman_: we use it too |
| 19:28:00 | funman_ | bertrik: well i wasn't thinking it's a critic, but your question is interesting |
| 19:28:13 | kugel | adc-ascodec.c is probably a better name |
| 19:28:17 | funman_ | the SD controllers use 32 bits registers so it's easier to copy into a 32bits integer type |
| 19:28:17 | bertrik | I just see no good reason to store it as a couple of 32-bit words |
| 19:28:38 | markun | this looks like pretty good news: http://forums.rockbox.org/index.php?topic=6518.msg152565#msg152565 |
| 19:29:15 | markun | hopefully it will be possible to decrypt, but also to encrypt firmwares for the nano 2g |
| 19:29:38 | saratoga_ | 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 | funman_ | i thought the notes vulnerability was not exploitable |
| 19:30:26 | * | bertrik mumbles something about pudding |
| 19:30:30 | saratoga_ | we'll see what they have soon enough I guess |
| 19:30:35 | markun | saratoga_: that's pretty cool, but then I don't understand why this dump was so difficult |
| 19:30:37 | saratoga_ | 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 | funman_ | 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 | kugel | the pp ascodec seems to yield indeed |
| 19:31:31 | markun | bertrik: I'll try to get you another S5L8700 target soon then :) |
| 19:31:51 | markun | (the M6SL in case you tink I have a nano for you..) |
| 19:32:09 | bertrik | 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 | LambdaCalculus37 | 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 | markun | hm, this doesn't look so good: https://mail.gna.org/public/linux4nano-dev/2009-07/msg00008.html |
| 19:35:56 | funman | 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 | mcuelenaere | IRC logs* |
| 19:36:23 | markun | or are they talking about their own writig and not the dump? |
| 19:37:17 | LambdaCalculus37 | mcuelenaere: That sounds a little fishy if you ask me. |
| 19:37:33 | mcuelenaere | LambdaCalculus37: probably just because the dump is there |
| 19:37:51 | LambdaCalculus37 | mcuelenaere: And I want to see that dump! :) |
| 19:38:07 | LambdaCalculus37 | Maybe we can finally figure out how to get something running on the 2nd gen nano! |
| 19:38:14 | LambdaCalculus37 | And we should get bertrik one, too! :P |
| 19:38:50 | funman | for the goodness of Sansa AMS port, NO ! |
| 19:39:07 | GodEater | 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 | rasher | mcuelenaere: they're freakishly paranoid |
| 19:41:44 | mcuelenaere | why that? like Apple is going to sue individual persons for just a ROM dump.. |
| 19:41:58 | GodEater | and on a 2 generations old model |
| 19:43:33 | rasher | mcuelenaere: that's why I say "freakishly" |
| 19:44:29 | Mikachu | if they live in the us i can understand :) |
| 19:44:55 | saratoga_ | 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 | saratoga_ | the Ipod2G and Mezui players have the same SOC right? |
| 19:47:41 | LambdaCalculus37 | Yep. |
| 19:48:05 | LambdaCalculus37 | 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 | kugel | saratoga_: nano 2G |
| 19:49:06 | kugel | ipod 2G is something different :/ |
| 19:49:44 | funman | 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 | FlynDice | funman: because there were no problems without the voltage reading code, about 3 battery benches worth... |
| 19:52:33 | funman | FlynDice: perhaps the adc input is reset after a read |
| 19:52:54 | funman | I had understood 'changed' as in changed by our software, not by the as3514 chip |
| 19:54:06 | FlynDice | 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 | FlynDice | and when I remmoved the loop the problems disappeared |
| 19:55:24 | FlynDice | so my guess was that something else was changing the input. I addressed that problem and there were no more lockups. |
| 19:55:49 | FlynDice | gotta go for a few hours, be back later |
| 19:56:28 | funman | see you |
| 19:56:36 | funman | we should check what the input is reset to |
| 20:00 |
| 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 | JdGordon| | 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 | gevaerts | 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 | JdGordon| | it probably wont make much difference, but its nice to use the whole buffer so people can have massive lists |
| 20:30:38 | JdGordon| | that is possibly happening in rfa.rock already |
| 20:31:33 | gevaerts | it won't make much difference, but it's break-proof |
| 20:32:08 | JdGordon| | as long as you dont break the needed maths :) |
| 20:32:48 | * | gevaerts can divide by sizeof(int), tyvm :) |
| 20:33:37 | JdGordon| | 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 | CIA-69 | New commit by gevaerts (r21598): Remove the static order[] allocation in favour of plugin_get_buffer() |
| 20:43:40 | gevaerts | JdGordon|: on 512k plugin buffer targets, you have room for about 125k directories. I'm pretty sure that's plenty :) |
| 20:44:05 | JdGordon| | careful with those sort of statements |
| 20:44:57 | JdGordon| | and you dont anyway... unless they all take up 0 bytes? |
| 20:45:18 | gevaerts | lowmem targets will have to make do with 6977 folders |
| 20:46:02 | JdGordon| | hmm... you're using the plugin buffer for the order array and the audio buffer for the folder name buffer? |
| 20:46:07 | gevaerts | JdGordon|: I allocate an array of ints, and shuffle that. The list of directories is actually in the audio buffer |
| 20:46:15 | JdGordon| | snap! |
| 20:46:22 | JdGordon| | right, yeah that should be sweet |
| 20:46:45 | gevaerts | 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 | CIA-69 | New commit by gevaerts (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 | gevaerts | 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 | JdGordon| | wouldnt they hit some FAT |
| 20:55:56 | JdGordon| | umm.. |
| 20:56:04 | JdGordon| | fat limitation first on the small disk? |
| 20:56:19 | rasher | JdGordon|: archos disks can be giant |
| 20:57:53 | gevaerts | hm, the actual limit for random folder advance itself is probably smaller (+-4000 if the audio buffer is 1M) |
| 21:00 |
| 21:02:35 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 21:04:04 | gevaerts | 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 | kugel | pretty close already |
| 21:04:55 | kugel | just grab dbestfit from PDa and use malloc :p |
| 21:05:06 | gevaerts | yes, but they're probably not going to make new bigger PATA disks |
| 21:06:16 | gevaerts | Anyway, I've never heard complaints from people who hit that limit |
| 21:06:20 | kugel | and 100MB is pretty much for an album |
| 21:06:32 | JdGordon| | but we shouldnt go out of our way to set artificial limitis |
| 21:06:35 | BryanJacobs | but they could make bigger flash drives, and there are flash->PATA adapters :-P |
| 21:06:42 | BryanJacobs | kugel: not if it's FLAC |
| 21:06:57 | kugel | BryanJacobs: he's assuming 192kbit/s |
| 21:07:14 | BryanJacobs | 192k MP3s are like 1.5MB/min, no? |
| 21:07:25 | funman | 95% of my albums are less than 100MB |
| 21:07:41 | amiconn | All limits in rockbox are tradeoffs, and those which have a significant impact on memory usage are therefore configurable |
| 21:07:44 | BryanJacobs | my whole music collection fits in 12GB if I convert to MP3 |
| 21:07:51 | Mikachu | BryanJacobs: 1.37 |
| 21:08:01 | gevaerts | 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 | kugel | gevaerts: that's what pf is doing |
| 21:08:18 | BryanJacobs | Mikachu: I was pretty close :-P |
| 21:08:18 | funman | amiconn: (sorry for repeating) anything against http://pastie.org/530998 ? |
| 21:08:24 | gevaerts | funman: how big are they on average? |
| 21:08:52 | kugel | you might want to look into that (unless you feel comfortable with that high limit, which sounds reasonable) |
| 21:09:05 | amiconn | funman: Not really, but I don't see the necessity. |
| 21:09:18 | gevaerts | kugel: it's an old limit. I'm not very bothered by it, as long as what I |
| 21:09:26 | amiconn | The extra calculation is small though. Btw, did you try replacing / with >> and % with & ? |
| 21:09:27 | gevaerts | 'm doing doesn't decrease it :) |
| 21:09:28 | funman | amiconn: consistency with docs and established bit order |
| 21:09:37 | amiconn | Sometimes gcc is too dumb to even optimise that |
| 21:09:37 | funman | no i didn't touch the function |
| 21:09:57 | funman | it's not very important, only called at card init / or in debug menu |
| 21:10:13 | amiconn | binsize... |
| 21:10:23 | funman | to save 3 instructions ? |
| 21:10:34 | kugel | clearly even 12bytes are important |
| 21:10:43 | | Quit __lifeless (Read error: 60 (Operation timed out)) |
| 21:10:47 | amiconn | Well, in this cases gcc *should* manage, as the involved variables are unsigned |
| 21:10:48 | kugel | but, if it's trivial, why not |
| 21:11:01 | funman | gevaerts: 61.6MB |
| 21:11:03 | amiconn | In case of signed division it's not just 3 instructions |
| 21:11:24 | gevaerts | funman: ok. You need a 250GB disk to hit the limit then :) |
| 21:11:32 | kugel | you can get that! |
| 21:11:35 | funman | well i didn't look at binsize |
| 21:11:44 | BryanJacobs | x / y != x >> log2(y) |
| 21:11:55 | BryanJacobs | similiar but not exact for corner cases |
| 21:12:01 | kugel | 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 | gevaerts | kugel: I don't think that will really help actually. We're already using the entire audio buffer |
| 21:12:39 | kugel | wincent: ping |
| 21:12:41 | amiconn | BryanJacobs: For positive results and y being a power of two it is, but not if the result is negative |
| 21:12:51 | BryanJacobs | amiconn: like I said... |
| 21:12:57 | kugel | gevaerts: you don't need MAX_PATH per directory |
| 21:13:04 | CIA-69 | New commit by funman (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 | amiconn | The difference is that integer division is supposed to round towards zero, while >> rounds towards negative infinity |
| 21:13:14 | kugel | you can alloc the actual length (+ \0) |
| 21:13:20 | gevaerts | 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 | gevaerts | kugel: as soon as someone complains, we'll fix it. I don't think we should bother before that though |
| 21:14:23 | amiconn | 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 | kugel | :p |
| 21:16:46 | | Join perrikwp1 [0] (n=Keith@rrcs-96-10-92-195.se.biz.rr.com) |
| 21:17:47 | gevaerts | 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 | JdGordon| | it was done that way for speed and simplicity reasons |
| 21:19:29 | JdGordon| | being able to do buffer[i*MAX_PATH] makes things dead simple |
| 21:19:56 | gevaerts | indeed |
| 21:20:33 | gevaerts | well, you could have the plugin write the same format whatever it's internal structure, but that gets even more complicated |
| 21:21:24 | gevaerts | it would also slow down the writing of that file |
| 21:21:47 | JdGordon| | how about leaving it as it is for now? :) |
| 21:22:06 | gevaerts | 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 | mc2739 | FlynDice: for the logs, http://pastie.org/530922 does not help microsd problems on e200v2 |
| 22:00 |
| 22:09:00 | kugel | mc2739: that's weird |
| 22:09:10 | kugel | I have no sorts of microsd problems |
| 22:09:24 | kugel | I tried pluging in and out in several situations |
| 22:09:50 | tmzt | what good is it for the logs if the paste disappears? |
| 22:10:23 | kugel | what? |
| 22:12:12 | mc2739 | kugel: I also tried the v2 patch from FS #10344(with the 1.05v setting) and get the same behavior |
| 22:13:42 | mc2739 | 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 | mc2739 | 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 | FlynDice_ | 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 | mc2739 | FlynDice_: yes |
| 22:26:24 | FlynDice_ | I'm playing off my 8GB msd right now with no problems, but I have had problems in the past |
| 22:27:09 | FlynDice_ | I found formatting will let the card work but is not necessary |
| 22:27:47 | mc2739 | I wonder if this maight be the same sort of problem as the FM radio - different hardware versions |
| 22:27:57 | FlynDice_ | 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 | mc2739 | I could try that, but the OF takes so long to rebuild it's database |
| 22:29:08 | FlynDice_ | 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 | FlynDice_ | 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 | mc2739 | 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 | FlynDice_ | 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 | mc2739 | 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 | kugel | mc2739: did you try adding some mci_delay()s in sd_init_card? |
| 22:41:33 | mc2739 | kugel: no, I have not tried that |
| 22:42:21 | kugel | 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 | kugel | 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 | mc2739 | 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 | JdGordon| | gevaerts: you going to fix the dir skip actions in the wps to work with your new playlists? |
| 22:48:58 | gevaerts | JdGordon|: are they broken as such? |
| 22:49:25 | JdGordon| | well,. they dont work with playlist playlists |
| 22:49:30 | JdGordon| | 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 | mc2739 | 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 | funman | mcuelenaere: does onda support both SD and MMC cards ? |
| 22:51:58 | Torne | 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 | mcuelenaere | funman: the SoC does, but the physical card holder is SD-only (for the current devices using that SoC) |
| 22:52:18 | mcuelenaere | microSD that is |
| 22:52:34 | funman | mcuelenaere: i'm a bit disturbed by the references to "mmc" in ata-sd-jz4740.c :) |
| 22:52:43 | mcuelenaere | yeah, that's not really my code |
| 22:52:47 | mcuelenaere | I know, it's a mess .. :( |
| 22:52:50 | funman | ok :/ |
| 22:52:59 | gevaerts | 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 | funman | do you know in which word-order the cid & csd are stored in memory ? |
| 22:53:06 | kugel | 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 | Torne | gevaerts: that doesn't help though does it? |
| 22:53:30 | Torne | or is there some trick i'm missing |
| 22:53:40 | mcuelenaere | funman: no idea, I saw that the code stores it in the way the SD interface receives it |
| 22:53:43 | kugel | 192MHz as CPUFREQ_MAX |
| 22:53:45 | funman | or in other words does the debug screen -> disk info look correct for manufacturing date / product id serial number .. |
| 22:53:50 | mcuelenaere | nope |
| 22:53:59 | mcuelenaere | that's why there's a TODO at that function ;) |
| 22:54:13 | funman | disk info debug menu read this info directly from the registers |
| 22:54:17 | mcuelenaere | 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 | funman | why is mmc_request->response 18 bytes and not 16 ? |
| 22:57:05 | funman | the real data seems to start after the 1st byte |
| 22:57:09 | gevaerts | Torne: /me thinks that Torne should have another look at the manual :) |
| 22:57:17 | * | Torne grumbles :) |
| 22:57:30 | funman | 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 | funman | to avoid touching this driver I could write another implementation of card_extract_bits for SD |
| 22:57:57 | Torne | gevaerts: aha |
| 22:58:06 | Torne | so that picks the next directory from the fs? |
| 22:58:13 | funman | my last commit is wrong : the cid/csd registers need to be stored most significant word first |
| 22:58:14 | mc2739 | kugel: it already works at 62mhz and 248mhz without the voltage change |
| 22:58:33 | mc2739 | back later |
| 22:58:34 | gevaerts | Torne: depends on your settings. It can also pick a random one |
| 22:58:55 | kugel | mc2739: I know, but now changing the frequency isn't instant anymore, and more complex |
| 22:59:35 | Torne | 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 | funman | mc2739: i just noticed a lock up with my microsd card |
| 22:59:40 | Torne | unless it's a pretty short album |
| 22:59:54 | | Quit robin0800 (Remote closed the connection) |
| 23:00 |
| 23:00:19 | kugel | I'm wondering if we need to boost on (microsd) data transfers, just to keep the voltage up |
| 23:00:30 | gevaerts | Torne: yes. If you never skip, the new feature is better. Otherwise not |
| 23:01:04 | Torne | what does next folder do if you're playing a tagcache playlist then? |
| 23:01:07 | Torne | nothing? |
| 23:01:45 | kugel | that probably wouldn't even cost much |
| 23:01:47 | mcuelenaere | funman: I didn't really change much in the code, just adapted it to Rockbox |
| 23:01:51 | gevaerts | I'm not sure. probably not what you want |
| 23:01:57 | kugel | 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 | Torne | 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 | FlynDice_ | kugel: isn't microsd transfer dma so should the processor core voltage even matter? |
| 23:03:05 | kugel | obviously, it's affecting more than only the core voltage |
| 23:03:08 | gevaerts | 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 | Bagder | 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 | Torne | hehe |
| 23:03:46 | Torne | ok, i'll have a look/fiddle later |
| 23:04:03 | Torne | 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 | Torne | which would do soemthing useful for nonshuffled playlists |
| 23:04:18 | kugel | Torne: you can't dirskip in tagcache playlists |
| 23:04:28 | Torne | kugel: right. |
| 23:04:44 | funman | mcuelenaere: would you help me cleaning it if i break it with my changes? |
| 23:04:59 | gevaerts | Bagder: did you see my -j calculations at http://www.rockbox.org/irc/log-20090701#16:48:17 ? |
| 23:05:38 | mcuelenaere | funman: you mean the Ingenic driver or the generic part in Rockbox? |
| 23:05:46 | Bagder | gevaerts: now I did! |
| 23:05:48 | Bagder | thanks |
| 23:06:54 | gevaerts | 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 | Zagor | gevaerts: how do you mean it would affect single-core hosts? |
| 23:07:55 | wincent | kugel: pong |
| 23:08:47 | funman_ | mcuelenaere: the ingenic part |
| 23:08:54 | mcuelenaere | funman: sure |
| 23:09:03 | funman_ | though i can commit for PP & as3525 and then work on ingenic on flyspray |
| 23:09:15 | Bagder | "C++ library exception" ... |
| 23:09:19 | Bagder | in the bootrom? |
| 23:09:21 | Bagder | ;-) |
| 23:09:29 | | Quit funman ("Reconnecting") |
| 23:09:29 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 23:09:33 | gevaerts | Zagor: hm, now I think about that particular bit a bit more, it doesn't make much sense... |
| 23:10:19 | kugel | 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 | Torne | 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 | gevaerts | 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 | mcuelenaere | funman_: just commit, I'll shout when you broke something ;) |
| 23:11:03 | wincent | kugel: Where does this table reside? |
| 23:11:23 | funman_ | mcuelenaere: well i just won't use the common code on ingenic |
| 23:11:35 | gevaerts | Torne: indeed. Just some strrchrs and strncmps I guess |
| 23:11:43 | funman_ | i'm still looking at PP code, then i'll move some code out from PP & AMS code into sd.c |
| 23:11:53 | kugel | wincent: in several places :) see http://www.rockbox.org/tracker/task/10400 |
| 23:12:09 | kugel | funman_: have you had time to test my mkamsboot patch? |
| 23:12:24 | notlistening | rasher, if you have a minute this one is stopping me at the moment http://pastebin.com/d4ffb1625 |
| 23:13:29 | kugel | gevaerts: I think it would make a difference until we have 106 build clients or have the clients to parallel builds |
| 23:13:58 | funman_ | kugel: no :/ where is it ? |
| 23:14:31 | wincent | 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 | Zagor | 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 | kugel | funman_: http://www.rockbox.org/tracker/task/10397 |
| 23:15:05 | kugel | Zagor: no, I mean 1 client doing multiple builds :) |
| 23:15:17 | gevaerts | Zagor: maybe we should just try both ways. It's going to be hard to work out the numbers from scratch |
| 23:15:19 | Zagor | kugel: yes, that means each build will be slower |
| 23:15:22 | kugel | instead of -j, since gevaerts showed the depgen limits |
| 23:15:42 | Zagor | gevaerts: true. statistics rule. |
| 23:16:20 | kugel | wincent: I don't know what accuracy you need though, the rockbox' one has only 90 values |
| 23:17:13 | gevaerts | 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 | Zagor | we should focus on getting it up and running at all, so we can collect statistics |
| 23:18:26 | Bagder | hm, the romdump is little endian? |
| 23:18:46 | Bagder | Zagor: the main problem atm is the client's too frequent dyings |
| 23:18:53 | wincent | kugel: Yes, the one from Pure Data is way greater. I will look into this later. |
| 23:18:57 | Zagor | Bagder: dying? |
| 23:19:05 | Bagder | 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 | Bagder | that, and the make process not being killed properly |
| 23:19:41 | Zagor | oh, I see that now. oddness. |
| 23:19:45 | gevaerts | Bagder: did we actually try my latest patch for that? |
| 23:19:55 | Bagder | no, not yet |
| 23:20:40 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 23:20:56 | | Quit bmbl ("Bye!") |
| 23:21:50 | gevaerts | hm, what was my latest patch? negative signal or negative pid? |
| 23:22:10 | gevaerts | :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 | Bagder | negative signal I beleive |
| 23:23:20 | kugel | JdGordon|: why? |
| 23:23:57 | gevaerts | hm, timestamps seem to show the opposite |
| 23:24:08 | JdGordon| | it doesnt sit well with me.. |
| 23:24:22 | kugel | but you can't explain that? |
| 23:24:50 | JdGordon| | yeah :/ |
| 23:25:07 | | Quit FlynDice_ (Remote closed the connection) |
| 23:25:49 | gevaerts | Bagder: I now have one of each running, so maybe we can just try? |
| 23:26:38 | gevaerts | Also one core each to increase my chances of killed builds |
| 23:26:39 | JdGordon| | oh wait! dont start any runs |
| 23:27:39 | JdGordon| | ok, my client is giong again, you can start them |
| 23:27:58 | Bagder | sorry, but I don't have time to play with that atm |
| 23:28:06 | JdGordon| | how rude! |
| 23:28:07 | JdGordon| | :p |
| 23:28:18 | * | gevaerts looks at Zagor instead :) |
| 23:28:19 | Mikachu | jarjargordon |
| 23:28:58 | Zagor | gevaerts: what is the patch you are talking about? |
| 23:30:30 | gevaerts | 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 | gevaerts | basically the problem is that you just kill the shell, but not any childprocesses of that |
| 23:31:50 | gevaerts | the second patch is reversed |
| 23:32:10 | Zagor | ah, right. so how do we kill the whole process tree? iterate through the pids? |
| 23:32:38 | Zagor | -$pid or -signal seems a bit... arbitrary. is that documented anywhere? |
| 23:32:50 | gevaerts | From /bin/kill, just use the negative of the parent pid. In perl, it's a bit confusing |
| 23:33:29 | gevaerts | 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 | Zagor | yeah perl does not do what /bin/kill does |
| 23:35:42 | Zagor | Bagder: did you change the server location or is it still running from the same place? |
| 23:36:06 | Bagder | I've been running it in my own dir during my tests |
| 23:36:12 | gevaerts | it's weird actually. kill(2) should behave the same as /bin/kill |
| 23:36:23 | Bagder | Zagor: it needs a data subdir, where it moves the completed builds |
| 23:36:34 | gevaerts | so I don't know why perl is different |
| 23:36:48 | Zagor | gevaerts: yes but perl has to deal with inter-system portability. bsd != posix for instance. |
| 23:38:13 | gevaerts | 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 | Zagor | I don't know |
| 23:40:36 | Zagor | any osx people here? |
| 23:40:56 | Zagor | Bagder: can you disable your test server so I can run one? |
| 23:41:07 | gevaerts | 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 | Bagder | ah sorry, done now |
| 23:43:48 | | Join lee321987 [0] (n=chatzill@adsl-76-250-135-220.dsl.dytnoh.sbcglobal.net) |
| 23:43:56 | JdGordon| | Zagor: lambda, lostlogic and preglow I tihnk are our resident turtleneck wearing hippies :D |
| 23:43:57 | gevaerts | 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 | lee321987 | 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 | Zagor | gevaerts: I guess there's only one way to find out :-) |
| 23:45:50 | gevaerts | 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 | Bagder | lee321987: original firmware version is the only really safe way we know |
| 23:46:36 | gevaerts | so perl seems to use negative signal numbers instead of negative pids to do this |
| 23:47:28 | Zagor | gevaerts: aha. is that what your test client does now? |
| 23:47:38 | gevaerts | one of them, yes |
| 23:47:45 | | Quit lee321987 (Client Quit) |
| 23:49:18 | CIA-69 | New commit by funman (r21601): add firmware/driver/sd.c which contains common code between SD drivers ... |
| 23:53:41 | Bagder | 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 | Bagder | that's fixed now though |
| 23:54:29 | Zagor | ok |
| 23:54:55 | Bagder | and it now rejects duplicate client names (from the same user) |
| 23:55:23 | Zagor | good |
| 23:56:06 | | Quit bluebrother ("leaving") |
icon identifies that the person is a core developer (has commit access).