--- Log for 27.09.111 Server: asimov.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 18 hours ago 00.02.41 Part Zagor 00.15.56 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 00.21.34 Quit mikroflops (Ping timeout: 248 seconds) 00.30.07 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 00.33.50 Quit mudd1 (Ping timeout: 248 seconds) 00.38.58 Quit Strife89 (Ping timeout: 258 seconds) 00.44.22 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 00.46.40 Quit mamarley (Remote host closed the connection) 00.51.03 Quit matze` (Read error: Connection reset by peer) 00.52.20 Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu) 00.52.39 Join [Saint] [0] (~st.lasciv@203.184.50.187) 01.03.36 Quit bluefoxx (Ping timeout: 276 seconds) 01.06.18 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 01.22.08 *** Saving seen data "./dancer.seen" 01.24.24 Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se) 01.35.59 Join mystica555_ [0] (~mike@71-211-199-174.hlrn.qwest.net) 02.11.16 Quit liar (Remote host closed the connection) 02.18.31 Quit Strife89 (Quit: Goodnight!) 02.33.50 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 02.54.00 Quit Keripo (Read error: Connection reset by peer) 02.55.25 Join Keripo [0] (~Keripo@165.123.49.206) 03.00.36 Quit Keripo (Ping timeout: 276 seconds) 03.02.37 # New commit by 03fredwbauer (r30610): Do not move NULL pointers in buflibmove_callback(). Fixes some skin crashes when changing themes. 03.04.33 # r30610 build result: All green 03.22.11 *** Saving seen data "./dancer.seen" 03.39.17 # [Saint]: are you not shipping your 24px imageset with the theme? 03.40.26 # <[Saint]> I can't remember if I put it in there or not off the top of my head. 03.40.43 # <[Saint]> I want to re-do the icons. I'll probably do so tonight. 03.40.52 # <[Saint]> 24px is too small for 480x800 03.41.04 # looking at God_Eater's screenshot, the icons make it look shit :) 03.42.44 # <[Saint]> I'll probably do: 240x320 == 18x18, 320x480 == 28x28, and 480x800 == 38x38 03.43.06 # <[Saint]> Iconsets are a royal PITA to do, though... ;) 03.43.07 # dont they all use the same font size? 03.43.40 # <[Saint]> What? No...shit no. 03.43.52 # DAMN NO! FUCK NO! 03.43.56 # JUST FUCKING NO! 03.44.22 # <[Saint]> 46pt font on the 240x320 port would be.....interesting ;) 03.44.37 # <[Saint]> You'd get ~5 items in the list or so. :P 03.46.17 # <[Saint]> JdGordon: I'm unsure what to do about making the titlebar use .lang strings... 03.46.35 # I don't want those string in the lang file 03.46.48 # I know for sure others dont either 03.47.01 # <[Saint]> I need at least one additional string. But I'm not sure about how "ethical" it would be to add it. 03.47.08 # the only good way to do it is have a skin translation system external to the core 03.47.21 # <[Saint]> There's only one (I think) I need that isn't there. 03.47.28 # <[Saint]> "Screen Locked" 03.47.40 # you sure that isnt there alreayd? 03.47.49 # <[Saint]> I'm pretty sure it'd be ok to add this, with the view that this theme will *eventually* be the default. 03.48.23 # "Buttons Locked" is there 03.49.04 # <[Saint]> Hmmmm....that *might* do. Its not quite right, though. 03.49.17 # <[Saint]> It would imply the HW buttons were locked. 03.49.20 # <[Saint]> they're not. 03.49.35 # <[Saint]> Oh...I also have a skin issue for you. 03.49.49 # see a dermatologist :) 03.50.11 # <[Saint]> the touch area "none" doesn't act like the other touch areas. It doesn't wait to see if its a short or long press. 03.50.22 # <[Saint]> And, it can't be used as a long press. 03.50.27 # <[Saint]> It fires immediately. 03.50.53 # <[Saint]> This makes "Hotkey" interesting in the theme, as the popup fires as well. 03.52.27 Join fyrestorm [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) 03.52.35 Quit evilnick (Ping timeout: 240 seconds) 03.54.04 # err... hmm... 03.54.15 # umm 03.54.59 # <[Saint]> I had a look at the source, but I couldn't see why it behaves differently. 03.55.19 # <[Saint]> Admittedly, I didn't really understand how it was implemented ;) 03.55.37 # the none action is quite a hack 03.56.53 # <[Saint]> Its not /crucial/, but, ideally (with a mind of eventually getting this into SVN) it'd be nice if it a: acted like the other touch areas, and b: could be used with "long_press" 03.57.03 # <[Saint]> But, not crucial. 03.57.12 # what was none used for? 03.57.58 # <[Saint]> I use it to fire the pop-ups 03.58.16 # use skin vars instead 03.58.20 # <[Saint]> well, I use it to set the skin variable, which fires the pop-ups. 03.58.45 # cant they be set directly from %T? 03.59.05 # ok, no 03.59.11 # <[Saint]> Nah, they can't. 03.59.17 # <[Saint]> Ah, too late. 04.00.04 # <[Saint]> Even if there /were/ a different way to do this (there isn't ;)), it'd still be nice for "none" to act as every other touch area does. 04.00.25 Quit MethoS- (Read error: Connection reset by peer) 04.00.39 # ok, gimme a sec 04.01.00 # <[Saint]> There's no rush. I justy wanted to make you aware of it. 04.01.05 # <[Saint]> *just. 04.01.13 # <[Saint]> I can open a tracker task if you'd prefer. 04.01.24 # <[Saint]> But, there's certainly no rush, none at all. 04.02.06 # try http://pastebin.com/rWc8kjvX 04.02.55 # the issue was none was returning ACTION_TOUCHSCREEN which is the same action that gets returned if no region is pressed 04.03.35 # though that doesnt completly explain the problem 04.07.09 Quit ender| (Ping timeout: 244 seconds) 04.19.20 Join ender| [0] (~ender1@foo.eternallybored.org) 04.29.28 Quit [fred] (Ping timeout: 260 seconds) 04.32.43 Join tmzt_ [0] (~tmzt@adsl-76-244-153-175.dsl.akrnoh.sbcglobal.net) 04.34.44 Join [fred] [0] (fred@ircop.efnet.at) 04.36.10 Quit tmzt (Ping timeout: 252 seconds) 04.38.46 Quit amiconn (Disconnected by services) 04.38.46 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.38.47 Quit pixelma (Disconnected by services) 04.38.49 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.38.51 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.39.08 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.43.22 Quit TheSeven (Disconnected by services) 04.43.34 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 05.18.20 # [Saint]: does silence mean you've exploded from the awesomeness that is that patch? 05.22.13 *** Saving seen data "./dancer.seen" 05.35.00 Quit ps-auxw (Ping timeout: 240 seconds) 05.39.18 Join ps-auxw [0] (~arneb@p4FF7F6DE.dip.t-dialin.net) 05.44.25 Quit Horschti (Quit: Verlassend) 05.54.09 Join Rob2223 [0] (~Miranda@p4FFF3A33.dip.t-dialin.net) 05.58.17 Quit Rob2222 (Ping timeout: 255 seconds) 06.00.40 Quit jhMikeS (Read error: Connection reset by peer) 06.03.54 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 06.03.55 Quit jhMikeS (Changing host) 06.03.55 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 06.05.38 Quit ps-auxw (Quit: leaving) 06.06.01 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 06.12.40 Join ReimuHakurei [0] (~reimu@wireless.sit-co.net) 06.15.56 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 06.15.56 Quit amiconn (Disconnected by services) 06.16.18 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 06.17.44 Quit ReimuHakurei (Quit: Linkinus - http://linkinus.com) 06.18.21 Join ReimuHakurei [0] (~reimu@wireless.sit-co.net) 06.40.59 Quit tmzt_ (Read error: Connection reset by peer) 06.41.23 Join tmzt [0] (~tmzt@adsl-76-244-147-161.dsl.akrnoh.sbcglobal.net) 07.00.37 Join evilnick [0] (~evilnick@5e007ec9.bb.sky.com) 07.00.38 Quit evilnick (Changing host) 07.00.38 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 07.19.50 Quit BHSPitMonkey (Remote host closed the connection) 07.22.15 *** Saving seen data "./dancer.seen" 07.25.03 Join tmzt_ [0] (~tmzt@adsl-76-244-151-92.dsl.akrnoh.sbcglobal.net) 07.28.08 Quit tmzt (Ping timeout: 256 seconds) 07.35.11 Join tmzt [0] (~tmzt@adsl-76-244-159-106.dsl.akrnoh.sbcglobal.net) 07.38.43 Quit tmzt_ (Ping timeout: 260 seconds) 07.39.26 Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 07.40.07 Quit bluefoxx (Ping timeout: 276 seconds) 07.50.30 # [Saint]: did you try the patch? 07.55.00 Quit [Saint] (Ping timeout: 252 seconds) 08.00.32 Join [Saint] [0] (~st.lasciv@203.184.50.187) 08.10.26 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 08.32.17 Quit powell14ski_ (Quit: powell14ski_) 08.37.08 Join B4gder [241] (~daniel@rockbox/developer/bagder) 08.41.07 Join ender` [0] (~ender@foo.eternallybored.org) 08.50.51 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.54.04 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.54.10 Part Zagor 08.59.21 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.07.14 # [Saint]: I was very happy with 24x24. don't you think 28x28 is too big? 09.07.49 # I hope you don't just scale down from 480x800 as thatcompletely ignores the dpi of the screen 09.10.48 Quit Scromple (Quit: Leaving) 09.15.04 Quit Jak_o_Shadows (Ping timeout: 252 seconds) 09.22.17 *** Saving seen data "./dancer.seen" 09.24.29 Join n1s [0] (~quassel@rockbox/developer/n1s) 09.33.08 Quit bertrik (Read error: Operation timed out) 09.39.51 Quit fyrestorm (Read error: Connection reset by peer) 09.49.03 Quit n1s (Remote host closed the connection) 09.59.33 Join LinusN [0] (~linus@giant.haxx.se) 10.01.18 Join fyrestorm [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) 10.03.23 Quit jhMikeS (Ping timeout: 260 seconds) 10.18.08 Quit user829385 (Ping timeout: 256 seconds) 10.21.38 Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) 10.21.39 Quit dfkt|n (Changing host) 10.21.39 Join dfkt|n [0] (dfktn@unaffiliated/dfkt) 10.22.09 # * [Saint] has no idea what kugel is on about... 10.23.26 Join user829385 [0] (~aoeu@112.166.15.141) 10.25.09 # <[Saint]> JdGordon: Sorry, actually I was out doing my grocery shopping ;) 10.25.56 # <[Saint]> I can't test it presently. No way to build. But if you can test it, and it works, sweet. 10.27.08 # <[Saint]> If it stops "none" from firing immediately, instead of not waiting to see if its a long or short press then its "fixed". 10.27.46 # [Saint]: the icons 10.28.09 # sorry 10.29.06 # <[Saint]> It basically just needs to act like the other touch actions which allow for a short and long press touch action to overlap each other and not fire fire them both in the long press case. 10.29.10 # <[Saint]> JdGordon: ^ 10.29.33 # touchscreen presses give results immediately because the coordinates change 10.29.45 # that's why none is timing out so early 10.31.11 # internally, anyway 10.31.29 # <[Saint]> kugel: I'm still not quite sure what you mean, regarding the icons. I make each set from the Tango! SVG sources individually, making one .bmp set and scaling it just. doesn't. work ;) 10.31.45 # I mean scaling the sizes 10.31.50 # <[Saint]> If you scale a .bmp image with our "magic colour", the result is hillarious. 10.32.11 # I would imagine that depends on the scaling algorithm 10.32.17 # colour bleeding usually hurts that a lot 10.32.39 # like if 480x800 is X then 320x4800 must be Y (where Y is simply scaled down from X and the resolution) 10.32.54 # I'm not asking whether you're actually scaling the images with a program 10.33.14 # <[Saint]> But yeah...regarding the *sizing*, I made a mockup of the UI viewport and the font height and thought that those sizes just looked right. 10.34.05 # mockup on your desktop lcd? 10.34.35 # I found the icons looking a bit "clamped" in the lists and thought there could be a bit more spacing (maybe "included" in the image source) 10.37.01 # <[Saint]> pixelma: kugel has some configurable list height patch thing but hasn't yet committed it. That would help for individual prefernce with list spacing. 10.37.03 # [Saint]: I suggest trying an android emulator from the sdk. it has the option to scale the window to match the real screen. that way you can judge better 10.37.44 # [Saint]: sorry I wasn't clear - I eant the horizontal spacing between scrollbar, icons and menu items 10.37.50 # meant too 10.37.55 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 10.38.03 # not the vertical spacing at all... 10.39.04 # I know about the list spacing - I once tried kugel's old patch and found the result looking way to big on my phone's screen although the number of lines was the same as in android's native lists, e.g. the app manager. My guess was that the separator lines and more info per item makes quite a difference 10.39.26 # in appearance 10.39.41 # <[Saint]> pixelma: Ah...I actually have a one line patch that spaces the list text one character away from the icons. I wouldn't mind that in svn actually. I think that it looks better with a slight space between the list and the icons too. 10.40.33 # I'd include the spacing in the icon (just some blank/magic magenta transparent pixels) 10.41.41 # <[Saint]> Hmmm, I guess that's the better option. 10.41.46 # no need for a code solution 10.49.31 Join swilde [0] (~wilde@aktaia.intevation.org) 10.51.42 # and another comment (IIRC) - I'd prefer the dB information when changing volume be in place of the icon during that, not on the info line - in the yelloish colour and maybe even turning red over 0dB as the icon basically does. That's something I'd want for all cabbies btw. 11.05.13 # <[Saint]> RaaA doesn't go above 0dB 11.05.30 # <[Saint]> I could make it red *on* 0dB, though. 11.05.34 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 11.05.34 Quit pamaury (Changing host) 11.05.34 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.05.40 # It probably doesn't need that. Red typically implies "warning" 11.06.12 # <[Saint]> I was just thinking that, and 0dB doesn't == "warning". 11.06.30 # <[Saint]> So, yeah, perhaps thats not such a great idea... ;) 11.06.33 # Does RaaA adjust android's media volume, or does it adjust Rockbox's volume relative to android's media volume? 11.06.40 # also it's not a dB scale in RaaA :) 11.06.43 # well I meant that in general, and as I said - for all cabbiev2s which means targets that can go above 0dB 11.16.20 Join JdGord [0] (~AndChat@122.110.238.159) 11.20.05 Quit user829385 (Quit: Leaving.) 11.22.21 *** Saving seen data "./dancer.seen" 11.30.07 Join user829385 [0] (~aoeu@112.166.15.141) 11.33.07 Quit JdGord (Quit: Bye) 11.34.44 Quit bluebrother (Disconnected by services) 11.34.45 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 11.35.16 Join pamaury_ [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 11.36.08 Quit pamaury (Ping timeout: 260 seconds) 11.36.20 Quit fs-bluebot (Ping timeout: 256 seconds) 11.37.31 Join fs-bluebot [0] (~fs-bluebo@g226071004.adsl.alicedsl.de) 11.49.44 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) 12.18.47 Quit nick-p (Quit: Leaving) 12.59.48 Quit casainho (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110905174115]) 13.22.22 *** Saving seen data "./dancer.seen" 13.30.32 Join T44 [0] (~Topy44@g228130128.adsl.alicedsl.de) 13.34.33 Quit Topy44 (Ping timeout: 260 seconds) 13.37.35 Join rf [0] (5a92c48b@gateway/web/freenode/ip.90.146.196.139) 13.38.53 # hi 13.39.19 # do you know, if there is a datasheet for the Ipod classic screen or the ipod video screen 13.40.03 # <[7]> well, there are datasheets of similar devices at least, but as I told you, all of these have 6800/8080 interfaces, so they're not suitable for your project 13.40.18 # ok 13.40.38 # hope i do not annoy you with that question 13.40.43 # again 13.41.31 # <[7]> so any recommendations on a device with lots of storage and an excellent DAC or a platform on which one could build such a thing? 13.42.00 # * [7] doesn't know the non-apple targets well enough to answer that question himself 13.43.27 # <[7]> the ipod classic has a rather crappy dac and stability problems, so that one has been ruled out already 13.46.12 # rf: If you're wanting to build your own DAP, this may be of interest - http://lyre.sourceforge.net/ 13.48.25 # <[7]> that's also where the mini2440 port i mentioned earlier came from 13.51.09 Quit ReimuHakurei (Remote host closed the connection) 13.52.27 # Lyre is nice 13.52.52 # but i already received the beagleboard... 13.52.53 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 13.52.53 Quit pamaury (Changing host) 13.52.53 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.55.37 Part rf 13.55.51 # doesn't the beagleboard have atrocious sound? 13.56.22 # i don't think anyone was paying very much attention when routing the audio signals 13.56.26 Quit pamaury_ (Remote host closed the connection) 13.56.30 # gumstix certainly weren't when they did the overo 13.59.16 # <[7]> Torne: it does have I2S and I2C on the expansion header though, so you can add a sane DAC to it 14.05.06 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 14.06.24 # This look quite interesting and could allow us to take stack backtrace on ARM on exception http://www.mcternan.me.uk/ArmStackUnwinding/. Can arm experts look at this? 14.11.19 # wodz: we can also compile in debug mode and use the dwarf compiler output 14.11.31 # pamaury: this is unwinding on device, though 14.11.43 # yes, same thing on device 14.11.55 # uh 14.11.59 # that would be massive :) 14.12.18 # one would need to check, most of the debug info useless and could be stripped 14.12.24 # no, i mean the code to hadnle it 14.12.51 # I don't think so, we don't need to handle the full dwarf spec 14.13.35 # I'm not saying it's free of course :) 14.14.25 Join JdGord [0] (~AndChat@106.71.69.95) 14.14.51 # we could have an address->function resolver on the web site 14.15.31 # Zagor: that's pretty much useless without backtrace most of the time no ? 14.15.32 # Zagor: that's not very useful 14.15.38 # unless you save entire stacks 14.15.48 # and most people have nowhere to write those to 14.15.53 # since that pretty much requires serial 14.15.54 # I mean for multiple addresses 14.16.05 # Right, but you don't know which things are addresses 14.16.13 # so you end up having to display the entire stack on the screen 14.16.17 # ...for a stack trace 14.16.42 # as opposed to needing full debug symbols in the builds 14.16.49 # oh 14.16.51 # this isn't about symbols 14.16.54 # this is about .debug_frame 14.17.00 # the cfi data to unwind the stack 14.17.40 # yes 14.17.50 # I'm trying a debug build to see the size 14.18.18 # i think the more interesting part is "how big a binary is libunwind" :) 14.19.03 # dwarf's actual encoding is weird and scary and i wouldn't want to implement it 14.19.31 # I had a look at it and it's not that bad I think; libunwind is probably massive otoh, handling lots of weird stuff 14.19.52 # hey, why the f+ debug build fails on undefined reference to `H_TO_BE32' ?? 14.20.37 # pamaury: it is pretty incomprehensible.. 14.20.44 # pamaury: the CFI format is only part of it.. 14.20.53 # yes I know 14.21.45 # but if you only want to stack trace, I *think* it's ok, I might be wrong though 14.22.04 # I think someone broke the debug builds 14.22.21 # clip+ build: rockbox/apps/recorder/pcm_record.c:1674: undefined reference to `H_TO_BE32' 14.22.44 # can someone else try a debug build ? 14.23.04 # <[7]> smells like a missing include 14.23.25 # you don't realyl want a debug build, do you? 14.24.49 # Torne: does the compiler generate dwarf info in all cases ? 14.24.49 # indeed, H_TO_BE32 is compiled out in debug build 14.24.58 # if not then we should do 14.25.02 # because it's cheap and useful 14.25.56 # <[7]> what about implementing post-mortem memory dumps on some more targets? 14.26.09 # dumping to where? 14.26.12 # <[7]> USB 14.26.32 # <[7]> we have that on the nano2g, and it's <1K ramsize overhead, at least on that target 14.27.00 # <[7]> might be a bit more with less fancy OTGs 14.27.09 # pamaury: it doesn't, no, but it should. plz fix :) 14.27.53 # sensible debug builds change nothing except #defines 14.28.00 # we can jsut do -g always 14.28.56 # Torne: I'm willing to fix it but why the hell is it compiled out and nobody noticed ? 14.29.04 # hm? 14.29.09 # because people never build non-debug builds with -g 14.29.17 # even though you should :) 14.29.36 # I'm talking about H_TO_BE32 ! 14.29.41 # Oh. 14.29.47 Quit JdGord (Read error: Connection reset by peer) 14.29.52 Join JdGord [0] (~AndChat@106.71.69.95) 14.29.56 # nobody builds with DEBUG defined 14.30.10 # i meant, please fix that you don't get symbols when you aren't building debug 14.30.17 # but yeah, we should probably compile with -g, although I'm a bit scared by the makefiles we have so if someone else can do it I prefer :) 14.30.20 # <[7]> is that maybe just misspelled? don't we call it HTOBE32? 14.30.46 # there is a define H_TO_BE32 14.30.59 # <[7]> well, then that file isn't included in the right place 14.31.04 # Torne: why should we build with -g? 14.31.32 Quit JdGord (Read error: Connection reset by peer) 14.31.33 Join jdgord_ [0] (~AndChat@106.71.69.95) 14.31.49 # [7]: strange, I don't find any reference to it in apps/ :-/ 14.32.00 # and only one in firmware/ : the define itself 14.32.20 # kugel: so you don't have to go back and recompile everything when you want debug info? 14.32.41 # but isn't it a waste of space? 14.32.45 # <[7]> host to big endian conversion isn't exactly something that's done very commonly 14.32.58 # no, debug info is not a loadable section 14.33.01 # objcopy will just ignore it 14.33.06 # oh I just understood, in debug build it seems to include more information and uses a ENC_CHUNK_MAGIC which relies on H_TO_BE32 which is not defined anywere 14.33.34 # kugel: the point is to leave it all in the ELF binary 14.33.36 # but we do have a htob32 14.33.38 # kugel: not the actual firmware binary 14.34.19 # <[7]> a dwarfed elf in combination with a full post-mortem dump is about the best that you can possibly get 14.34.27 # some info: fuze+ debug build: 14.34.28 # .debug_frame: 75Kib 14.34.45 # right 14.34.54 # so even if the code to decode it is free that's pretty large 14.35.03 # .debug_info: 1.2Mib 14.35.12 # you can implement a basic unwinder for ARM in under 4kb as wodz's link does :) 14.35.18 # ARM is really, really easy to unwind by hand 14.35.19 # we need .debug_info but we wan't to strip most of it 14.35.35 # Torne: I never compile with -g (explicitely) but the .elf output is just fine 14.35.43 # thanks to the function prolog/epilog being completely predictable 14.35.52 # kugel: ..huh? 14.35.52 # <[7]> just get the data off the device and analyze it on a pc 14.36.02 # [7]: The point is for *end users* 14.36.09 # who currently report just a single address for a crash 14.36.11 # <[7]> the end users can send us a dump 14.36.13 # so we can print, say, 5 addresses 14.36.25 # or whatever fits on the screen 14.36.31 # and know that they are probably the right ones 14.36.44 # kugel: if you don't compile with -g you don't get debug info 14.37.28 # the .debug_* sections don't exist without that 14.37.47 # <[7]> if we want to make it easier for the end users to obtain a dump and sacrifice some more ramsize for it, we could emulate a UMS drive with a debuginfo.dat file on it :) 14.38.01 # How does the wodz's link work ? 14.38.17 # pamaury: it just disassembles a few interesting arm instructions and follows execution backwards 14.38.34 # The format of a functoin on ARM is so predictable that you don't need any actual unwinding data at all 14.38.35 # you can't to that reliably can you ? 14.38.48 # For gcc-generated code you can do it with basically 100% accuracy 14.38.52 # for assembler it might miss a few 14.40.03 # i ahven't looked at that specific implementation, but i've seen it done 14.41.07 Join n1s [0] (~quassel@rockbox/developer/n1s) 14.41.10 # * [7] likes the crashkernel (kexec on panic) approach of obtaining memory dumps 14.41.24 # pamaury: you just take the value of lr and "jump" there, starting to "execute" instructions until you hit the function epilog 14.41.40 # you can ignore almost all instructions, so your emulator can be really stupid 14.41.59 # when you get to the epilog you can deduce the form of the current stack frame and work out the previous return address by reading the stack 14.42.02 # then repeat 14.42.20 # <[7]> and a simple crashkernel fits in 1KiB of memory 14.42.25 # some minor caution for tail calls is about all you need :) 14.42.30 # this assumes the stack is allocated/freed at once, is that an abi requirement ? 14.42.44 # pamaury: Nope, but it always will be in compiler-generated code 14.43.09 # <[7]> you can also detect if part of it is freed prematurely while searching for the tail 14.43.29 # That only ever happens in handwritten assembler, though, srsly 14.43.36 # gcc just plain doesn't do taht 14.43.43 # <[7]> premature freeing could be interpreted as an epilog with a fallthrough into the next function 14.44.08 # <[7]> so it's actually pretty much straightforward to handle it 14.45.20 # so maybe this worth a try to extend our panic screen? 14.45.24 # anyway. if that implementation works for our code (it's old, btu should be reasonable i think) then it's almost a no-brainer 14.45.42 # <[7]> hm, so would the crashkernel approach we're doing on the nano2g be feasible for a) other targets, b) end users? 14.45.42 # It gives you the ability to print a speculative return stack on the screen easily 14.46.12 # [7]: I don't think *any* approach that involves doing something more trivial than typing in what they see ont he device's screen is going to have a lot of end user takeup 14.46.31 # We get a lot of people on the forum who type in what the panic screen says, including addresses/etc 14.46.39 # <[7]> well, dumping through mass storage would be more complex for us, but pretty much straightforward for the user 14.46.41 # They almost never respond to requests for any followup information 14.46.58 # especially if the way to get it involves following any instructions 14.47.11 # <[7]> print a text "please connect usb and attach dbginfo.dat to bug report" on the panic screen 14.47.32 # [7]: if you implemented that it would be neat, and some people would use it 14.47.34 # it would be awesome if we could write the dump to disk and just ask them for that 14.47.43 # but i suspect less people will bother than if it was just a couple more numbers on the screen 14.47.51 # of course this assumes 1) usb works :) 2) there is a computer not far away 3) user wants to do it 14.47.55 # <[7]> Torne: is it worth the ramsize overhead? 14.48.04 # <[7]> i'd estimate 16-32KB depending on the OTG 14.48.07 # [7]: the ram size of the unwinding thing wodz found is <4kb 14.48.19 # <[7]> well, the ramsize of my trivial dumper is <1KB 14.48.31 # what is that dumping to? 14.48.34 # store the dump in memory, then used a reserved bit to indecate there there is a dump there. reboot without flushing memory, allow the fresh kernel to check the bit, then dump to disk when its accessible? 14.49.06 # Viperfang: yup 14.49.09 # that's the other one. 14.49.14 # <[7]> Viperfang: that requires some reserved memory space for the dumper kernel 14.49.17 # but that's not possible on all devices 14.49.21 # [7]: No it doesn't 14.49.32 # <[7]> otherwise it will destroy some evidence 14.49.35 # it may not be possible to reset without killing the content of the ram 14.49.41 # wodz: yes, that's the problem 14.49.58 # Viperfang: lots of our devices we have no way to reset reliably without going through the OF's bootloader again 14.49.59 # <[7]> well, i've dumped lots of stuff through coldboot attacks on ipods :) 14.50.02 # which often reinitialises ram 14.50.14 # or just plain overwrites it :) 14.50.34 # <[7]> but i still don't see how rebooting gets you around the need for reserved crashkernel memory 14.50.43 # <[7]> and if you have that, you can just kexec it directly 14.50.51 # [7]: you don't need another kernel 14.51.03 # [7]: you just dump ram into somewhere boring 14.51.10 # like the end of the audio buffer 14.51.18 # write a magic word at a fixed physical address 14.51.19 # <[7]> yeah, but the something that does that needs some place to live in 14.51.19 # then reset 14.51.27 # huh? 14.51.35 # no, you just do it in abort context or whatever, from the panic handler 14.51.43 # <[7]> well, yeah, this is the "destroying evidence" method 14.51.49 # how does that destroy anything? 14.51.55 # <[7]> the important bit might have been where you copied the unimportant bits to 14.52.11 # but it won't be 14.52.33 # <[7]> that's a question of probabilities but if you want to be sure, you need to reserve some small amount of memory 14.52.49 # no, i don't think it is a question of probabilities 14.52.53 Quit bluefoxx_ (Ping timeout: 255 seconds) 14.53.06 Quit wodz (Quit: Leaving) 14.53.23 # if you use the audio buffer for example ? (the part which is used for audio data) 14.53.29 # <[7]> for the simple dumper crashkernel i'd go for the 1KB overhead. for a UMS-based one or dumping to disk it might be worth to go through a reset if at all possible 14.53.53 # i don't see how you can do anything useful or interesting in 1KB or whatever :) 14.54.00 # <[7]> pamaury: corrupted audio data (or memory corruption in general) might have been the cause of the crash 14.54.07 # if you want to save the complete state of RAM you need to reserve 50% of RAM 14.54.16 # <[7]> Torne: I have a full USB dumper crashkernel for the nano2g in <1KB 14.54.38 # argh 14.54.42 # but that doesn't do the same thing 14.54.51 # * Torne gives up 14.55.13 # <[7]> doesn't do which thing? dumping to disk or via UMS? 14.55.15 # but that's not suitable for the end user 14.55.29 # <[7]> well yeah, as i said, a UMS version might be slightly bigger 14.56.12 # <[7]> UMSboot is like 16KB but contains some unneccessary things, OTOH it has a rather easy-to-handle OTG 14.56.36 # <[7]> removing the LCD driver from that one might shave off quite some amount of ramsize 14.56.56 # what is UMSboot ? 14.57.11 # <[7]> a bootstrapping tool we use for the newer ipods 14.57.34 # <[7]> emulates a USB mass storage drive with fat16, allows the user to copy a file to it, and executes that file from DRAM start 14.58.03 # <[7]> that's what our exploit binaries contain :) 14.58.14 Join JdGord [0] (~AndChat@123-243-140-31.static.tpgi.com.au) 14.58.26 # it reimplements the usb driver ? 14.58.36 # <[7]> yes 14.58.52 # <[7]> or rather copy&pasted from rockbox/emcore/whatever 14.59.19 Join WalkGood [0] (~4@unaffiliated/walkgood) 14.59.41 # Anyway for most controllers you can greatly simplify the code if you know the purpose of it 15.00.15 # <[7]> guess how i managed to shrink my dumper to 1KB :) 15.00.30 # but still, the inconvenient is that you need a computer 15.00.51 # <[7]> writing to disk is not always a good solution though 15.01.04 # <[7]> (file system corruption could be the crash cause) 15.01.14 # yes I know, but the same for usb 15.01.28 Quit jdgord_ (Ping timeout: 276 seconds) 15.01.29 # <[7]> why that? 15.01.39 # <[7]> USB will need a PC, yes, but that's it 15.01.46 # if your usb code is buggy or you managed to put the usb controller is a strange state, the dumper will not work 15.02.09 # <[7]> thats why a rather trivial and well-tested dumper will completely reinitialize the USB core 15.03.03 # <[7]> there can of course always be a bug in the exception handler, but that's something that can be tested comparatively well 15.06.20 Quit B4gder (Quit: Konversation terminated!) 15.07.20 Quit antil33t (Read error: Connection reset by peer) 15.07.41 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 15.08.46 # also regarding the size of the "dumper" (whatever shape it would have), I think there is no point in crushing its size as most as possible since most recent targets have >32Mb of memory and rockbox.bin is already 600Kib in size 15.09.15 # <[7]> I'm fairly certain that 16KB will be doable at least with some OTGs 15.09.30 # <[7]> with thumb code probably even less 15.10.19 # <[7]> remember we've even managed to fit a readonly NAND+FTL+FAT32 driver into <4K on nano2g 15.10.38 # <[7]> but yeah, that was with both thumb and UCL 15.10.58 # as usual it depends on the hardware 15.11.01 # <[7]> it was a very tight fit, but in the end it worked 15.11.17 # <[7]> I like that hack :) 15.11.30 # <[7]> it allows us to install rockbox on a factory nano2g by just copying a single file to it and unplugging it 15.11.54 # <[7]> (bootstrapping through a buffer overflow exploit in the OF) 15.12.25 # <[7]> if that kind of thing can be done, i'm fairly sure that we can manage a mass storage memory dumper as well 15.12.45 # yeah such a hack is nice :) But if we are going to a general dumper, we can sacrifice size a bit to make it run on several targets 15.13.05 # <[7]> that highly depends on the target 15.15.02 # there is the device part and the OTG part 15.15.27 # you don't want to copy&paste the same OTG controller code for each device using it ! 15.16.15 # <[7]> i'm more worried about implementing the mass storage part, which will probably need to be forked from our current driver 15.16.24 # <[7]> the OTG part can probably be used unchanged 15.16.51 # yes the ums part will need to be changed 15.17.04 # most probably we want to emulate at the same time ums+fat 15.17.09 # <[7]> possibly ifdef out some unneeded stuff in the OTG drivers 15.17.56 # <[7]> fat is trivial, that's big mux based on the sector number being read 15.18.10 # yes 15.18.37 # <[7]> the first couple of sectors will be generated on the fly, containing the basic FS metadata, and all sector numbers above a certain threshold will just map to DRAM+IRAM linearly 15.19.37 # we want to dump registers too 15.20.05 # <[7]> those would just be dumped into some reserved space somewhere (end of DRAM?) 15.20.23 # you can reserve one sector for it in the fat 15.20.36 # <[7]> this would have to happen at the very start of the exception handler, which is still in the "old" kernel 15.20.51 # <[7]> otherwise rockbox's panic handler will have trashed the regs already 15.21.17 # Aren't the registers pushed on the stack or something ? 15.21.26 # <[7]> not all of them 15.21.40 # ok, then it needs to be done 15.21.44 # <[7]> probably none at all for the current non-recoverable panic handlers 15.22.13 # Torne: I don't know. I never added -g and could use the .elf just fine (like passing them to bloat-o-meter.py and it showed which symbols got bigger) 15.22.15 Quit dfkt|n (Ping timeout: 245 seconds) 15.22.23 *** Saving seen data "./dancer.seen" 15.22.28 # <[7]> so you'll have to dump them to memory somewhere anyway, and a fixed address at the end of RAM seems to be perfect for that 15.22.47 # <[7]> if you throw them on the stack, you might overflow it and corrupt other (important?) data 15.22.48 # kugel: symbols are not debugging information 15.22.49 # kugel: without -g so still get info about which functions are where because we generate a map 15.22.53 # kugel: symbols are symbols 15.23.00 # <[7]> and nobody really cares about ~160 bytes at the end of RAM 15.23.02 # an entirely different class of thing 15.23.24 # kugel: debug info is stack unwinding data, source line info, etc.. 15.23.37 # [7]: right, and that avoids reserving a sector 15.23.49 # <[7]> exactly 15.24.58 # Torne: oh, I thought you're only asking for the symbols for the backtrace 15.25.17 Quit mamarley (Remote host closed the connection) 15.25.19 # kugel: no, we want unwinding info to generate the *addresses* to show in teh backtrace 15.28.37 Quit mystica555_ (Read error: Operation timed out) 15.30.22 Quit mystica555 (Ping timeout: 248 seconds) 15.33.07 # so, who wants to implement that ? :D 15.34.02 # perhaps a discussion on the ML would be useful 15.35.34 Join mystica555_ [0] (~mike@71-211-199-174.hlrn.qwest.net) 15.37.55 Join ReimuHakurei [0] (~reimu@165.139.179.10) 15.41.22 Join mystica555 [0] (~Mike@71-211-199-174.hlrn.qwest.net) 15.44.15 Quit JdGord (Read error: Connection reset by peer) 15.49.01 Quit God_Eater (Ping timeout: 252 seconds) 15.49.45 Quit saratoga (Ping timeout: 252 seconds) 16.07.02 # * Zagor spots WindowManager.LayoutParams.FLAG_FULLSCREEN in android/src/org/rockbox/RockboxActivity.java 16.07.15 # Zagor: aha 16.07.48 # Zagor: we probably don't want that, no ;) 16.08.52 # but it will make all the screen sizes change :) 16.09.18 # yes, [Saint] will be extatic :) 16.09.54 Quit ReimuHakurei (Quit: Leaving...) 16.14.14 # I think we wanted to hadnle that by either pushing the rockbox framebuffer down, or simply not drawing where the android statusbar is 16.14.18 # or something like that 16.14.29 # so the screen size rockbox sees doesnt change 16.16.25 # i'm not sure why we want it not to change.. 16.16.36 # unles syou mean we want to support this being a setting 16.16.51 # i would be happy with it never being fullscreen, at which point the themes can just all be slightly smaller.. 16.17.38 Quit bieber (Remote host closed the connection) 16.19.19 # just to stop wierd screen sizes 16.19.33 # 480*754 or something 16.19.46 # and yeah, to make it a settings 16.19.46 # why is that particularly weird, compared to the random sizes we already have? 16.19.47 # -s 16.20.03 # is the android bar always the same size? 16.20.17 # probably not :) 16.21.47 # anyway, you will inevitably have weird sizes 16.21.48 # it isn't 16.21.59 # see honeycomb which has soft buttons permanently displayed 16.22.07 # and thus *no* app can use the full LCD size 16.22.21 # I hoped to implement it as "we don't draw into this area". of course that conflicts with themes, thus I wanted to make it configrable 16.22.27 # isn't it a fixed size for each resolution/dpi? 16.22.39 # Zagor: the combination of resolution and dpi, yes 16.22.52 # I even had it implemented (http://repo.or.cz/w/kugel-rb.git/shortlog/refs/heads/host_statusbar), however there's a glitch when enabling the bar 16.23.37 # anyway. just fyi, "full" fullscreen is not a thing in honeycomb 16.23.46 # and may not be on all devices in future either 16.23.55 # so weird sizes are guaranteed 16.24.20 # the part you can't ahve on honeycomb is substantially larger and also at the bottom 16.24.32 # yeah, the screen size is quite a hurde for the android app 16.24.54 # You might even have more than one edge you can't use :) 16.24.54 # sizes* :) 16.28.28 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 16.37.08 Join scanf [0] (~x32@unaffiliated/scanf) 16.37.20 # so i have rockbox on a fifth gen ipod video 16.37.28 # battery runs out 16.37.33 # i plug it into my USB charger 16.37.47 # it starts up, but its the default apple ipod crap 16.37.56 # but then when i reboot it it somehow is rockbox again 16.38.01 # what is this sorcery 16.38.36 # power on with hold on = boot to original firmware 16.38.55 # applies to power on by plugging in as well 16.44.28 Join Strife89 [0] (~Strife89@207.144.201.128) 16.44.51 # ah 16.48.43 Join matze` [0] (~pflaume@p5498A5A4.dip.t-dialin.net) 16.55.05 Quit user829385 (Max SendQ exceeded) 16.55.56 # git users: i hope you saw my mail to rockbox-dev. you need to change your remote url to keep using the current git mirror! 16.56.38 Quit evilnick (Quit: Leaving) 17.00.24 # Torne: that would be this mail? http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-09/0084.shtml 17.00.35 # yes 17.00.43 # er, no 17.00.51 # he one before :) 17.00.53 # http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-09/0083.shtml 17.00.54 # http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-09/0083.shtml 17.03.03 # Ah, OK. 17.03.55 # so, currently git://git.rockbox.org/rockbox refers to the old content, but that may change at any time, and the old content is permanently (kind of) available under git://git.rockbox.org/rockbox-old ? 17.04.02 # yes 17.04.21 # well, not any time. we will give people notice, i hope :) 17.05.42 Part Zagor 17.06.25 # once we get automatic mirroring using the new format then people should be able to move their work-in-progress over to that (via one of a variety of methods) 17.10.55 Quit n1s (Ping timeout: 244 seconds) 17.11.16 # * Torne tries to work out how to remove all the $Keyword%s 17.14.54 # "carefully", would appear to be the order of the day :) 17.18.10 Join dfkt|n [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at) 17.18.10 Quit dfkt|n (Changing host) 17.18.10 Join dfkt|n [0] (~dfkt@unaffiliated/dfkt) 17.22.27 *** Saving seen data "./dancer.seen" 17.40.30 # hah 17.40.38 # we had svn:keywords set on more than a few bitmaps. 17.40.46 # it's fun what i discover doing this stuff :) 17.43.48 Quit Farthen (Ping timeout: 240 seconds) 17.45.16 Join y4n [0] (y4n@unaffiliated/y4ndexx) 17.46.46 # [Saint]: where can i get a piece of this android ui rework i'm hearing about? 17.46.54 Join Farthen [0] (~Farthen@2a01:4f8:101:2a4:0:bc28:b2e1:9) 17.47.28 Quit dfkt|n (Ping timeout: 258 seconds) 17.48.07 # well, 2506 keywords deleted.. 17.48.12 # there are still a lot though 17.49.50 # many of them are in files that didn't have svn:keywords set :) 17.49.52 # so weren't being expanded 17.51.18 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.58.51 Join n1s [0] (~quassel@rockbox/developer/n1s) 18.00.25 # Torne: yeah, some people decided they were not going to follow the svn properties conventions and just ignored them because of broken tools 18.07.30 Quit matze` (Remote host closed the connection) 18.15.42 # how do you tell which 18.15.44 # er 18.15.46 # Do we care which $Id$ lines were from upstream sources and which are ours? :) 18.19.18 Join mortalis [0] (~4d6c62b0@www.haxx.se) 18.20.55 Join Keripo [0] (~Keripo@dhcp0751.kin.resnet.group.UPENN.EDU) 18.21.02 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.25.58 Quit Keripo (Read error: Connection reset by peer) 18.43.40 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 18.45.01 Join Keripo [0] (~Keripo@dhcp0751.kin.resnet.group.UPENN.EDU) 18.46.17 Quit Keripo (Read error: Connection reset by peer) 18.52.09 Join Keripo [0] (~Keripo@dhcp0751.kin.resnet.group.UPENN.EDU) 19.03.46 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 19.03.46 Quit jhMikeS (Changing host) 19.03.46 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 19.07.10 Quit mortalis (Quit: CGI:IRC) 19.09.59 Part WalkGood 19.11.49 # does some has an idea how to restore the filesystem (for the OF) of my Archos player? I tried a few variations on partition layout and mkfs.vfat parameters, but when the filesystem fills the player crashes 19.22.03 Join Horscht [0] (~Horscht@p5DD56838.dip.t-dialin.net) 19.22.03 Quit Horscht (Changing host) 19.22.03 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.22.30 *** Saving seen data "./dancer.seen" 19.27.05 Quit Keripo (Quit: Leaving.) 19.27.52 # Is there any work going on to fix the regressions after r30589? I'm seeing bug reports even at the anythingbutipod forums now 19.29.39 # <[Saint]> preglow: Sorry, I was asleep...bein' on the other side of the world 'n all... ;) 19.29.47 Join Horschti [0] (~Horscht@xbmc/user/horscht) 19.29.50 # <[Saint]> preglow: Here 'ya go - http://www.rockbox.org/tracker/task/12254 19.30.00 # how does that look like? http://imagebin.org/174325 19.30.54 # <[Saint]> Not bad. 19.32.01 # <[Saint]> Good, in fact. 19.32.26 # <[Saint]> (See, I can do compliments too...I'm not /always/ an asshole ;)) 19.33.00 Quit Horscht (Ping timeout: 244 seconds) 19.36.41 Join ReimuHakurei [0] (~reimu@165.139.179.10) 19.37.49 # that's list spacing with slightly smaller lines + line separators + 25px ubuntu font + the icons, the rest is your cabbie 19.37.58 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 19.38.18 # Zagor: http://imagebin.org/174325 :) 19.38.37 # kugel: looks German 19.39.24 # pressing ctrl+- thrice in firefox gives about the real size on my phoen 19.41.36 # kugel: is this the line space patch? 19.42.02 # that too yes 19.43.46 Join TheLemonMan [0] (~LemonBoy@ppp-30-34.26-151.libero.it) 19.44.12 # are the separating lines the correct color? they look a little bright. 19.44.47 # well, what's correct is to be decided :) 19.45.30 # it's what I did in the code. font color but darker (rgb each scaled down by 2) 19.46.20 Quit ReimuHakurei (Ping timeout: 252 seconds) 19.46.55 # "correct" defined as "same as native list" 19.47.17 # imo that looks far batter than http://imagebin.org/174329, and is usable too 19.47.58 # I didnt check the color but I don't think it needs to be the _same_ 19.48.22 # I agree, same is not vital. but a darker shade looks thinner, which is more appealing in my eyes 19.49.46 # darker is probably completely invisible at the top lines due to cabbies background. but I'm not at all opposed to making it darker 19.49.50 # I wouldn't say it's *far* better. it is a bit more native-like, which is a good thing. 19.50.04 # ah right, the background is faded.. 19.50.58 # I think the separators should extend further to the left. at least as far as the icons, possibly all the way. (native is all the way) 19.51.11 # i agree, it's just a first version 19.51.18 # but how does this coexist with themes? 19.51.36 # New commit by 03bertrik (r30611): FS#12282 - basque language improved by Asier Arsuaga 19.51.46 # I think they should extend to the most left (aligned to the title). in this case it'll still be offset a bit because the UI viewport starts at 12 19.52.38 # now I'm tempted to make a "native android" theme :) 19.53.24 # r30611 build result: 0 errors, 5 warnings (bertrik committed) 19.53.40 # <[Saint]> Zagor: Then, it would be best to not draw the seperators with the core, and do it with skinned lists. 19.53.58 # <[Saint]> kugel's approach here is already entirely possible without additional code. 19.54.50 # <[Saint]> If its implemented kugel's way, themes and/or the user need to be able to switch the seperators off. 19.55.03 # <[Saint]> themes definitely do. 19.55.12 # the core can provide a nicely usable default for *all* screens with being dependant on the theme 19.55.30 # skinned lists still need someone to make a theme for that very resolution 19.55.41 # <[Saint]> Right, but it needs to be able to be switched off...that's all I'm saying. 19.55.47 # kugel: yes, but we still *have* to ackomodate themes 19.55.49 # kugel: I like ;) 19.56.09 # it can be turned of in my current patch 19.56.24 # by the theme? 19.56.38 # <[Saint]> Theme's need to be able to override it, it'd to /good/ if users can too...not, necessary. 19.56.49 # <[Saint]> if that's possible, great, I've no complaints. 19.58.50 # http://pastie.org/2601133 is the current patch 19.58.55 Quit Horschti (Quit: Verlassend) 19.59.00 # Zagor: via a setting so yes 20.01.55 # <[Saint]> Hmmmm.... 20.02.04 # <[Saint]> there's no "setting_get" 20.02.15 # <[Saint]> that'd be sueful...I might look into that. 20.02.23 # <[Saint]> *useful too 20.02.54 # [Saint]: ? 20.03.15 # <[Saint]> setting_inc/dec/set/get (the latter not implemented yet) would make for some interesting uses in themes. 20.04.00 # <[Saint]> kugel: "%?if(setting_get,setting,value)" 20.04.13 # <[Saint]> for example. 20.04.37 Quit Xerion (Ping timeout: 256 seconds) 20.06.43 # [Saint]: %St is sure implemented 20.07.41 # <[Saint]> Ah....so it is. 20.07.57 # that's much older than the other settings stuff actually :) 20.07.59 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 20.08.45 # <[Saint]> setting_* foo is touch specific. 20.08.57 # <[Saint]> setting_get could still possible be usefyl. 20.09.08 # <[Saint]> *useful too 20.12.40 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 20.14.25 # commenting out FLAG_FULLSCREEN looks nice 20.14.28 Join Horscht [0] (~Horscht@p5DD572BB.dip.t-dialin.net) 20.14.28 Quit Horscht (Changing host) 20.14.28 Join Horscht [0] (~Horscht@xbmc/user/horscht) 20.14.59 # * [Saint] shakes a fist at zagor! ;) 20.15.14 # heh, yeah 20.15.32 # <[Saint]> *thankfully*, its not too much of an issue, just a minor PITA 20.15.35 # <[Saint]> ;) 20.15.46 Join Biont [0] (~bc66d9ba@www.haxx.se) 20.15.51 # Hello :) 20.18.33 # I'm trying to wrap my head around the "skin breaking change" in the wps syntax. Sadly, the theme I made back in my D2 days did not survive the automatic conversion. Does anyone know common problems that break the converted themes? 20.18.52 # status bars are 38, 25 and 19 pixels high for high, medium and low density screens 20.19.04 # <[Saint]> touch area changes, biont. 20.19.11 # <[Saint]> the * and & system has changed. 20.19.23 # <[Saint]> whoops... Biont: ^ 20.20.13 # So it would be wise to start there when trying to fix the converted wps/sbs? 20.20.21 # <[Saint]> Biont: http://www.rockbox.org/wiki/CustomWPS#Touchscreen_areas 20.21.00 # Thank you. Very nice interesting by the way. I had a look at them yesterday 20.21.06 # <[Saint]> specifically, take a look at "pepeat_press, long_press, and the new allow_while_locked" 20.21.10 # err "Very interesting changes" 20.21.28 # <[Saint]> *repeat_press", too 20.22.01 # <[Saint]> repeat_press and long_press replace * and & 20.22.25 # I don't have any of that in my wps. Or did these replace something I might have in there? 20.23.05 # <[Saint]> You said D2, right...touchscreen? 20.23.43 # <[Saint]> the touchscreen syntax changed with regard to long press and repeat press. That _should_ be all that changed specific to touchscreen. 20.24.03 # alright 20.24.46 # btw, does the sbs support touch areas by now? 20.25.07 # <[Saint]> Biont: AFAIK, it always has. 20.26.14 # <[Saint]> An example of the changes for you: "%T(4,4,120,120,*hotkey)" is now "%T(4,4,120,120,hotkey,long_press)" 20.26.36 # <[Saint]> "%T(4,4,120,120,&hotkey)" is now "%T(4,4,120,120,hotkey,repeat_press)" 20.28.01 # <[Saint]> and if you used !volume its now going to be volume,reverse_bar 20.28.05 # just to make sure we're on the same page: we're talking about this, are we? http://www.rockbox.org/wiki/SkinBreakingChange Your example syntax looks like you're talking about another change I'm not even aware of :D 20.28.33 # <[Saint]> Oh....hell, you theme is *that* old :-S 20.28.40 # <[Saint]> *your 20.28.50 # It apparently is :) 20.29.06 # <[Saint]> And yes, the changes I mention here also apply, and aren't listed there. 20.29.25 # <[Saint]> So you'll need to take them into account also. 20.29.29 # okay 20.31.18 # Well, I sold my D2 a year ago and now I'm trying to make my theme work on my htc wildfire again..the skin updater sure saved me a big headache, but I still don't know why it doesn't work. It's been a terribly long time since I *knew* all that stuff as well :/ 20.31.51 # <[Saint]> the skin updater script isn't up to date with current changes to the skin syntax. 20.32.01 # <[Saint]> namely the touch areas (and possible other tags) 20.32.16 # although the buttons were always there), so the problem must be something different. I'll report back when I have an actual question to ask, okay? 20.32.28 # <[Saint]> Sure ;) 20.32.56 # don't we have screen width/height tag? 20.33.08 # This web client likes to eat parts of my messages oO 20.33.18 # <[Saint]> Zagor: A skin tag? 20.33.37 # <[Saint]> If yes, no. 20.33.47 # yes, couldn't that be used to make skins semi-adaptive? 20.34.16 Join Jerom [0] (~jerome@2a02:8420:215:f000:f66d:4ff:fe45:790f) 20.35.30 # <[Saint]> I can't think of how...the binary itself should know what size notification bar to expect by checking its screen size. 20.35.54 # <[Saint]> the theme shouldn't need to do this checkign. 20.36.37 Join low_light [0] (48db2090@gateway/web/freenode/ip.72.219.32.144) 20.36.39 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 20.37.16 # but that means having umpteen different themes for all odd sizes. if the theme could adapt to minor differences we could perhaps cut down that number. 20.37.50 # so, have some kind of layout manager? :P 20.37.54 # <[Saint]> but the theme can't adapt to all odd sizes. 20.38.06 # <[Saint]> you casn't load/unload a backdrop conditionally 20.38.15 # <[Saint]> *can't 20.38.47 # But you can scale it or crop it 20.39.39 # [Saint]: no, not *all* sizes. but at least for example the various variations of each size. such as the 800 height that comes in 762, 775, 781, 816, 829 and 835 pixel heights 20.39.48 # I can't remember now, can viewports get negative positions? 20.40.01 # <[Saint]> gevaerts: Sure. 20.40.55 # are the current crop of 10-inch tablets configured as high, low or medium-dpi screens? 20.41.15 # <[Saint]> There's *presently* no way for a theme to check the screen height/width. 20.41.23 # <[Saint]> this magic could probably be added. 20.41.31 # <[Saint]> that's Jd's domain, though. 20.41.34 # maybe you could add a layout-policy to a viewport to make it expand to the screen and distribute its elements for example 20.41.53 # * gevaerts will help think about this more when he's back at a real keuboard 20.42.09 # bertrik: yes, that could be done with simple tag arithmetic. 20.42.13 # I think we should have percentage or android's density-independant-pixel units in skins 20.43.16 # Zagor: rockboxdev.sh fails with the sunet.se gnu mirror because the gcc releases are located in "gcc/releases/" 20.43.23 # <[Saint]> Why make it Android specific? Presently all "Application" themes should "just work". 20.43.31 # yes we need to add *some* dynamic handling 20.43.34 # <[Saint]> Assuming the other ports ever make something of themselves. 20.43.54 # low_light: right. *grumbles* I'll fix it. thanks. 20.44.05 # <[Saint]> Maemo, Pandora, etc. 20.45.35 # [Saint]: why application specific. all themes just should work :P 20.46.34 # having themes scale from 1280x720 to 96x64 can be a bit challenging :) 20.48.25 Join webguest20 [0] (~4d6c62b0@www.haxx.se) 20.49.02 # [Saint]: no worries mate, looking forward to giving it a whirl 20.49.03 Quit webguest20 (Client Quit) 20.49.53 # my thinking was that with simple width/4 arithmetic, current tags could basically take percent without having to be rewritten 20.50.30 # though I haven't written a wps in *years* so I don't remember how we stand on such things 20.51.33 # [Saint]: did you see I posted the patch? 20.51.35 # <[Saint]> I think Jd looked into it and it seemed simple in theory and bloody hard in practice ;) 20.51.49 # would be nice if you gave it a try to see if the reduced line height is better 20.52.10 # [Saint]: hmm :( 20.52.12 # <[Saint]> kugel: I did, yeah...but there's not a lot I can do with it apart from look at it and say "Oh, that's nice". 20.52.17 # it's a bit too small but I could live with it 20.52.31 # +for me 20.52.43 # <[Saint]> I'm not doing my own builds at the present. 20.56.39 Quit Horscht (Quit: Verlassend) 21.00.16 # low_light: unfortunately no mirror will work right now because gnu.org screwed up the binutils dir. 21.00.42 # [Saint]: fwiw, I don't think the default theme should override this list spacing 21.00.48 # if it gets in 21.03.44 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 21.09.42 # Zagor: Downloading binutils from the sunet.se mirror via rockboxdev.sh worked fine earlier. It seems sunet doesn't "mirror" the gnu/gcc directory, they added an additional "releases" subdir. 21.10.50 # oh right, binutils is only broken for sh. I'll commit a new mirror. 21.11.26 Join ReimuHakurei [0] (~reimu@165.139.179.10) 21.14.43 # hm, maybe we should host that stuff ourselves 21.15.21 # or would that get too heavy on the data usage? 21.19.29 # New commit by 03zagor (r30612): sunet mirror was bad. let's try funet. 21.19.59 # no I don't think it would be too bad. but it just feels wrong. there's a huge number of mirrors already. 21.20.25 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 21.20.57 # r30612 build result: 0 errors, 5 warnings (zagor committed) 21.22.33 *** Saving seen data "./dancer.seen" 21.23.13 Quit ReimuHakurei (Quit: Linkinus - http://linkinus.com) 21.24.51 # do language string tags still exist? Has anything changed about them? 21.25.15 # I have some lines like this " %al%s%?ia<%ia|%Sx(Unknown)> " 21.25.28 # looks like they got converted badly 21.25.43 # BTW, 86 seconds! 21.25.49 # hey bertrik, those are your warnings 21.25.54 # well, not exactly, but these lines break the wps nonetheless 21.26.46 # * bertrik denies everything 21.34.09 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) 21.36.39 Part low_light 21.39.28 # [Saint]: we need the volume popup in the menus too. is that doable? 21.40.09 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.44.18 # another oddity: scrolling the settings lists changes the setting. highly non-obvious. 21.45.14 # <[Saint]> that _shouldn't_ happen. 21.45.34 # <[Saint]> Perhaps you're hitting the setting prior to scrolling? 21.45.35 # not to mention the select bar being visible at all times is quite non-android-style 21.46.02 # <[Saint]> ANd no, I can't do a volume popup in the menus. 21.46.09 # [Saint]: yes, I go into volume (for example) and scroll up and down to see the values. the volume changes as I scroll, with no visual feedback at all 21.46.34 # I mean no feedback that the volume is actually changed due to just me scrolling the list 21.46.34 # <[Saint]> Hmmmmm, I haven't tried with volume. 21.46.45 # I also tried with bass and treble. same thing. 21.47.14 # <[Saint]> That is rather non-obvious. And, wrong. 21.47.25 # <[Saint]> I'm pretty confident other lists don't do this. 21.47.33 # <[Saint]> Max playlist, for one. 21.48.48 # we also need to get started on a manual for android 21.49.32 # <[Saint]> thankfully its pretty much already there. (all the contents, rather) just need to murder one of the touchscreen manuals. 21.50.08 Quit liar (Remote host closed the connection) 21.50.09 # * [Saint] is *not* a TeX guru, though. 21.50.14 # yes. though I'd like to add some "being an app"-specific bits 21.50.26 # <[Saint]> Right. 21.52.19 Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 21.52.51 Quit bluefoxx_ (Read error: Connection reset by peer) 21.55.29 Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 21.55.31 Quit bluefoxx (Ping timeout: 276 seconds) 21.55.36 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.05.29 # Strife89, I think I was probably wrong thinking that the PMU settings affected USB working or not on AMSv2 22.06.01 # bertrik: Ah, so the most recent patch doesn't really work? 22.06.21 # how do I make a screenshot in raaa? the usb trick doesn't seem to work. 22.06.55 # Strife89, I'm not certain, I thought it had some effect, but at other times USB just worked also without the patch 22.07.31 # part of the patch has been committed already by the way, just not the part of it that increases some of the voltages inside the clip+ 22.08.25 # [Saint]: I like this look of the sbs: http://pastebin.com/L8uKnByG (only play controls + adjusted for android status bar) 22.08.38 # One of the changes I can imagine having an effect, is lowering the USB detection threshold voltage from 4.5V to 3.18V (IIRC) 22.09.01 # oh, that diff became bigger than necessary 22.09.13 # bertrik: Assuming a clean checkout, then, is it possible to apply any of those patches and get USB operational on my Clip+? 22.10.45 # You need some changes to enable USB on AMSv2 anyway, and to do all of the PMU init the OF does you need to change an #if 0 into an #if 1 in system-as3525.c 22.11.20 Quit bluefoxx_ (Ping timeout: 255 seconds) 22.11.34 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) 22.11.59 # wps tags can be nested, right? so can't we just add simple plus, minus, div, mul tags? 22.12.36 # Zagor: they can't in general. A tag has to be coded specially to take the output value of another tag 22.12.51 # I'd like to see that changed too :) 22.12.56 # :( 22.13.14 # bertrik: Sorry, but where is the file? 22.13.20 Quit TheLemonMan (Quit: WeeChat 0.3.5) 22.13.50 # * [Saint] hands Strife89 grep 22.14.06 # line 284 in firmware/target/arm/as3525/system-as3525.c 22.14.15 # * Strife89 keeps forgetting how useful grep is 22.15.21 # Anyway, any other changes needed? 22.19.05 Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu) 22.19.12 Join mshathlonxp [0] (msh@87.110.20.30) 22.23.14 Quit y4n (Quit: only amiga makes it possible) 22.23.19 # You need to enable rockbox USB in firmware/export/config/sansaclipplus.h but that's already in the FS task I think 22.23.33 # You can experiment a bit with the #if 0/1 in system-as3525.c 22.23.45 # hum, how do I transfer files to virtual android machines? 22.25.43 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 22.25.44 # bertrik: I haven't applied anything from the FS task yet. 22.26.50 # Am I correct that if we want to do stackbacktrace from exception handler we need first switch to supervisor mode? 22.26.56 # on ARM I mean 22.26.58 Quit benedikt93 (Quit: Bye ;)) 22.28.58 # Strife89, this is what I use to enable USB on clip+ : http://pastebin.ca/2083328 22.29.30 # wodz: you mean because the registers are shadowed? 22.29.43 # yes 22.30.09 # * ukleinek opens ARMARM 22.30.11 # all our stack setups I saw so far uses IRQ stack in exception 22.30.12 # bertrik: So you only change two lines? 22.30.20 # oh, great, some abort on the clip+ and the display goes dark after the bootloader 22.30.40 # wtf is Playlist Catalogue? 22.31.01 # * Zagor learns about adb push 22.31.48 # * Strife89 compiles with fingers crossed. 22.32.05 # same symptom as the guy on abi after r30589 22.32.31 # I'm really starting to think of reverting that, and r30590 and r30591 22.32.41 # mshathlonxp: it's something that's been described in the manual for ages 22.32.55 # damnit, can't JdGordon just ever get a commit right in 1 try? 22.33.00 # o_O 22.33.08 # * mshathlonxp is adding missing lines to latvian translation 22.33.19 # why it is at the end of the file then? 22.33.55 Join gbl08ma [0] (~gbl08ma@195.23.214.31) 22.35.10 # hi. I'm conneting to this channel just to inform that the problems that I reported some days ago regarding some themes' WPS not loading on nano2g, is solved after the fixes on SVN build 22.36.05 # thanks. now iLike and photoSkins work properly, and I didn't even need to change the amount of RAM allocated to the themes (by editing the new macgic file under .rockbox) 22.36.08 # wodz: I think you need to walk the stack in exception mode first and when that ends switch to svc and walk there, too 22.36.42 Quit GermanMushroom (Quit: Ik ga weg) 22.37.07 # s/svc/mode in SPSR/ 22.37.23 # mshathlonxp: at the end of what file? 22.37.44 # lang file 22.38.17 Quit gbl08ma (Client Quit) 22.38.27 # ukleinek: why? 22.39.12 Join fml [0] (~chatzilla@manz-590f1519.pool.mediaWays.net) 22.39.39 # * gevaerts can't find anything that matches whatever mshathlonxp is trying to say 22.40.16 # LANG_SET_AS_PLAYLISTCAT_DIR for example - wasn't it added recently? 22.40.28 # speaking about the magic file: will the commit be reverted? What it does is done in a very unusual way. 22.40.46 Quit mamarley (Remote host closed the connection) 22.40.58 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 22.41.18 # mshathlonxp: Ah, right. That particular setting was added recently, yes. 22.42.22 Join low_light [0] (48db2090@gateway/web/freenode/ip.72.219.32.144) 22.42.26 Join ReimuHakurei [0] (~reimu@208.119.81.194) 22.42.39 Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu) 22.42.50 Join mamarley_ [0] (~quassel@Lee-08-199.rh.ncsu.edu) 22.42.54 Quit mamarley_ (Remote host closed the connection) 22.44.37 # bertrik: ... Well, fuck. It blacked out on me, too. 22.45.05 # hold power for 15s or so, then boot while holding LEFT to return to the OF 22.45.23 # Way ahead of you there. :) 22.46.24 Quit liar (Quit: hallowed are the ori!) 22.46.34 # lulz 22.46.41 Join saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113) 22.46.48 # playlist catalog was renamed to playlist catalogue 22.46.52 # :D 22.47.07 # and I was wondering why I haven't noticed that name yet... :D 22.47.07 # JdGordon: maybe its a good idea to revert the font commit until we have a better idea whats going on with some players? 22.49.13 # bertrik: Using #if 0 and rebuilding. 22.49.22 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 22.49.53 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.49.54 # saratoga: I meant the commit that introduced a magic file to init the skin buffer 22.50.42 # saratoga: (if if were following up on me) 22.51.13 # fml: no haven't read the logs 22.51.14 # wodz: what's your theory? 22.51.36 # [Saint]: here's a screenshot too: http://imagebin.org/174417 22.51.52 Quit n1s (Remote host closed the connection) 22.52.12 # ukleinek: about what? 22.53.08 # Holy CRAP that's a high-res Cabbie 22.53.11 Quit ReimuHakurei (Quit: Leaving...) 22.53.28 # heh yeah I don't know how to make the emulator do 1:1 pixel mapping 22.53.52 # Zagor: my first impression is that icons are too close to the text. (I do not use android.) 22.53.54 # it's not terribly far off though 22.54.14 # fml: yes. my change is the playback buttons at the bottom. 22.54.55 # saint's theme has volume, shuffle and repeat buttons squeezed in there too which I think is cramped an not so pretty 22.55.34 # plus, of course, this screenshot shows the android status bar.. 22.55.34 # wodz: about how to do the backtrace 22.55.45 # Zagor: OK. Just so that the other know :-) Also, I think that the icons are of different sizes. E.g. the "Resume playback" icon looks smaller than "Playlist catalogue" 22.56.34 # Well, I understant that technically they are of the same size, but the look as if they were different 22.57.01 # Zagor: I'd agree with not putting volume, shuffle, and repeat down there. Shuffle and repeat at least, both seem like something you wouldn't want to change often or suddenly 22.57.04 # fml: yes 22.57.09 # The stack unwinder I provided link before should be straight forward to use in rockbox. Basically we would need to implement __current_sp() and change __return_address() to __builtin_return_address(0) 22.57.23 # Volume is a little more of a gray area, I don't know how many Android phones have dedicated volume buttons. 22.57.24 # The question is if we are interested 22.57.40 # I don't think I've seen any without 22.58.26 # Zagor: If you're in Rockbox, and you use the phone's volume buttons, do you get "rockbox sized" volume steps, or "phone sized" volume steps? 22.58.33 # i think they all do so far 22.58.37 # Basically, is there a reason why the onscreen volume controls would b preferable in general? 22.58.39 # ukleinek: read back irclogs - I provided link to some (maybe suitable) solution for ARM 22.58.40 # in rockbox, you get "rockbox steps" 22.58.57 # Alright, then I'm perfectly okay with dropping the onscreen volume controls there too. 22.59.37 # I 23.00.01 # I'd like us to get a volume popup in the menus too, like you get in the wps (and like you get in android) 23.00.57 # Is Rockbox volume its own separate thing, or is changing Rockbox volume just changing the "media" volume in Android? 23.01.01 # otherwise our small volume steps can easily be interpreted as non-functioning buttons 23.01.42 # Llorean: we coexist. basically we use our pcm volume to create many small steps between the bigger android steps 23.02.05 # I'm quite proud of it :) 23.02.13 # Zagor: Interesting. I mean, for practical purpose, as long as I can get the volume as quiet as I'd like, I'm mostly happy 23.02.47 # But there are times where I listen to media *and* play games. Most games have their own volume slider, but it helps if both my media and my game can be adjusted relative to the overall volume. 23.03.02 # Still, sounds "good enough" for me, at least 23.03.06 # Bah, can't manage to revert r30589,r30590,r30591 anymore 23.03.38 Join ReimuHakurei [0] (~reimu@208.119.81.194) 23.03.39 # we had a debate about that and the general consensus was that fully independent volume control would be too "technical" and confusing 23.05.15 # wodz: yeah saw, but didn't read it. 23.05.30 # Odd. An awful lot of apps (not media players, though) seem to have fully independent volume control 23.06.13 # New commit by 03fredwbauer (r30613): Delay settings_reset() until after font_init(). Fixes boot crash on Fuze(v1) and probably others. 23.06.24 # svn -r . 23.07.53 # r30613 build result: All green 23.07.54 # Llorean: I can't say I've seen many, actually 23.09.26 Join freddyb [0] (~freddybbb@216.8.239.112.etczone.com) 23.10.47 # bertrik: did that fix your boot problem? 23.10.52 Quit fml (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214]) 23.11.02 # freddyb, yes it seems so 23.11.27 # oh wait no 23.11.38 # bertrik: Related to the patch or something else? 23.18.31 # I was hoping I had fixed FS#12292. 23.18.32 # http://www.rockbox.org/tracker/task/12292 3Sansa Clip+: Cannot boot since r30589 with real target (bugs, unconfirmed) 23.18.42 Quit domonoky (Read error: Connection reset by peer) 23.19.34 # Ah 23.22.35 *** Saving seen data "./dancer.seen" 23.22.59 # Well, shit. I didn't back up my old build. 23.23.18 # bertrik: can you tell if it at least got farther into boot? 23.24.24 Part Zagor 23.25.40 Quit low_light () 23.26.34 Quit liar (Remote host closed the connection) 23.27.04 # freddyb, actually it does seem to fix trunk, but trunk + usb patch appears to boot only once, next boot is shows a dark display after the bootloader 23.27.05 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.30.34 # gotcha 23.32.15 # freddyb, thanks for the fix so far, I'll go get my clip+ back in usable state ... 23.34.45 # Strife89, well, so much for trying USB on AMSv2 ... :( goodnight! 23.34.52 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 23.35.13 Quit liar (Quit: hallowed are the ori!) 23.35.32 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.38.35 Join blind [0] (~blind@c-71-235-61-84.hsd1.ct.comcast.net) 23.39.06 # hey im not sure what generation it is.. the short square ipod nano - I'm assuming that's not 2G and not supported? 23.40.00 # http://support.apple.com/kb/ht1353 23.42.13 # we do support the Nano 2G, but its not remotely square :) 23.43.43 # so what's the plan with audio library GSOC outcome? 23.44.38 # i want to get it merged into rockbox 23.48.13 # Getting screen corruption in r30610 on ipod6g 23.49.38 # ah, it's 3G - just making sure because i'd hate to be wrong, but 3g nano isn't supported? 23.50.10 # Scratch that, cant reproduce 23.50.49 # Is there a way to add a reboot option to the system menu? 23.51.09 Quit ReimuHakurei (Ping timeout: 260 seconds) 23.51.41 Nick scanf is now known as doesntcare (~x32@unaffiliated/scanf) 23.51.45 Nick doesntcare is now known as scanf (~x32@unaffiliated/scanf) 23.53.11 Join FlynDice [0] (~jack@c-24-19-225-90.hsd1.wa.comcast.net) 23.53.37 Quit Jerom (Quit: Leaving.) 23.54.59 # freddyb: You fix works just fine for my clip+ now. Thanx... 23.55.19 # You're welcome! 23.57.23 # Viperfang: you can "play" the rockbox binary and it will ROLO. 23.58.36 Quit wodz (Ping timeout: 260 seconds)