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:00 |
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:00 |
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 |
03:00:36 | | Quit Keripo (Ping timeout: 276 seconds) |
03:02:37 | CIA-14 | New commit by fredwbauer (r30610): Do not move NULL pointers in buflibmove_callback(). Fixes some skin crashes when changing themes. |
03:04:33 | CIA-14 | r30610 build result: All green |
03:22:11 | *** | Saving seen data "./dancer.seen" |
03:39:17 | JdGordon | [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 | JdGordon | 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 | JdGordon | dont they all use the same font size? |
03:43:40 | [Saint] | What? No...shit no. |
03:43:52 | JdGordon | DAMN NO! FUCK NO! |
03:43:56 | JdGordon | 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 | JdGordon | I don't want those string in the lang file |
03:46:48 | JdGordon | 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 | JdGordon | 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 | JdGordon | 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 | JdGordon | "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 | JdGordon | 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 | JdGordon | err... hmm... |
03:54:15 | JdGordon | 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 | JdGordon | 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 | JdGordon | what was none used for? |
03:57:58 | [Saint] | I use it to fire the pop-ups |
03:58:16 | JdGordon | 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 | JdGordon | cant they be set directly from %T? |
03:59:05 | JdGordon | ok, no |
03:59:11 | [Saint] | Nah, they can't. |
03:59:17 | [Saint] | Ah, too late. |
04:00 |
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 | JdGordon | 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 | JdGordon | try http://pastebin.com/rWc8kjvX |
04:02:55 | JdGordon | the issue was none was returning ACTION_TOUCHSCREEN which is the same action that gets returned if no region is pressed |
04:03:35 | JdGordon | 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:00 |
05:18:20 | JdGordon | [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 |
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 |
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 | JdGordon | [Saint]: did you try the patch? |
07:55:00 | | Quit [Saint] (Ping timeout: 252 seconds) |
08:00 |
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:00 |
09:07:14 | kugel | [Saint]: I was very happy with 24x24. don't you think 28x28 is too big? |
09:07:49 | kugel | 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:00 |
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 | kugel | [Saint]: the icons |
10:28:09 | kugel | 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 | kugel | touchscreen presses give results immediately because the coordinates change |
10:29:45 | kugel | that's why none is timing out so early |
10:31:11 | kugel | 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 | kugel | 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 | God_Eater | I would imagine that depends on the scaling algorithm |
10:32:17 | God_Eater | colour bleeding usually hurts that a lot |
10:32:39 | kugel | like if 480x800 is X then 320x4800 must be Y (where Y is simply scaled down from X and the resolution) |
10:32:54 | kugel | 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 | kugel | mockup on your desktop lcd? |
10:34:35 | pixelma | 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 | kugel | [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 | pixelma | [Saint]: sorry I wasn't clear - I eant the horizontal spacing between scrollbar, icons and menu items |
10:37:50 | pixelma | meant too |
10:37:55 | | Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) |
10:38:03 | pixelma | not the vertical spacing at all... |
10:39:04 | pixelma | 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 | pixelma | 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 | pixelma | 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 | pixelma | no need for a code solution |
10:49:31 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
10:51:42 | pixelma | 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:00 |
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 | Llorean | 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 | Llorean | Does RaaA adjust android's media volume, or does it adjust Rockbox's volume relative to android's media volume? |
11:06:40 | kugel | also it's not a dB scale in RaaA :) |
11:06:43 | pixelma | 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:00 |
12:18:47 | | Quit nick-p (Quit: Leaving) |
12:59:48 | | Quit casainho (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110905174115]) |
13:00 |
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 | rf | hi |
13:39:19 | rf | 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 | rf | ok |
13:40:38 | rf | hope i do not annoy you with that question |
13:40:43 | rf | 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 | linuxstb | 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 | rf | Lyre is nice |
13:52:52 | rf | 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 | Torne | doesn't the beagleboard have atrocious sound? |
13:56:22 | Torne | 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 | Torne | 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:00 |
14:05:06 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
14:06:24 | wodz | 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 | pamaury | wodz: we can also compile in debug mode and use the dwarf compiler output |
14:11:31 | Torne | pamaury: this is unwinding on device, though |
14:11:43 | pamaury | yes, same thing on device |
14:11:55 | Torne | uh |
14:11:59 | Torne | that would be massive :) |
14:12:18 | pamaury | one would need to check, most of the debug info useless and could be stripped |
14:12:24 | Torne | no, i mean the code to hadnle it |
14:12:51 | pamaury | I don't think so, we don't need to handle the full dwarf spec |
14:13:35 | pamaury | I'm not saying it's free of course :) |
14:14:25 | | Join JdGord [0] (~AndChat@106.71.69.95) |
14:14:51 | Zagor | we could have an address->function resolver on the web site |
14:15:31 | pamaury | Zagor: that's pretty much useless without backtrace most of the time no ? |
14:15:32 | Torne | Zagor: that's not very useful |
14:15:38 | Torne | unless you save entire stacks |
14:15:48 | Torne | and most people have nowhere to write those to |
14:15:53 | Torne | since that pretty much requires serial |
14:15:54 | Zagor | I mean for multiple addresses |
14:16:05 | Torne | Right, but you don't know which things are addresses |
14:16:13 | Torne | so you end up having to display the entire stack on the screen |
14:16:17 | Zagor | ...for a stack trace |
14:16:42 | Zagor | as opposed to needing full debug symbols in the builds |
14:16:49 | Torne | oh |
14:16:51 | Torne | this isn't about symbols |
14:16:54 | Torne | this is about .debug_frame |
14:17:00 | Torne | the cfi data to unwind the stack |
14:17:40 | pamaury | yes |
14:17:50 | pamaury | I'm trying a debug build to see the size |
14:18:18 | Torne | i think the more interesting part is "how big a binary is libunwind" :) |
14:19:03 | Torne | dwarf's actual encoding is weird and scary and i wouldn't want to implement it |
14:19:31 | pamaury | 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 | pamaury | hey, why the f+ debug build fails on undefined reference to `H_TO_BE32' ?? |
14:20:37 | Torne | pamaury: it is pretty incomprehensible.. |
14:20:44 | Torne | pamaury: the CFI format is only part of it.. |
14:20:53 | pamaury | yes I know |
14:21:45 | pamaury | but if you only want to stack trace, I *think* it's ok, I might be wrong though |
14:22:04 | pamaury | I think someone broke the debug builds |
14:22:21 | pamaury | clip+ build: rockbox/apps/recorder/pcm_record.c:1674: undefined reference to `H_TO_BE32' |
14:22:44 | pamaury | can someone else try a debug build ? |
14:23:04 | [7] | smells like a missing include |
14:23:25 | Torne | you don't realyl want a debug build, do you? |
14:24:49 | pamaury | Torne: does the compiler generate dwarf info in all cases ? |
14:24:49 | pamaury | indeed, H_TO_BE32 is compiled out in debug build |
14:24:58 | Torne | if not then we should do |
14:25:02 | Torne | because it's cheap and useful |
14:25:56 | [7] | what about implementing post-mortem memory dumps on some more targets? |
14:26:09 | Torne | 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 | Torne | pamaury: it doesn't, no, but it should. plz fix :) |
14:27:53 | Torne | sensible debug builds change nothing except #defines |
14:28:00 | Torne | we can jsut do -g always |
14:28:56 | pamaury | Torne: I'm willing to fix it but why the hell is it compiled out and nobody noticed ? |
14:29:04 | Torne | hm? |
14:29:09 | Torne | because people never build non-debug builds with -g |
14:29:17 | Torne | even though you should :) |
14:29:36 | pamaury | I'm talking about H_TO_BE32 ! |
14:29:41 | Torne | 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 | Torne | nobody builds with DEBUG defined |
14:30:10 | Torne | i meant, please fix that you don't get symbols when you aren't building debug |
14:30:17 | pamaury | 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 | pamaury | 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 | kugel | 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 | pamaury | [7]: strange, I don't find any reference to it in apps/ :-/ |
14:32:00 | pamaury | and only one in firmware/ : the define itself |
14:32:20 | Torne | kugel: so you don't have to go back and recompile everything when you want debug info? |
14:32:41 | kugel | 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 | Torne | no, debug info is not a loadable section |
14:33:01 | Torne | objcopy will just ignore it |
14:33:06 | pamaury | 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 | Torne | kugel: the point is to leave it all in the ELF binary |
14:33:36 | pamaury | but we do have a htob32 |
14:33:38 | Torne | 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 | pamaury | some info: fuze+ debug build: |
14:34:28 | pamaury | .debug_frame: 75Kib |
14:34:45 | Torne | right |
14:34:54 | Torne | so even if the code to decode it is free that's pretty large |
14:35:03 | pamaury | .debug_info: 1.2Mib |
14:35:12 | Torne | you can implement a basic unwinder for ARM in under 4kb as wodz's link does :) |
14:35:18 | Torne | ARM is really, really easy to unwind by hand |
14:35:19 | pamaury | we need .debug_info but we wan't to strip most of it |
14:35:35 | kugel | Torne: I never compile with -g (explicitely) but the .elf output is just fine |
14:35:43 | Torne | thanks to the function prolog/epilog being completely predictable |
14:35:52 | Torne | kugel: ..huh? |
14:35:52 | [7] | just get the data off the device and analyze it on a pc |
14:36:02 | Torne | [7]: The point is for *end users* |
14:36:09 | Torne | 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 | Torne | so we can print, say, 5 addresses |
14:36:25 | Torne | or whatever fits on the screen |
14:36:31 | Torne | and know that they are probably the right ones |
14:36:44 | Torne | kugel: if you don't compile with -g you don't get debug info |
14:37:28 | Torne | 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 | pamaury | How does the wodz's link work ? |
14:38:17 | Torne | pamaury: it just disassembles a few interesting arm instructions and follows execution backwards |
14:38:34 | Torne | The format of a functoin on ARM is so predictable that you don't need any actual unwinding data at all |
14:38:35 | pamaury | you can't to that reliably can you ? |
14:38:48 | Torne | For gcc-generated code you can do it with basically 100% accuracy |
14:38:52 | Torne | for assembler it might miss a few |
14:40:03 | Torne | 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 | Torne | pamaury: you just take the value of lr and "jump" there, starting to "execute" instructions until you hit the function epilog |
14:41:40 | Torne | you can ignore almost all instructions, so your emulator can be really stupid |
14:41:59 | Torne | 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 | Torne | then repeat |
14:42:20 | [7] | and a simple crashkernel fits in 1KiB of memory |
14:42:25 | Torne | some minor caution for tail calls is about all you need :) |
14:42:30 | pamaury | this assumes the stack is allocated/freed at once, is that an abi requirement ? |
14:42:44 | Torne | 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 | Torne | That only ever happens in handwritten assembler, though, srsly |
14:43:36 | Torne | 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 | wodz | so maybe this worth a try to extend our panic screen? |
14:45:24 | Torne | 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 | Torne | It gives you the ability to print a speculative return stack on the screen easily |
14:46:12 | Torne | [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 | Torne | 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 | Torne | They almost never respond to requests for any followup information |
14:46:58 | Torne | 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 | Torne | [7]: if you implemented that it would be neat, and some people would use it |
14:47:34 | n1s | it would be awesome if we could write the dump to disk and just ask them for that |
14:47:43 | Torne | but i suspect less people will bother than if it was just a couple more numbers on the screen |
14:47:51 | pamaury | 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 | Torne | [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 | Torne | what is that dumping to? |
14:48:34 | Viperfang | 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 | Torne | Viperfang: yup |
14:49:09 | Torne | that's the other one. |
14:49:14 | [7] | Viperfang: that requires some reserved memory space for the dumper kernel |
14:49:17 | Torne | but that's not possible on all devices |
14:49:21 | Torne | [7]: No it doesn't |
14:49:32 | [7] | otherwise it will destroy some evidence |
14:49:35 | wodz | it may not be possible to reset without killing the content of the ram |
14:49:41 | Torne | wodz: yes, that's the problem |
14:49:58 | Torne | 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 | Torne | which often reinitialises ram |
14:50:14 | Torne | 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 | Torne | [7]: you don't need another kernel |
14:51:03 | Torne | [7]: you just dump ram into somewhere boring |
14:51:10 | Torne | like the end of the audio buffer |
14:51:18 | Torne | 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 | Torne | then reset |
14:51:27 | Torne | huh? |
14:51:35 | Torne | 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 | Torne | 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 | Torne | 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 | Torne | 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 | pamaury | 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 | Torne | 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 | Torne | 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 | Torne | argh |
14:54:42 | Torne | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | Anyway for most controllers you can greatly simplify the code if you know the purpose of it |
15:00 |
15:00:15 | [7] | guess how i managed to shrink my dumper to 1KB :) |
15:00:30 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | there is the device part and the OTG part |
15:15:27 | pamaury | 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 | pamaury | yes the ums part will need to be changed |
15:17:04 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | Aren't the registers pushed on the stack or something ? |
15:21:26 | [7] | not all of them |
15:21:40 | pamaury | 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 | kugel | 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 | Torne | kugel: symbols are not debugging information |
15:22:49 | pamaury | kugel: without -g so still get info about which functions are where because we generate a map |
15:22:53 | Torne | kugel: symbols are symbols |
15:23:00 | [7] | and nobody really cares about ~160 bytes at the end of RAM |
15:23:02 | Torne | an entirely different class of thing |
15:23:24 | Torne | kugel: debug info is stack unwinding data, source line info, etc.. |
15:23:37 | pamaury | [7]: right, and that avoids reserving a sector |
15:23:49 | [7] | exactly |
15:24:58 | kugel | 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 | Torne | 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 | pamaury | so, who wants to implement that ? :D |
15:34:02 | pamaury | 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:00 |
16:07:02 | * | Zagor spots WindowManager.LayoutParams.FLAG_FULLSCREEN in android/src/org/rockbox/RockboxActivity.java |
16:07:15 | Torne | Zagor: aha |
16:07:48 | Torne | Zagor: we probably don't want that, no ;) |
16:08:52 | Torne | but it will make all the screen sizes change :) |
16:09:18 | Zagor | yes, [Saint] will be extatic :) |
16:09:54 | | Quit ReimuHakurei (Quit: Leaving...) |
16:14:14 | JdGordon | 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 | JdGordon | or something like that |
16:14:29 | JdGordon | so the screen size rockbox sees doesnt change |
16:16:25 | Torne | i'm not sure why we want it not to change.. |
16:16:36 | Torne | unles syou mean we want to support this being a setting |
16:16:51 | Torne | 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 | JdGordon | just to stop wierd screen sizes |
16:19:33 | JdGordon | 480*754 or something |
16:19:46 | JdGordon | and yeah, to make it a settings |
16:19:46 | Torne | why is that particularly weird, compared to the random sizes we already have? |
16:19:47 | JdGordon | -s |
16:20:03 | JdGordon | is the android bar always the same size? |
16:20:17 | Torne | probably not :) |
16:21:47 | Torne | anyway, you will inevitably have weird sizes |
16:21:48 | kugel | it isn't |
16:21:59 | Torne | see honeycomb which has soft buttons permanently displayed |
16:22:07 | Torne | and thus *no* app can use the full LCD size |
16:22:21 | kugel | 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 | Zagor | isn't it a fixed size for each resolution/dpi? |
16:22:39 | Torne | Zagor: the combination of resolution and dpi, yes |
16:22:52 | kugel | 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 | Torne | anyway. just fyi, "full" fullscreen is not a thing in honeycomb |
16:23:46 | Torne | and may not be on all devices in future either |
16:23:55 | Torne | so weird sizes are guaranteed |
16:24:20 | Torne | the part you can't ahve on honeycomb is substantially larger and also at the bottom |
16:24:32 | Zagor | yeah, the screen size is quite a hurde for the android app |
16:24:54 | Torne | You might even have more than one edge you can't use :) |
16:24:54 | kugel | 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 | scanf | so i have rockbox on a fifth gen ipod video |
16:37:28 | scanf | battery runs out |
16:37:33 | scanf | i plug it into my USB charger |
16:37:47 | scanf | it starts up, but its the default apple ipod crap |
16:37:56 | scanf | but then when i reboot it it somehow is rockbox again |
16:38:01 | scanf | what is this sorcery |
16:38:36 | maraz | power on with hold on = boot to original firmware |
16:38:55 | maraz | applies to power on by plugging in as well |
16:44:28 | | Join Strife89 [0] (~Strife89@207.144.201.128) |
16:44:51 | scanf | ah |
16:48:43 | | Join matze` [0] (~pflaume@p5498A5A4.dip.t-dialin.net) |
16:55:05 | | Quit user829385 (Max SendQ exceeded) |
16:55:56 | Torne | 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 |
17:00:24 | Lalufu | Torne: that would be this mail? http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-09/0084.shtml |
17:00:35 | Torne | yes |
17:00:43 | Torne | er, no |
17:00:51 | Torne | he one before :) |
17:00:53 | Torne | http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-09/0083.shtml |
17:00:54 | Zagor | http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-09/0083.shtml |
17:03:03 | Lalufu | Ah, OK. |
17:03:55 | Lalufu | 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 | Torne | yes |
17:04:21 | Torne | well, not any time. we will give people notice, i hope :) |
17:05:42 | | Part Zagor |
17:06:25 | Torne | 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 | Torne | "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 | Torne | hah |
17:40:38 | Torne | we had svn:keywords set on more than a few bitmaps. |
17:40:46 | Torne | 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 | preglow | [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 | Torne | well, 2506 keywords deleted.. |
17:48:12 | Torne | there are still a lot though |
17:49:50 | Torne | many of them are in files that didn't have svn:keywords set :) |
17:49:52 | Torne | 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 |
18:00:25 | n1s | 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 | Torne | how do you tell which |
18:15:44 | Torne | er |
18:15:46 | Torne | 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:00 |
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 | ukleinek | 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 | bertrik | 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 | kugel | 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 | kugel | 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 | kugel | Zagor: http://imagebin.org/174325 :) |
19:38:37 | ukleinek | kugel: looks German |
19:39:24 | kugel | pressing ctrl+- thrice in firefox gives about the real size on my phoen |
19:41:36 | Zagor | kugel: is this the line space patch? |
19:42:02 | kugel | that too yes |
19:43:46 | | Join TheLemonMan [0] (~LemonBoy@ppp-30-34.26-151.libero.it) |
19:44:12 | Zagor | are the separating lines the correct color? they look a little bright. |
19:44:47 | kugel | well, what's correct is to be decided :) |
19:45:30 | kugel | 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 | Zagor | "correct" defined as "same as native list" |
19:47:17 | kugel | imo that looks far batter than http://imagebin.org/174329, and is usable too |
19:47:58 | kugel | I didnt check the color but I don't think it needs to be the _same_ |
19:48:22 | Zagor | I agree, same is not vital. but a darker shade looks thinner, which is more appealing in my eyes |
19:49:46 | kugel | 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 | Zagor | I wouldn't say it's *far* better. it is a bit more native-like, which is a good thing. |
19:50:04 | Zagor | ah right, the background is faded.. |
19:50:58 | Zagor | 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 | kugel | i agree, it's just a first version |
19:51:18 | Zagor | but how does this coexist with themes? |
19:51:36 | CIA-14 | New commit by bertrik (r30611): FS #12282 - basque language improved by Asier Arsuaga |
19:51:46 | kugel | 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 | Zagor | now I'm tempted to make a "native android" theme :) |
19:53:24 | CIA-14 | 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 | kugel | the core can provide a nicely usable default for *all* screens with being dependant on the theme |
19:55:30 | kugel | 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 | Zagor | kugel: yes, but we still *have* to ackomodate themes |
19:55:49 | GodEater | kugel: I like ;) |
19:56:09 | kugel | it can be turned of in my current patch |
19:56:24 | Zagor | 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 | kugel | http://pastie.org/2601133 is the current patch |
19:58:55 | | Quit Horschti (Quit: Verlassend) |
19:59:00 | kugel | Zagor: via a setting so yes |
20:00 |
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 | kugel | [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)<foo|bar>" |
20:04:13 | [Saint] | for example. |
20:04:37 | | Quit Xerion (Ping timeout: 256 seconds) |
20:06:43 | kugel | [Saint]: %St is sure implemented |
20:07:41 | [Saint] | Ah....so it is. |
20:07:57 | kugel | 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 | Zagor | 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 | Zagor | 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 | Biont | Hello :) |
20:18:33 | Biont | 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 | Zagor | 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 | Biont | 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 | Biont | 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 | Biont | 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 | Biont | 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 | Biont | alright |
20:24:46 | Biont | 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 | Biont | 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 | Biont | 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 | Biont | okay |
20:31:18 | Biont | 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 | Biont | 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 | Zagor | don't we have screen width/height tag? |
20:33:08 | Biont | 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 | Zagor | 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 | Zagor | 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 | bertrik | 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 | gevaerts | But you can scale it or crop it |
20:39:39 | Zagor | [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 | gevaerts | I can't remember now, can viewports get negative positions? |
20:40:01 | [Saint] | gevaerts: Sure. |
20:40:55 | Zagor | 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 | bertrik | 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 | Zagor | bertrik: yes, that could be done with simple tag arithmetic. |
20:42:13 | kugel | I think we should have percentage or android's density-independant-pixel units in skins |
20:43:16 | low_light | 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 | Zagor | yes we need to add *some* dynamic handling |
20:43:34 | [Saint] | Assuming the other ports ever make something of themselves. |
20:43:54 | Zagor | low_light: right. *grumbles* I'll fix it. thanks. |
20:44:05 | [Saint] | Maemo, Pandora, etc. |
20:45:35 | kugel | [Saint]: why application specific. all themes just should work :P |
20:46:34 | Zagor | 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 | preglow | [Saint]: no worries mate, looking forward to giving it a whirl |
20:49:03 | | Quit webguest20 (Client Quit) |
20:49:53 | Zagor | my thinking was that with simple width/4 arithmetic, current tags could basically take percent without having to be rewritten |
20:50:30 | Zagor | though I haven't written a wps in *years* so I don't remember how we stand on such things |
20:51:33 | kugel | [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 | kugel | would be nice if you gave it a try to see if the reduced line height is better |
20:52:10 | Zagor | [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 | kugel | it's a bit too small but I could live with it |
20:52:31 | kugel | +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 |
21:00:16 | Zagor | low_light: unfortunately no mirror will work right now because gnu.org screwed up the binutils dir. |
21:00:42 | kugel | [Saint]: fwiw, I don't think the default theme should override this list spacing |
21:00:48 | kugel | if it gets in |
21:03:44 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
21:09:42 | low_light | 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 | Zagor | 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 | bertrik | hm, maybe we should host that stuff ourselves |
21:15:21 | bertrik | or would that get too heavy on the data usage? |
21:19:29 | CIA-14 | New commit by zagor (r30612): sunet mirror was bad. let's try funet. |
21:19:59 | Zagor | 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 | CIA-14 | 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 | Biont | do language string tags still exist? Has anything changed about them? |
21:25:15 | Biont | I have some lines like this " %al%s%?ia<%ia|%Sx(Unknown)> " |
21:25:28 | Biont | looks like they got converted badly |
21:25:43 | bertrik | BTW, 86 seconds! |
21:25:49 | Zagor | hey bertrik, those are your warnings |
21:25:54 | Biont | 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 | Zagor | [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 | Zagor | 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 | Zagor | 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 | Zagor | [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 | Zagor | 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 | Zagor | 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 | Zagor | 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 | Zagor | 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:00 |
22:05:29 | bertrik | Strife89, I think I was probably wrong thinking that the PMU settings affected USB working or not on AMSv2 |
22:06:01 | Strife89 | bertrik: Ah, so the most recent patch doesn't really work? |
22:06:21 | Zagor | how do I make a screenshot in raaa? the usb trick doesn't seem to work. |
22:06:55 | bertrik | 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 | bertrik | 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 | Zagor | [Saint]: I like this look of the sbs: http://pastebin.com/L8uKnByG (only play controls + adjusted for android status bar) |
22:08:38 | bertrik | 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 | Zagor | oh, that diff became bigger than necessary |
22:09:13 | Strife89 | 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 | bertrik | 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 | Zagor | wps tags can be nested, right? so can't we just add simple plus, minus, div, mul tags? |
22:12:36 | gevaerts | Zagor: they can't in general. A tag has to be coded specially to take the output value of another tag |
22:12:51 | gevaerts | I'd like to see that changed too :) |
22:12:56 | Zagor | :( |
22:13:14 | Strife89 | 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 | bertrik | line 284 in firmware/target/arm/as3525/system-as3525.c |
22:14:15 | * | Strife89 keeps forgetting how useful grep is |
22:15:21 | Strife89 | 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 | bertrik | 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 | bertrik | You can experiment a bit with the #if 0/1 in system-as3525.c |
22:23:45 | Zagor | 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 | Strife89 | bertrik: I haven't applied anything from the FS task yet. |
22:26:50 | wodz | Am I correct that if we want to do stackbacktrace from exception handler we need first switch to supervisor mode? |
22:26:56 | wodz | on ARM I mean |
22:26:58 | | Quit benedikt93 (Quit: Bye ;)) |
22:28:58 | bertrik | Strife89, this is what I use to enable USB on clip+ : http://pastebin.ca/2083328 |
22:29:30 | ukleinek | wodz: you mean because the registers are shadowed? |
22:29:43 | wodz | yes |
22:30:09 | * | ukleinek opens ARMARM |
22:30:11 | wodz | all our stack setups I saw so far uses IRQ stack in exception |
22:30:12 | Strife89 | bertrik: So you only change two lines? |
22:30:20 | bertrik | oh, great, some abort on the clip+ and the display goes dark after the bootloader |
22:30:40 | mshathlonxp | wtf is Playlist Catalogue? |
22:31:01 | * | Zagor learns about adb push |
22:31:48 | * | Strife89 compiles with fingers crossed. |
22:32:05 | bertrik | same symptom as the guy on abi after r30589 |
22:32:31 | bertrik | I'm really starting to think of reverting that, and r30590 and r30591 |
22:32:41 | gevaerts | mshathlonxp: it's something that's been described in the manual for ages |
22:32:55 | bertrik | damnit, can't JdGordon just ever get a commit right in 1 try? |
22:33:00 | mshathlonxp | o_O |
22:33:08 | * | mshathlonxp is adding missing lines to latvian translation |
22:33:19 | mshathlonxp | why it is at the end of the file then? |
22:33:55 | | Join gbl08ma [0] (~gbl08ma@195.23.214.31) |
22:35:10 | gbl08ma | 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 | gbl08ma | 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 | ukleinek | 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 | ukleinek | s/svc/mode in SPSR/ |
22:37:23 | gevaerts | mshathlonxp: at the end of what file? |
22:37:44 | mshathlonxp | lang file |
22:38:17 | | Quit gbl08ma (Client Quit) |
22:38:27 | wodz | 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 | mshathlonxp | LANG_SET_AS_PLAYLISTCAT_DIR for example - wasn't it added recently? |
22:40:28 | fml | 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 | gevaerts | 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 | Strife89 | bertrik: ... Well, fuck. It blacked out on me, too. |
22:45:05 | bertrik | hold power for 15s or so, then boot while holding LEFT to return to the OF |
22:45:23 | Strife89 | Way ahead of you there. :) |
22:46:24 | | Quit liar (Quit: hallowed are the ori!) |
22:46:34 | mshathlonxp | lulz |
22:46:41 | | Join saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113) |
22:46:48 | mshathlonxp | playlist catalog was renamed to playlist catalogue |
22:46:52 | mshathlonxp | :D |
22:47:07 | mshathlonxp | and I was wondering why I haven't noticed that name yet... :D |
22:47:07 | saratoga | 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 | Strife89 | 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 | fml | saratoga: I meant the commit that introduced a magic file to init the skin buffer |
22:50:42 | fml | saratoga: (if if were following up on me) |
22:51:13 | saratoga | fml: no haven't read the logs |
22:51:14 | ukleinek | wodz: what's your theory? |
22:51:36 | Zagor | [Saint]: here's a screenshot too: http://imagebin.org/174417 |
22:51:52 | | Quit n1s (Remote host closed the connection) |
22:52:12 | wodz | ukleinek: about what? |
22:53:08 | Strife89 | Holy CRAP that's a high-res Cabbie |
22:53:11 | | Quit ReimuHakurei (Quit: Leaving...) |
22:53:28 | Zagor | heh yeah I don't know how to make the emulator do 1:1 pixel mapping |
22:53:52 | fml | Zagor: my first impression is that icons are too close to the text. (I do not use android.) |
22:53:54 | Zagor | it's not terribly far off though |
22:54:14 | Zagor | fml: yes. my change is the playback buttons at the bottom. |
22:54:55 | Zagor | 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 | Zagor | plus, of course, this screenshot shows the android status bar.. |
22:55:34 | ukleinek | wodz: about how to do the backtrace |
22:55:45 | fml | 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 | fml | Well, I understant that technically they are of the same size, but the look as if they were different |
22:57:01 | Llorean | 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 | Zagor | fml: yes |
22:57:09 | wodz | 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 | Llorean | Volume is a little more of a gray area, I don't know how many Android phones have dedicated volume buttons. |
22:57:24 | wodz | The question is if we are interested |
22:57:40 | Zagor | I don't think I've seen any without |
22:58:26 | Llorean | 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 | Torne | i think they all do so far |
22:58:37 | Llorean | Basically, is there a reason why the onscreen volume controls would b preferable in general? |
22:58:39 | wodz | ukleinek: read back irclogs - I provided link to some (maybe suitable) solution for ARM |
22:58:40 | Zagor | in rockbox, you get "rockbox steps" |
22:58:57 | Llorean | Alright, then I'm perfectly okay with dropping the onscreen volume controls there too. |
22:59:37 | Zagor | I |
23:00 |
23:00:01 | Zagor | 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 | Llorean | Is Rockbox volume its own separate thing, or is changing Rockbox volume just changing the "media" volume in Android? |
23:01:01 | Zagor | otherwise our small volume steps can easily be interpreted as non-functioning buttons |
23:01:42 | Zagor | Llorean: we coexist. basically we use our pcm volume to create many small steps between the bigger android steps |
23:02:05 | Zagor | I'm quite proud of it :) |
23:02:13 | Llorean | 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 | Llorean | 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 | Llorean | Still, sounds "good enough" for me, at least |
23:03:06 | bertrik | Bah, can't manage to revert r30589,r30590,r30591 anymore |
23:03:38 | | Join ReimuHakurei [0] (~reimu@208.119.81.194) |
23:03:39 | Zagor | 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 | ukleinek | wodz: yeah saw, but didn't read it. |
23:05:30 | Llorean | Odd. An awful lot of apps (not media players, though) seem to have fully independent volume control |
23:06:13 | CIA-14 | New commit by fredwbauer (r30613): Delay settings_reset() until after font_init(). Fixes boot crash on Fuze(v1) and probably others. |
23:06:24 | Strife89 | svn -r . |
23:07:53 | CIA-14 | r30613 build result: All green |
23:07:54 | Zagor | 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 | freddyb | 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 | bertrik | freddyb, yes it seems so |
23:11:27 | bertrik | oh wait no |
23:11:38 | Strife89 | bertrik: Related to the patch or something else? |
23:18:31 | freddyb | I was hoping I had fixed FS #12292. |
23:18:32 | fs-bluebot | http://www.rockbox.org/tracker/task/12292 Sansa Clip+: Cannot boot since r30589 with real target (bugs, unconfirmed) |
23:18:42 | | Quit domonoky (Read error: Connection reset by peer) |
23:19:34 | Strife89 | Ah |
23:22:35 | *** | Saving seen data "./dancer.seen" |
23:22:59 | Strife89 | Well, shit. I didn't back up my old build. |
23:23:18 | freddyb | 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 | bertrik | 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 | freddyb | gotcha |
23:32:15 | bertrik | freddyb, thanks for the fix so far, I'll go get my clip+ back in usable state ... |
23:34:45 | bertrik | 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 | blind | 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 | Torne | http://support.apple.com/kb/ht1353 |
23:42:13 | saratoga | we do support the Nano 2G, but its not remotely square :) |
23:43:43 | wodz | so what's the plan with audio library GSOC outcome? |
23:44:38 | saratoga | i want to get it merged into rockbox |
23:48:13 | Viperfang | Getting screen corruption in r30610 on ipod6g |
23:49:38 | blind | ah, it's 3G - just making sure because i'd hate to be wrong, but 3g nano isn't supported? |
23:50:10 | Viperfang | Scratch that, cant reproduce |
23:50:49 | Viperfang | 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 | FlynDice | freddyb: You fix works just fine for my clip+ now. Thanx... |
23:55:19 | freddyb | You're welcome! |
23:57:23 | freddyb | Viperfang: you can "play" the rockbox binary and it will ROLO. |
23:58:36 | | Quit wodz (Ping timeout: 260 seconds) |