Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2011-09-25

00:00:14 Join Rob2223 [0] (~Miranda@p5DE4BFA3.dip.t-dialin.net)
00:00:53 Quit pamaury (Remote host closed the connection)
00:02:26 Quit Keripo (Ping timeout: 256 seconds)
00:02:29 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
00:03:45amiconnkugel: Do you have an idea what might be going wrong there?
00:03:46*amiconn is lost in the talk/ buflib/ tagtree init maze
00:03:54 Quit Rob2222 (Ping timeout: 245 seconds)
00:06:16 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped)
00:09:23 Join Topy44 [0] (~Topy44@f049198255.adsl.alicedsl.de)
00:10:22 Quit T44 (Ping timeout: 256 seconds)
00:20:43 Join natedev [0] (~18f619de@www.haxx.se)
00:22:15natedevhey is there any infrastructure for doing kernal prints or application prints and storing them to a log file? How about sending them over USB to a tool to display them in realtime?
00:26:12 Quit gbl08ma__ (Quit: Saindo)
00:27:48 Join T44 [0] (~Topy44@f049010140.adsl.alicedsl.de)
00:31:42 Quit Topy44 (Ping timeout: 248 seconds)
00:33:53 Quit n1s (Remote host closed the connection)
00:40:33 Quit pamaury (Read error: Connection reset by peer)
00:47:34kugelamiconn: no
00:50:21kugeltalk is very badly integrated in general
00:55:43 Quit petur (Quit: Leaving)
01:00
01:06:18 Join Topy [0] (~Topy44@f048004114.adsl.alicedsl.de)
01:06:52 Quit natedev (Quit: CGI:IRC (EOF))
01:09:34 Quit T44 (Ping timeout: 248 seconds)
01:14:30 Quit scorche (Disconnected by services)
01:14:44 Join scorche` [0] (~scorche@rockbox/administrator/scorche)
01:16:18 Join freddyb [0] (~freddybbb@rrcs-24-123-73-214.central.biz.rr.com)
01:16:35 Quit freddyb (Client Quit)
01:20:57*amiconn is even more puzzled
01:21:08***Saving seen data "./dancer.seen"
01:22:14amiconnkugel: Apparently the hang on target since r30312 which doesn't affect the sim has been fixed in r30380. The crash problem which also affects the sim if voice is enabled & present appears somewhere between r30380 and r30386
01:22:24amiconnProbably r30381 - will test
01:26:44amiconnErr, 30381 and 30382 don't build
01:27:42amiconnOkay, and 30379 hangs
01:28:26amiconnSo r30380 fixes the hang (which hence doesn't need to be tracked down), and r30381 (+2+3) introduces the crash
01:29:35amiconnThe sim only crashes when voice is enabled and a matching voice file is present. Target also crashes if either doesn't apply, but then it crashes at another address. It's probably still related
01:30:20 Join FlynDice [0] (~FlynDice@107.63.246.240)
01:35:59FlynDiceHello old friends... r30595 is crashing on the clip+ The bootloader flashes Rockbox and then I get a dark screen and have to reset with a long power press. Don't have time to pinpoint a revision now but didn't see a report yet. I've installed it 2 times with same result.
01:36:32 Quit FlynDice (Quit: Gotta go fly!)
01:36:46kugelamiconn: when does it crash exactly?
01:37:01amiconnAt boot, while the boot screen is displayed
01:38:07kugelso at init?
01:38:35amiconnYes, precisely in tagtree_init() - but only if coice is enabled & matching voice file present
01:38:45amiconns/coice/voice/
01:39:33kugeloh I thought that was the hang, sorry
01:39:42*kugel confused the problems for a moment
01:40:03kugelright, get_tag() crashes because of bad pointer
01:40:22amiconnNo. I don't know where the hang happened exactly, as it didn't happen in the sim and it doesn't give an address on target
01:40:29kugelI suspect the memory gets overwritten
01:40:35kugelperhaps by talk buffer or so
01:41:19amiconnYes. I bet it will crash a little earlier on target as well (same place as in the sim) if I enable memory guard
01:42:41amiconnProblem is that target won't catch out-of-bounds accesses because there's no mmu. Address space 0x0000nnnn can normally be accessed without destroying anything, as it is rom space, but of course without the desired end result
01:42:57kugeltalk.c should receive its buffer from mpeg.c
01:43:01amiconnmemory guard *can* catch accesses to the rom area
01:45:44amiconnHmm, unfortunately it won't tell us much because there is no backtrace
01:45:58amiconnIt will probably crash in something like strcpy()
01:46:13amiconnSo the sim is a better choice
01:48:46 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.)
01:50:03 Join AlexP [0] (~alex@rockbox/staff/AlexP)
01:51:36kugelamiconn: bt full shows a bit more (bad pointer for dest for strcpy)
01:52:13amiconnI already reported that earlier here too (by setting a breakpoint and printing the variable)
01:53:46amiconntagtree gets its memory block from buflib iiuc, and talk.c does too (shared with mpeg.c for hwcodec)
01:53:50 Quit Topy (Ping timeout: 248 seconds)
01:55:33 Join Topy44 [0] (~Topy44@g228232240.adsl.alicedsl.de)
01:56:34amiconnSo something is going wrong within buflib, and it has been introduced when enabling compaction
01:58:38kugelprinting the result of core_get_data() shows that it's chaning between invocations
01:59:59kugelhm, inspecting core_ctx (what core_* wraps around) gives strange results
02:00
02:01:43kugelerr
02:01:58kugelthe very first tagtree_alloc() call allocs 9MB
02:02:47kugelah nvm
02:02:49amiconnHow can it allocate more memory than there is?
02:04:09kugelvoicebuf and p_thumbnail are still NULL, so I don't know
02:06:04kugelhmmm
02:06:38 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche)
02:07:02kugelamiconn: the first tagtree_alloc0 call destroys buflibs handle table :\
02:08:17amiconnThe question is why it only does that when voice is present. talk_init() is called from settings_apply() uuic, and that's called before tagtree_init()
02:09:01kugelcore_alloc_maximum() returns 0 for tagtree_bufsize but still a valid handle???
02:09:10amiconnHmm, or perhaps it also does that when voice is not present, just the effect is slightly different. Might explain the other crash I saw on target with voice disabled
02:09:31amiconn(somewhere in font code)
02:09:54 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/)
02:11:33 Join T44 [0] (~Topy44@f049108086.adsl.alicedsl.de)
02:14:22kugelamiconn: because talk_init() calls audio_get_buffer() if a voicefile is present
02:14:38 Quit Topy44 (Ping timeout: 248 seconds)
02:15:15kugelwhich calls core_alloc_maximum()
02:15:27kugelthat's so early that further calls to that fail, like the one in tagtree
02:21:32amiconnVoice on hwcodec is special in that it can (should) be thrown out of ram if something else (like playback) needs the buffer
02:22:19kugelaudio_get_buffer() behave differently between sw and hwcodec
02:26:33kugelamiconn: this should fix it http://pastie.org/2586810
02:27:44 Quit dfkt|n ()
02:28:03 Quit bieber (Ping timeout: 256 seconds)
02:28:42kugelI can't remember if there was some reason to make audio_get_buffer behave that way on hwcodec
02:31:06amiconnHmm, this fixes the crash in tagtree_init(), but not the second crash :/
02:31:23amiconnUnfortunately I haven't been able to reproduce the second on in the sim
02:31:39kugel:(
02:32:39kugelwhere is that one?
02:32:50amiconnIn font_unload() near the beginning
02:34:08kugelperhaps introduced with JdGordon's commit?
02:36:01*amiconn tries r30588 with kugel's fix
02:36:14JdGordongevaerts: %xd(label, %LI, 1) will fix your off by one issue
02:36:33 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
02:37:13 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com)
02:37:19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
02:37:38amiconnBleh, r30588 + fix hangs :(
02:39:30kugeljust tried r30584 and it doesn't hang in the sim
02:40:20amiconnYeah, sim didn't hang with r30312..r30379 which hung on target too
02:40:31JdGordonLalufu: BUTTON_RC_PLAY is proobably mapped to ACTION_STD_OK in the keymap file
02:42:47amiconnI will try to track down where it hangs exactly, unless someone beats me to it
02:43:13kugelI need to go to bed
02:43:42amiconnJdGordon: font in buflib crashes on hwcodec (unaligned access in font_unload() during boot). Currently covered by another (earlier) crash which kugel just pasted the fix for
02:49:25 Nick soap_ is now known as soap (~soap@rockbox/staff/soap)
02:56:41 Quit liar (Remote host closed the connection)
03:00
03:06:18 Join Topy [0] (~Topy44@f048133111.adsl.alicedsl.de)
03:10:06 Quit T44 (Ping timeout: 248 seconds)
03:10:21JdGordon[saint] you kill me sometimes! :/
03:10:32JdGordontouch tags arent rejected on non touch targets
03:10:36JdGordonthey are *ignored*
03:11:08JdGordonrecording tags are rejected, but if you use the recroding *feature* tag they wont get parsed so it will work
03:13:46JdGordonas for comments allocing buffer.. yeah, thats a bug, though i havnt looked into it very much, it absolutly shouldnt be as the code for that is #ifdefed out on ROCKBOX builds
03:18:25 Quit MethoS- (Read error: Connection reset by peer)
03:21:11***Saving seen data "./dancer.seen"
03:23:51 Quit mystica555 (Ping timeout: 276 seconds)
03:28:12 Join mystica555 [0] (~mike@71-211-199-174.hlrn.qwest.net)
03:35:14 Join T44 [0] (~Topy44@f049235155.adsl.alicedsl.de)
03:38:54 Quit Topy (Ping timeout: 248 seconds)
03:47:52 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
03:50:09 Quit Jak_o_Shadows (Ping timeout: 245 seconds)
04:00
04:40:40 Quit amiconn (Disconnected by services)
04:40:40 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:40:40 Quit pixelma (Disconnected by services)
04:40:42 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:40:44 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:41:02 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:43:42 Quit simonlnu (Quit: bbl)
04:45:35 Quit [7] (Disconnected by services)
04:45:46 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
04:46:27 Quit mamarley (Remote host closed the connection)
04:55:52 Join mamarley [0] (~quassel@2001:470:5:84d:221:6aff:fe19:4d0c)
04:59:45soaphow much pain will I feel migrating from Ubuntu 32 to Ubuntu 64?
04:59:56soapi want to give my VM more RAM.
05:00
05:12:01Jak_o_Shadows1I guess the first step in making a port is to figure out what cpu, rom, ram, file-system structure the device has?
05:21:15***Saving seen data "./dancer.seen"
05:38:27 Quit T44 (Read error: Connection reset by peer)
05:39:07 Join Topy44 [0] (~Topy44@f049235155.adsl.alicedsl.de)
05:56:23 Join Rob2222 [0] (~Miranda@p5DE4B69B.dip.t-dialin.net)
06:00
06:01:10 Quit Rob2223 (Ping timeout: 276 seconds)
06:48:42 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
06:51:18 Quit Jak_o_Shadows1 (Ping timeout: 260 seconds)
07:00
07:06:34 Join simonlnu [0] (~simon@unaffiliated/simonrvn)
07:21:19***Saving seen data "./dancer.seen"
07:48:55 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
07:51:04 Quit Jak_o_Shadows (Ping timeout: 256 seconds)
08:00
08:10:05 Quit powell14ski (Quit: powell14ski)
08:49:35 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
08:51:00 Quit Jak_o_Shadows1 (Ping timeout: 245 seconds)
09:00
09:02:37 Join y4n [0] (y4n@unaffiliated/y4ndexx)
09:17:34 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
09:21:24***Saving seen data "./dancer.seen"
09:43:38CIA-14New commit by 03jdgordon (r30596): Partial fix for FS #12289 - comment lines would waste lots of buffer space. Still not perfect but should get 90+% of comments completly ignored now.
09:45:43CIA-14r30596 build result: All green
09:50:16 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
09:52:43 Quit Jak_o_Shadows (Ping timeout: 260 seconds)
09:53:46 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
09:56:00 Join stooo [0] (~sto@g226141003.adsl.alicedsl.de)
09:56:06 Quit stooo (Client Quit)
09:56:46 Join n1s [0] (~quassel@rockbox/developer/n1s)
10:00
10:12:51ukleinekmoin, do you have a recommendation for tools/workflows to rip cds?
10:13:18JdGordon#rockbox-community for that ukleinek
10:13:50ukleinekJdGordon: sorry, wondered about being off-topic after pressing enter
10:16:14 Quit kadoban (Ping timeout: 248 seconds)
10:17:50*JdGordon has a script to debug skin allocations
10:17:56 Quit AlexP (Remote host closed the connection)
10:18:08JdGordonthe ilike theme allocates 40KB in strings, mostly 2 and 3 chars long!
10:18:17JdGordon645 of them!
10:18:27n1swow
10:19:04JdGordonit was also doing 20+KB in empty elements because of the comment lines which the above commit fixes
10:36:38bertrikLalufu, the state machine approach to iap worked for you, right? I'm thinking of committing at least that part.
10:50:36 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
10:52:30 Quit Jak_o_Shadows1 (Ping timeout: 248 seconds)
11:00
11:11:46jacekowskisoap: just change kernel to 64bit
11:18:21 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:19:58 Join TheLemonMan [0] (~LemonBoy@ppp-158-36.26-151.libero.it)
11:21:25***Saving seen data "./dancer.seen"
11:46:48ukleinekhmm, I'm currently looking at the sansa Fuzev2 simulator and wonder about the .mpu view
11:47:16ukleinekmy filenames are utf-8 encoded and they show up nicely in the directory view
11:47:57ukleinekbut when looking at an .m3u (not t .mpu) the umlauts look strage
11:48:01ukleinek*strange
11:48:26ukleinek(sorry for the typos, I'm on a slow connection here)
11:51:33 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
11:54:46 Quit Jak_o_Shadows (Ping timeout: 276 seconds)
11:56:47 Join [Saint] [0] (~st.lasciv@203.184.50.187)
12:00
12:13:22ukleinekalso when selecting the .m3u files with umlauts don't get properly added
12:15:07 Join lovasoa [0] (~lovasoa@2a01:e35:8a2e:8080:e2b9:a5ff:fe5b:ca7b)
12:18:27 Join MethoS- [0] (~clemens@134.102.106.250)
12:26:24[Saint]ukleinek: That's your font, or codepage setting's problem.
12:26:34kugelhow do people think about function pointers in the viewport struct?
12:35:13 Quit factor (Read error: Connection reset by peer)
12:36:38rasher[Saint]: it wouldn't be the font
12:37:17 Join veve [0] (~veverone@79.112.116.235)
12:37:33[Saint]rasher: Yeah, I thought of that after I pressed enter, but I'd mentioned the codepage also...so, I fugured I was covered ;)
12:37:43vevehi
12:37:44[Saint]*figured, too.
12:38:51vevedoes anybody know if the latest version of Rockbox 3.9.1 on Sansa Clip v1 will cause the battery to drain 2x faster than with the original firmware?
12:39:10[Saint]veve: Why would you think it would?
12:39:55vevethis was an issue some time ago and it was reported and confirmed (let me search for that link)
12:40:48vevequote: "Clipv1/c200v2/m200v4/e200v2/Fuzev1*: Battery life is quite shorter than when using the original firmware (OF). See SansaRuntime also FS #11765. Some (unknown) hardware is likely misconfigured leading to higher power consumption. "
12:40:50fs-bluebothttp://www.rockbox.org/tracker/task/11765 3Improve Battery Life on AMSv1 Sansa players (patches, new)
12:40:56vevehttp://www.rockbox.org/wiki/SansaAMS#AMSv1_issues_40m200v4_44_c200v2_44_e200v2_44_Fuzev1_44_Clipv1_41
12:41:46vevefs-bluebot: you are a boot or a real person :)) ? (I need to know if I have to thank you or not)
12:42:12[Saint]"he" is neither a boot, nor a person ;)
12:42:35veveboy*
12:42:37vevebot**
12:42:40veve:P
12:43:28[Saint]where are you getting the "2X faster" values from?
12:43:40[Saint]Battery life *is* poorer than the OF, but, not be that much.
12:43:59[Saint]the author of the patch saw a 27% increase.
12:44:38[Saint]and ClipV1 runtime was ~10 hours in ~2010
12:44:56vevewell... if you look here >> http://www.rockbox.org/wiki/SansaRuntime#Results you can see that the average time with Rockbox is 9 hours
12:45:03vevefor mp3
12:45:12veveand with the original firmware is 15
12:45:14veveBUT
12:45:35vevethis information is very old and I've searched the internet for information
12:45:40[Saint]right, that's not "2X faster", though.
12:45:47[Saint]even if it were current data.
12:46:38veveoh, yeah, it's not :). it is 1.6x faster, for the code available in 2010
12:47:00veveI don't want to be disrespectful
12:47:17[Saint]For some reason, the V2 and the + do *way* better than the V1...I don't think the reason for this is understood at all.
12:47:39veveit's just a question, if somebody knows that this is fixed or improved (because I already searched the net and i didn't found anything relevant)
12:47:48[Saint]If it were, it wouldn;t be an issue, as it'd be fixed ;)
12:48:07veve;)) true true
12:48:35bertrikWhere can I find the offset used to display the LCD contents as an overlay on the player image in the simulator?
12:49:53veve[Saint]: do you think that I have to apply that patch to the latest version of rockbox? it seems that this ticket was opened and not updated for some time
12:50:04[Saint]If I remember correctly, the patch you linked provided good battery savings, at the expense of erratic uSD behaviour.
12:50:11[Saint](for some players)
12:50:32bertrikuSD on AMS/AMSv2 has seen some fixes in the meantime
12:50:47 Join factor [0] (~factor@74.197.205.204)
12:50:48[Saint]veve: It may, or may not, apply to current svn. I couldn't say.
12:51:09bertrikWhich reminds me that we are currently not using 4-bit mode but 1-bit mode for AMS targets
12:51:17[Saint]The fixes to get it to apply should be trivial, however.
12:51:39[Saint](disclaimer: may not be the case, its an old patch ;))
12:52:25veveI will give this version a try. I never did a battery test, so I'll have to do some preparations if I decide to do it (I feel inspired by some stuff regarding battery tests, stuff that I read in the last hours)
12:52:27 Join fml [0] (~chatzilla@manz-590f3bf8.pool.mediaWays.net)
12:52:47veveI will post the results :)
12:52:50vevefor now, thank you
12:53:26fmlJdGordon: Hello. Have you seen the discussion yesterday re %Vf(xxx) not working (%Vs(color,xxx) still working)?
12:53:59fmlrasher: It would be nice if the SVN version number would be displayed on the sim download page, not just the date.
12:54:42rasherfml: hover over the date
12:56:02fmlrasher: Ah! But it's hard to know that this exists. Why not write in out?
12:56:30 Quit veve (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
12:57:09rasherfml: No particular reason - I had the date there first and just added the revision like that because I felt it'd look a bit cluttered and most people probably don't care (plus you can see the revision once you run it)
13:00
13:01:16 Quit fml (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214])
13:01:56[Saint]In hindsight, the reverse would probably be of more use. Maybe. The revision changes several times a day, where the date doesn't.
13:02:26rasherOn the other hand it's hard to know at a glance if r30457 is up to date
13:02:39[Saint]that's true.
13:04:42rasherNow it has both
13:09:01Lalufubertrik: works fine so far for me. I made a few additions, but all of those should be in FS12135
13:15:44 Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch)
13:21:28***Saving seen data "./dancer.seen"
13:22:46pamaurywhat is the cleanest option with respect to our buildchain if I want to compile *one* c file to elf and then objcopy it just like for the bootloader or the main firmware ? I need it to dual-boot
13:24:43bertrikThis is approximately how the rockbox main menu will look on the Sansa Clip Zip: http://imagebin.org/173953
13:29:27bertrikLalufu, ok, I'll commit that part then
13:31:31 Join fyre^OS [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com)
13:33:53bertrikAt least the main menu items still fit horizontally on the sansa clip zip screen
13:34:58 Quit fyrestorm (Ping timeout: 260 seconds)
13:43:15 Quit MethoS- (Remote host closed the connection)
13:47:38JdGordonfml: yes, but i've no plans to fix it any time soon so if someone wants to have a go they are free to
13:48:59JdGordon[Saint]: your ilike theme does some really bad stuff regarding skin buffer usage
13:49:28[Saint]"really bad stuff"...that worked fine until you messed it up :)
13:49:46[Saint]comments are supposed to not count towards the skin RAm usage, I thought.
13:50:13JdGordonyes, well they sort of do (did)
13:50:21JdGordonkugel: function points to do what?
13:50:40kugelline height getter
13:50:57[Saint]...which is why I never gave a flying f**k about them, but, now the Ilike Nano theme needs comments stripped or max_tokens upped just to laod.
13:51:10JdGordonkugel: err why?
13:51:14JdGordon[Saint]: its fixed now :)
13:51:22[Saint]JdGordon: Ah, awesome.
13:51:27[Saint]I missed that.
13:51:53JdGordonbut i spent some time today looking into other issues and your ilike nano theme allocates 41KB *KILOBYTES* for static strings
13:51:54 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
13:52:03JdGordoni.e all the image labels
13:52:12[Saint]"meh".
13:52:16JdGordon645 allocs totally 41KB
13:52:25[Saint]It wasn't possible to reduce that when that theme was made.
13:52:32[Saint]and, I've not touched in in months.
13:52:41JdGordonoh I know
13:52:52JdGordonjust saying :)
13:53:05 Quit Jak_o_Shadows1 (Ping timeout: 245 seconds)
13:53:14JdGordonits probably a good usecase to figure out other wastage though
13:53:27[Saint]%?XX(identifier,tag) wasn't possible at that stage.
13:53:45JdGordonI've got a list of 18 functions doing allocations in the order of count and accumulated cost of each
13:54:05JdGordonthe second worst offender is %V
13:54:13JdGordon3.6K
13:54:32JdGordoni.e I know i need to look into why the fist case is so terrible
13:54:50[Saint]On the topic of line height, kugel, why?
13:54:58*[Saint] is genuinely curious.
13:55:17kugelhave functions to select the line height based on user setting
13:55:23[Saint]I think the theme should handle the line height, personally.
13:55:31[Saint]then its a per screen setting.
13:55:31JdGordonwhere outside of lists would the line height matter?
13:55:36[Saint]not forced for all lists.
13:56:19kugelI would hate if one list is different than the previous one
13:56:47kugelJdGordon: at no place, but lcd.c needs the line height but can't just access global_settings
13:56:59kugelso I set the getter in apps/ and lcd.c just calls this
13:57:03[Saint]Well, I personally *might* want a bit of spacing in the main menu, but *not* for long scrolling lists. If the line isn't selectable, its the themes fault. It should be usable without spacing.
13:57:09kugelbut it's sure doable in another way if it's hated
13:57:22[Saint]long srolling lists with lots os spacing makes them....longer.
13:57:33JdGordonyeah, no, i dont like it, skinned lists are the way to do that
13:57:41*[Saint] nods.
13:57:47kugel(a getter is needed in the first place to not cache font height/absolute height in case either changes)
13:58:15n1skugel: can't you add a setter to lcd.c that is called when it changes?
13:58:17kugelwhy skinned lists?
13:58:30kugelnot everyone is using them
13:59:00kugellist height is not about eye candy, it's about usability
13:59:04kugelline height*
13:59:13JdGordon*COUGH* I see no reason why it is needed outside of lists, therefore its wrong
13:59:28kugelso?
13:59:31[Saint]I'd *hate* this to be forced. Make a setting for it, and I'd consider considering it. But, skinned lists are far more versatile.
14:00
14:00:12 Quit lovasoa (Ping timeout: 240 seconds)
14:00:14kugelI want rockbox to be usable without special theme support
14:00:30kugel[Saint]: I'm doing the setting, as I just wrote
14:00:30JdGordonso? thats the same argument you give me often enough
14:00:51[Saint]I find 28px completely usable...you get 10 px higer and can't use it?
14:01:00[Saint]on a larger screen, too.
14:01:27[Saint]If the lists aren't usable, that's my fault, apparently...or your screen is weird.
14:02:08kugelor we have different opinions about usability
14:02:24 Quit antil33t (Read error: Connection reset by peer)
14:02:29[Saint]How is that possibly? How many definitions are there?
14:02:44kugelI find getting sufficiently large lines (for my thumbg) only via huge fonts not usable
14:02:48 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
14:03:07[Saint]"I can use the lists with perfect accuracy", is my definition in this case.
14:03:22n1sperhaps you use them differently
14:03:27[Saint]and by percentile of total screen hieght, my lists are a lot smaller.
14:03:44[Saint]s/,y/240/320/
14:03:47[Saint]*my
14:04:41[Saint]I think even the 480x800 port has "smaller" lists compared to the 320x480 port.
14:04:48kugel[Saint]: that you can use them with perfect accuracy doesnt mean anyone else does
14:05:02[Saint]I haven't had any complaints...
14:05:05CIA-14New commit by 03jdgordon (r30597): Add a simple perl script to display info about what is allocating skin buffer. ...
14:05:14[Saint]And there's a few hundred people using it.
14:05:15kugelthat doesn't mean anything
14:05:29kugeland I had complained if my list spacing patch wasn't already applied
14:05:39JdGordona setting is the wrong place for this
14:06:05kugelwell, *I* don't need a setting anyone
14:06:15kugelanyway
14:06:21JdGordonespecially when if anyone uses skinned lists anyway the setting will be ignored
14:06:49[Saint]when you brought it up the last time, I believe I wasn't the only one that said it was terrible on 240x320, how does it cope with this now?
14:07:01kugelI want it to be based on the screen lcd. I don't care what skinned lists do to it if I don't use a theme with them
14:07:19CIA-14r30597 build result: All green
14:07:52[Saint]Well, shouldn't we only care about the default theme? Which is still under development, so there's nothing saying it *won't* use them.
14:08:06[Saint]Or...that it will, to be honest.
14:08:57kugelI thought you're done on development and in the bug fix phase?
14:10:10[Saint]Not exactly, no. Its been constantly changing for a long time. I have no reason to believe it won't continue to either, as things like this happen.
14:10:36[Saint]Your port was the last completed, so now I have to deal with your issues.
14:10:41[Saint]I knew it was coming.
14:10:47JdGordon[Saint]: err oops, the 41KB is on the skin_element items, so not much you can do about it.. every tag creates 1, and every sub/line and every conditionalal etc
14:10:49kugelwell, we didn't even decide if we even want it, or in which form
14:11:27JdGordon1KB in strings
14:11:35kugelwhat do you want to use skinned lists for?
14:12:18[Saint]To space the lists, conditionally. By screen. *maybe*, if in fact more poeple than just yourself think its even necessary.
14:12:37[Saint]I've no indication that's the case presently.
14:12:51kugelthat sounds horrible, imo
14:13:08[Saint]As horrible as forcing spacing in all lists sounds to me.
14:13:19[Saint]its hard enough to scroll long lists without making them longer.
14:13:22kugelI'm doing the setting didn't you hear?
14:13:40[Saint]which will turn it off *everywhere*.
14:13:40kugelhave you used the scrollbar?
14:14:07[Saint]the scrollbar scrolls way too fast to be useful really. Unless its an alphabetical list.
14:14:34[Saint]if the list isn;t ordered, and you want to review it, its terrible if the list is sufficiently long.
14:14:41kugelso, what you actually want is faster scrolling, not smaller linesß
14:14:48kugel?
14:14:52[Saint]slower.
14:15:16kugelslower?
14:15:30kugelwith smaller lines it gets faster
14:16:36kugeldoes anyone else here think that lists looking differently (instead of uniform throughout rockbox) is a good ui design decision?
14:17:05kugelnot only _looking_, the line height has a clear impact on the usability
14:17:26kugelI don't want this for the default theme
14:17:38JdGordonyou're the only one bringing this up, and there is already a very workable solution
14:18:07kugelJdGordon: where?
14:18:18kugela custom theme?
14:18:38[Saint]...why not?
14:18:41kugelI find this is only remotely related to theming
14:18:47[Saint]So far, you're the only one bringing this up.
14:19:29kugelwhat. I should shut up because I'm the only one currently?
14:19:34CIA-14New commit by 03bertrik (r30598): IAP: use a state machine for handling iap packets, based on FS #12135
14:19:56Lalufuanyone around here using current release rockbox versions with an iPod, and using attached devices of any kind?
14:20:24Lalufu(headphones do not count as "attached devices" here :)
14:20:31[Saint]No, I'm not saying that. Just that maybe you have a different idea than the rest about whats usable, so maybe a custom theme is a more workable solution than adding yet another setting for something that has a solution already.
14:20:38JdGordonkugel: no you shdont' need to shutup, but you're in the minority, and yes this is entirely a theme issue
14:20:48kugelit isn't
14:20:57JdGordonyou already said you cant tihnk of anywhere outside of a themeable screen this would be needed
14:21:08kugelwhether I can use my thumb to select items or not is *not* a theme issue
14:21:15[Saint]I could even easily add a toggle, on a per screen basis, to expand and contract lists.
14:21:42CIA-14r30598 build result: All green
14:22:22kugelfwiw, I have support for the patch in its old form
14:22:26JdGordondoes the packed sturct attribute make gcc reorder the items so individual items are type-aligned like they should be?
14:22:37kugeljust making it commitable with a setting to make you happy
14:23:01[Saint]"have support"?
14:23:09*[Saint] doesn't follow.
14:23:24[Saint]At the end of the day, I really don't care...so long as its not forced.
14:23:34[Saint]but I do think its a theme issue.
14:23:41JdGordonit isnt commitable
14:23:42JdGordoneven with a settin g it isnt
14:23:43kugelAlexP and GodEater said it makes rockbox usable
14:23:49kugel(while svn isn't)
14:24:25 Join lovasoa [0] (~lovasoa@2a01:e35:8a2e:8080:e2b9:a5ff:fe5b:ca7b)
14:24:30[Saint]kugel: the same Alexp and GodEater that have reported no issues whatsoever with my theme?
14:24:40bertrikJdGordon, no I don't think they are reordered
14:24:44[Saint]I wasn't aware they were running custom builds, that's annoying.
14:24:56kugel[Saint]: yes. perhaps they had my patch applied when trying
14:25:09[Saint]usability testing means nothing, in that case,. fuck it.
14:25:30*[Saint] grumbles now about being misslead ;)
14:26:13kugelalso, it might be that with a sufficiently large font it becomes usable, but very ugly at the same time
14:26:25[Saint](and, fwiw, they *have* reported multiple issues with my theme...I worded that incorrectly. They've both been a great help. I've had no complaints about the lists though)
14:26:29[Saint]...this may be why.
14:26:30[Saint]dammit.
14:27:24kugelwell, the test builds you provided also have a bunch of patches applied no?
14:27:39JdGordonbertrik: hmm, ok, . it appears saving 4 bytes per item I could save quite a bit of waste :/ but i tihnk i wont bother
14:28:12[Saint]I stopped providing builds a long time ago. the first run of the theme needed a few changes not currently in svn, so I distributed my private build as it was easier.
14:28:14bertrikit might even result in items getting unaligned and lot of extra code generated to access the items
14:28:25[Saint]Now there's no need for non-svn, I don't supply builds.
14:28:34[Saint](there was nothing list related, either)
14:30:17[Saint]How would this setting (lets say it does get committed) cope if it encountered skinned lists?
14:30:27JdGordonit would break horribly
14:30:28[Saint]fail silently?
14:30:35JdGordonit will also break every wps virewport
14:30:39kugelskinned list would probably override it
14:30:41JdGordoni.e its a really bad idea
14:30:53kugelwhy break horribly?
14:32:05kugelwps viewports have nothing to do with it
14:32:20 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
14:34:33[Saint]I know it adds another layer of complexity, and another setting. But I'd prefer (were this to be committed) that there was an on/off setting, as well as a value setting, instead of trying to guess the height to expand the lists based on font and/or screen height.
14:34:43kugelpfwiw, skinned lists only work for a single resolution. I aim to just work for all screens
14:34:50[Saint]then it's truly be a user's preference as to what they thought was usable.
14:35:14[Saint]on/off, and a value divisable by two to expand the lists by in pixels.
14:35:33JdGordonI'm very against this setting, and as I'm really the only one active in this i tihnk that should mean something
14:35:44[Saint]or even just 0 == off, 2,4,6,8etc.
14:35:56*JdGordon thought you were doing *svn* builds kugelp ?
14:36:10JdGordonif you're doing custom builds anyway why cant my buflib malloc patch go in?
14:36:11rasherAre you talking about list padding?
14:36:21[Saint]rasher: It seems that way.
14:36:25kugelpI don't do any builds
14:36:52[Saint]I believe he was referring to an ealier statement of yours.
14:37:07rasherThat sounds like something that should prooobably be a setting. No need for multiple ones though, just an int defining how many pixels to add on each side?
14:37:54[Saint]rasher: I disagree. There's a lot of difference in touchscreens apparently.
14:38:06rasher[Saint]: huh?
14:38:15JdGordonwhat is the last point anything can call buffer_alloc() before buflib takes over?
14:38:16[Saint]a user should be able to specify the inscrease in padding, not have a forced value that may be too much/little
14:38:21rasher[Saint]: What do you disagree with?
14:39:05[Saint]Ah...I missinterpreted that, nevermind. ...<skulks away>.
14:39:24[Saint]I just re-read it and realised you said exactly what I did, only in a different way.
14:41:16[Saint]But, yeah..."Settings - LCD Settings - Pad Lists - 0,2,4,6,8,etc." I wouldn't mind. If it worked in harmony with skinned lists.
14:41:20kugelpJdGordon: buffer_alloc() is dead
14:41:42[Saint](where "in harmony" == "skinned lists negate list padding if present)
14:42:27rasher[Saint]: Why only even numbers? That just looks silly
14:42:43[Saint]rasher, to senter the lists inside the padding.
14:42:48[Saint]*center too
14:42:53JdGordonkugelp: how do i stallocate a buffer which wont move?
14:43:09JdGordonor im forced to use buflib and make sure to be the first to do so
14:43:09kugelpyou don't
14:43:10rasher[Saint]: you can do that with any number - just interpret it as padding on each side
14:43:46kugelpwhat do you want to do?
14:43:53[Saint]How could you then, add 1px paddign top/bottom (say you wanted to)
14:44:02rasher[Saint]: set padding to 1
14:44:20[Saint]Ah, right. *derp*.
14:45:47[Saint]I'd prefer it to be divisable by two and reflect the total amount of padding applied, but, I guess that's entirely personal.
14:46:24[Saint]It wouldn't be immediately obvious to me that padding == 1 applied 2px of padding.
14:47:52*rasher shrugs
14:47:54rasherit just a number
14:48:15rasherNo one cares about pixels, just the end result!
14:49:19[Saint]right, volume should be : silent, quiet, louder, a bit louder still, loud, really loud...then :)
14:49:23 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
14:49:56kugelpthe number could translate to different pixels on different displays :-)
14:54:58 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.)
14:55:42CIA-14New commit by 03jdgordon (r30599): Check for the magic file "/.rockbox/skin_buffer_size.txt" on bootup which can have a number which is the amount of kilobytes to allocate for the skin ...
14:57:01CIA-14New commit by 03jdgordon (r30600): fix warnings
14:57:45CIA-14r30599 build result: 10 errors, 188 warnings (jdgordon committed)
14:58:46 Quit Jak_o_Shadows (Remote host closed the connection)
14:59:25CIA-14r30600 build result: 10 errors, 0 warnings (jdgordon committed)
14:59:30JdGordongrr android :/
15:00
15:01:53CIA-14New commit by 03jdgordon (r30601): fix APPLICATION build errors
15:03:36kugelpjd
15:03:53CIA-14r30601 build result: All green
15:04:17kugelpJdGordon: ugh, I had that idea many month ago, you were against it
15:04:49kugelpwhy now, where the vast majority of the skin buffer is dynamic?
15:05:27JdGordonI have no recollection of that, and 2 the vast majorifty is not dynamic at all
15:06:08kugelphuh?
15:06:36JdGordonhuh what?
15:07:10kugelpthis is effectively a user setting for the buffer size, I thought that was a nodo
15:07:46kugelpbackdrops & images are much bigger aren't they?
15:08:02JdGordonyou thought wrong....
15:08:25kugelpwe had configurable skin buffer topic many times, and you now sneak it in
15:08:28JdGordonand i've spent all day looking into skin buffer usage, it cant get any smaller with massive rework to use buflib which isnt going to happen
15:08:43kugelpyou have any numbers?
15:10:01JdGordonas a matter of fact.. yes I do http://pastebin.com/0vP0zbDP <- ilike on the nano, cabbie shows a similar story
15:11:13JdGordonhttp://pastebin.com/AMUB7Spi <- cabbie
15:12:09kugelpand what does that show?
15:12:26 Quit ReimuHakurei_ (Quit: And therefore, dye this sky red. The time has come again for my body to only go forward / Even the 'people' who pass by and the 'things' which become lost in confusion / Will one day be like vanished memories)
15:12:37kugelpand I'm not sure you want me to look at the first paste
15:13:00JdGordonthe first post is the raw data
15:13:08JdGordonthe second one is actually usefu;l
15:13:31kugelpbut it doesn't include images does it?
15:13:35JdGordonno
15:13:51kugelpso what should it tell me?
15:13:51JdGordonwhat it shows is that there is no more easy fixes for the skin buffer size problem
15:14:49JdGordonand I know for sure noone else is going to even attempt the hard solution, so this is the fix
15:15:08kugelpand for that you sneak in a patch for configurable buffer without any word about it?
15:15:32JdGordonwhy do you always think there is *evil* in my commits?
15:15:39kugelpI disagree with that commit in several ways
15:17:36kugelpwhy don't you discuss it before
15:18:19kugelpwe were always against user configurable skin buffer
15:18:42kugelpthis is even worse because its implemented in an awkward manner
15:21:29***Saving seen data "./dancer.seen"
15:47:09pamauryr30599 seems strange to me, it's kind of setting but done in a unusual way
15:48:34 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
15:54:06pamaurywhat are the steps to add a target to the simulator ?
16:00
16:07:29 Quit user829385 (Quit: Leaving.)
16:22:15 Quit lovasoa (Quit: lovasoa)
16:44:52*bertrik ordered a Sansa Clip Zip, to be used for rockbox development
16:47:39bertrikpamaury, add a .bmp in uisimulator/bitmaps/UI-<targetname>.bmp and edit firmware/target/hosted/sdl/sim-ui-defines.h to define how the framebuffer overlays the player image
16:48:11bertrikI just did that for the clip zip :)
16:54:12bertrikI guess we can't use a promotional picture from the manufacturer for the BMP?
16:54:28pamauryweird, I'm getting an error because of swap16_hw being redefined :(
16:54:37pamaurybertrik: I guess not, I took a picture of my fuze+
16:55:25pamauryand HIGHEST_IRQ_LEVEL beging redefined too, strange
16:55:28pamaury*being
16:55:31pamaury*been
16:55:50pamauryall seem related to adc-target
16:56:13bertriksounds nasty
16:57:59pamauryjust tried a e200 sim and it builds, so it might be related to my code but I don't see how
16:59:10 Join ender` [0] (~ender@foo.eternallybored.org)
16:59:40pamauryok, I found why
17:00
17:12:05 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
17:12:55 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
17:16:44GodEaterwhat argument have I missed where I've been mentioned?
17:18:49kugellist item spacing
17:19:08kugel(on touchscreen that is)
17:19:40GodEateroh right
17:19:54GodEateryes - bigger spacing makes the menu much more usable
17:20:17GodEaterthe default theme using the original spacing is a complete pain in the ass
17:21:15GodEaterwhose patch to introduce it did I use originally?
17:21:24kugelmine
17:21:33***Saving seen data "./dancer.seen"
17:21:37kugelI'm working on making it committable, but I'm faced some opposition
17:22:31GodEateroh?
17:22:36kugelfacing*
17:22:38GodEaterwho says it's a bad idea?
17:24:34kugelwell, nobody. but JdGordon says it can be done be done in themes with skinned lists, so any other way is wrong
17:25:02kugelthe patch I work on works on all screens (or tries to...) without special theme support
17:25:14GodEaterthat seems a better idea to me
17:25:41GodEaterhaving to theme a list for screensize seems a rather obtuse way of doing it
17:25:58kugelIMO it's not a theme issue at all
17:26:07GodEaterno it isn't I don't think
17:27:05kugelGodEater: did you test saint's cabbiev2 version with or without this patch applied?
17:27:41GodEaterI've not tested his theme for ages
17:27:50GodEaternot since the first time I tried it and didn't like the WPS changes
17:28:20GodEaterat the moment I can't do much testing, as I have no build env. until kernel.org is fixed and I can rebuild by toolchain
17:28:30kugelsaint said you "reported no issue whatsoever"
17:28:32GodEaters/by/my/
17:28:53GodEaterkugel: well that's technically true - but only because I've barely used it ;)
17:28:55kugelfor android you don't need the toolchain do you?
17:29:10GodEaterneed an arm compiler don't I?
17:29:17kugelthat comes with the ndk
17:29:40GodEaterah cool
17:29:42GodEaterwill download then
17:30:20kugelplus, you can set other mirrors for rockboxdev.sh (or download manually), but I don't know any mirror :)
17:30:28GodEaternor me
17:30:41GodEaterand I've not really been incentivised to look
17:35:41CIA-14New commit by 03pamaury (r30602): imx233/fuze+: add fuze+ to the simulator framework
17:37:24 Join Stummi [0] (~Stummi@rockbox/developer/Stummi)
17:37:42CIA-14r30602 build result: All green
17:45:03n1sJdGordon: gcc never reorders struct members (it would be dangerous unless it kknew where all the usres were and altered them too) and the packed attribute tells it to not use any padding between members so members are no longer aligned unless by coincidence so on targets that require alignment, such as arm i will generate byte-by-byte accesses which are slower and makes the code bigger
17:45:46n1ss/ i / it /
17:49:49 Quit pamaury (Remote host closed the connection)
17:55:32 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/)
17:56:49 Quit Xerion (Ping timeout: 256 seconds)
18:00
18:00:18 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl)
18:01:49 Quit bluefoxx_ (Ping timeout: 255 seconds)
18:02:20 Join Keripo [0] (~Keripo@dhcp0751.kin.resnet.group.UPENN.EDU)
18:04:19 Quit Keripo (Client Quit)
18:04:33 Quit simonlnu (Quit: bbl)
18:07:59 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
18:12:25 Quit fyre^OS (Ping timeout: 276 seconds)
18:23:54 Join funman [0] (~fun@rockbox/developer/funman)
18:27:03 Join soap_ [0] (~soap@94.75.232.194)
18:27:03 Quit soap_ (Changing host)
18:27:03 Join soap_ [0] (~soap@rockbox/staff/soap)
18:44:52 Join benedikt93 [0] (~benedikt9@p5B0C6A2E.dip.t-dialin.net)
18:44:57 Quit benedikt93 (Changing host)
18:44:57 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
18:47:46gevaertsSomeone broke album art!
18:48:35funmanyou mean MrSomeone? :)
18:49:10 Quit ej0rge (Remote host closed the connection)
18:49:21 Join ej0rge [0] (~alhaz@207.135.137.71)
18:51:52gevaertsscrendumps seem to be really unstable on my gigabeat F with a build from yesterday
18:55:16bertrikfunman, perhaps you can have an extra look at my code/binary just before the first attempt of flashing the clip zip
18:56:05funmanbertrik: did it change since i looked? iirc it was super simple
18:57:08bertrikno, the first try is to just make it boot the OF, then to introduce a button-dependent delay, then to make it boot rockbox bootloader depending on the button state
18:59:00 Join simonlnu [0] (~simon@unaffiliated/simonrvn)
19:00
19:02:05gevaertsIt looks like connecting USB when screendumps are enabled (at least on gigabeat f) now starts making screendumps continuously
19:05:10 Quit mystica555 (Ping timeout: 245 seconds)
19:05:10gevaertsAnd album art doesn't seem to be loaded if it's one directory up
19:05:38mc2739gevaerts: that is a symptom I noticed on e200v2 and reported in FS #11995
19:05:40fs-bluebothttp://www.rockbox.org/tracker/task/11995 3screendump problems caused by r29445 (bugs, new)
19:06:03 Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch)
19:07:22gevaertsmc2739: so it might be a stack issue?
19:08:02mc2739gevaerts: that is what it looked like
19:13:01 Join Buschel [0] (~chatzilla@p54B67F1B.dip.t-dialin.net)
19:13:41 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
19:14:11Buschelwhy do we use "int" for "line", "params_count" and "children_count" in the "skin_element" type? is this really required? we might save several KB when using unsigned char instead...
19:15:21gevaertsIs unsigned char always large enough?
19:16:03Buschelin fact I do not know. but I am pretty convinced we fo not need int.
19:16:18gevaertsshort might be doable
19:16:57Buschelmaybe some of our skin experts can evaluate this
19:21:34***Saving seen data "./dancer.seen"
19:28:05kugelhm, might be possible
19:29:26 Join Horschti [0] (~Horscht@xbmc/user/horscht)
19:30:19kugelparam_count char and line, children_count short, plus reordering, could save 8 byte or so
19:30:42kugelsince enum skin_element_type is char also (on arm eabi at least)
19:32:13Buschelwhich would equal 8 KB of skin buffer size
19:32:51gevaertsWell, yes and no
19:33:08 Quit Horscht (Ping timeout: 256 seconds)
19:33:43gevaertsIt would make the skin buffer 8KB smaller, but whether that translates to actually *needing* 8KB less depends on how the skin uses this space
19:34:22Buschelwasn't this what I said? making the skin buffer smaller?
19:35:32Buscheland if I understant this stuff right the skin buffer is always allocated. but maybe not fully used by the skin
19:35:52*gevaerts nods
19:38:27kugelhere's a new version of the list item patch, with now with setting and some bugs fixed: http://pastie.org/2590041
19:38:30kugelGodEater: ^
19:55:38gevaertsUnhelpful: I understand you understand AA?
19:55:57gevaertsDo you have any idea why parent directory AA doesn't work anymore for me?
19:56:00Unhelpfuluhoh. what's the question?
19:56:23Unhelpfulwithout looking at the code, no... gimme a bit.
20:00
20:02:36Lalufubertrik: you deciced to drop the serbuf_lock?
20:03:28bertrikyes, the approach I took was not water-proof I think
20:04:13 Quit Bagder (Ping timeout: 276 seconds)
20:04:38 Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at)
20:04:38 Quit dfkt|n (Changing host)
20:04:38 Join dfkt|n [0] (dfktn@unaffiliated/dfkt)
20:08:45 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
20:08:45 Quit Bagder (Changing host)
20:08:45 Join Bagder [241] (~daniel@rockbox/developer/bagder)
20:10:22 Quit bluebrother (Disconnected by services)
20:10:23 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
20:13:14 Quit fs-bluebot (Ping timeout: 255 seconds)
20:14:26 Join fs-bluebot [0] (~fs-bluebo@g231123130.adsl.alicedsl.de)
20:18:54LalufuI think something of that kind is needed, to prevent buffer corruption
20:21:03bertrikyes I agree, but somehow IAP got stuck when looking at the IAP debug info
20:21:44bertrikI think IAP messages were probably being dropped somehow in the debug menus, causing the lock to never be released again
20:24:11Lalufuyes, that happens.
20:24:32Lalufuif you're in the debug menu receiving messages will f**k up the state machine
20:24:48Lalufuor better, f**k up the locking, as the queue is never run
20:27:04LalufuBut I think going to a local queue to handle messaging (which I've done in the meantime) fixes that
20:29:08Lalufuat least I can have the logf dump open and put messages through IAP and watch them in real time
20:46:56GodEaterkugel: doing a build with that patch now
20:48:59 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/)
20:49:13 Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch)
20:51:52GodEaterkugel: looks great
20:54:33pamaurywho can quickly explain to me the different items of the keymaps ?
20:54:55pamaurywhat does ACTION_STD_MENU and ACTION_STD_CONTEXT do ?
20:56:11 Join MethoS- [0] (~clemens@134.102.106.250)
20:59:33 Quit Lalufu (Read error: Connection reset by peer)
20:59:47 Join Lalufu [0] (~sun@ryoko.camperquake.de)
21:00
21:00:01 Quit Lalufu (Changing host)
21:00:01 Join Lalufu [0] (~sun@unaffiliated/lalufu)
21:02:42 Quit dfkt|n ()
21:03:55gevaertshm, my clip doesn't boot with a current build
21:04:21ukleinekhow do I start playback with a playlist from the catalogue?
21:04:53 Join Chat7180 [0] (pyzuks@app3.chatmosphere.org)
21:05:45ukleinekI would expect selecting an entry in the Catalogue and pressing 9 in the Sansa Fuzev2 Simulator would do, but it doesn't
21:06:11 Quit parafin (Ping timeout: 240 seconds)
21:06:38 Quit Chat7180 (Client Quit)
21:07:02ukleinekalso selecting an entry of the playlist and pressing >|| (9) doesn't work
21:07:40 Join parafin [0] (parafin@paraf.in)
21:11:48mc2739gevaerts: my e200v2 is having problems, too. It hangs with a white screen after the bootloader logo displays. It looks like r30589 is the problem build.
21:11:55kugelGodEater: cool
21:13:24gevaertsmc2739: yes, same here
21:14:34 Quit bluefoxx (Ping timeout: 256 seconds)
21:14:43bertrikamiconn looked at it a bit closer at this, but I don't know the final verdict
21:15:32 Join freddyb [0] (~freddybbb@216.8.239.112.etczone.com)
21:16:17amiconnr30589 causes 100% reproducable crash *on hwcodec* (after applying a fix for an earlier crash)
21:16:24 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
21:17:21amiconnThat said current seems to be somewhat unstable on swcodec as well. Today, my H180 hung at shutdown. CF targets used to hang occasionally some time ago, but I didn't observe that anymore for many months
21:17:34amiconnYesterday I updated to latest svn, and today it hung...
21:19:33*bertrik is getting scared of updating
21:20:49saratogai just updated my Clip+ and its working perfectly
21:21:05saratogar30602
21:21:38***Saving seen data "./dancer.seen"
21:25:38amiconnIf you just updated you cannot be sure whether it's 100% stable
21:26:00gevaertsAh, good news. A visible panic screen!
21:26:40kugelI don't suppose anyone cares about my mailing list post?
21:27:13gevaertsdata abort in font_get
21:27:29 Quit Buschel (Ping timeout: 255 seconds)
21:27:57bertrikkugel, I mostly agree with you
21:28:55gevaertsWith an address that looks like ASCII
21:29:30saratogaha fuzeV1 locked on rolo after updating
21:30:05saratogayeah 3 locks in a row booting
21:30:22saratogaso amsv2 worked for me, but v1 did not
21:36:44kugelbertrik: an answer on the ml would be appreciated
21:40:31ukleinekhuh, a segfault
21:41:30 Quit TheLemonMan (Quit: WeeChat 0.3.5)
21:41:44 Join TheLemonMan [0] (~LemonBoy@ppp-158-36.26-151.libero.it)
21:51:32 Quit Stummi (Quit: Bye!)
21:53:22kugeldid anyone notice 30600 built in 94s?
21:53:41kugelthat's new record isnt it?
21:54:03kugelah build error, so it probably doesnt count
21:54:04gevaertsIt might be. We've had some fast builds when Zagor was testing
21:54:21kugelbut r30587 was 100s
21:54:44saratogais there any theory why the fonts on buflib broke some random AMS devices?
21:55:15kugelbad luck
21:55:26gevaertssaratoga: for me it seems to crash in get_font() in the "pf = &alloc->font" line
21:55:39kugelI don't believe it's specific to samsa in any way
21:55:49gevaertsThe second one, that is
21:56:05 Quit benedikt93 (Quit: Bye ;))
21:56:58kugelprobably data is being overwritten
21:57:17kugelamiconn reported another crash in font_unload()
21:57:56gevaertsI get a data abort with 0x65696266 as the illegal address, which looks suspiciously ASCII, so yes, overwritten data seems likely
21:58:36kugel&alloc->font shouldn't crash as it should evaluate to (type*)alloc (font is the first member)
21:59:01kugelmissed optimization then
21:59:20gevaertsMaybe. Or maybe I'm wrong in locating the crash of course
21:59:24kugelgevaerts: did you check what string that is?
21:59:39gevaertsWhat I do is compile with -g and then arm-elf-eabi-objdump −−disassemble -S rockbox.elf
21:59:46kugel"fbie"
22:00
22:01:00 Quit mystica555_ (Remote host closed the connection)
22:02:01kugelgevaerts: you don't need -g for that I think
22:02:36*kugel might be wrong
22:02:50gevaertsAh, I see what I did wrong. It's the line after that, i.e. "if (pf && pf->height)"
22:06:32 Quit evilnick (Ping timeout: 260 seconds)
22:15:22kugelfwiw, lru isn't updated in the move callback
22:16:33kugelI'm not sure it matters for this crash
22:18:46 Quit y4n (Quit: 6,000,000 ways to die — choose one.)
22:18:47CIA-14New commit by 03kugel (r30603): Fonts/buflib: The lru cache base poitner needs to be updated as well in the move callback.
22:19:29*kugel slaps forehead
22:19:36CIA-14r30603 build result: 376 errors, 0 warnings (kugel committed)
22:19:55CIA-14New commit by 03kugel (r30604): Fix typos. Should have test compiled at least once :\
22:22:01CIA-14r30604 build result: All green
22:24:37kugelI don't suppose that fixed it for anyone?
22:25:51gevaertsit didn't, no
22:26:34gevaertsWell, it still crashes at least. No guarantees that it's the same crash, I haven't managed to get the visible panic again yet
22:26:54freddybAre you guys crashing on the sim, too?
22:28:55 Join mystica555 [0] (~Mike@71-211-199-174.hlrn.qwest.net)
22:29:57saratogadidn't make a difference on my fuze, haven't tried the sim
22:32:34mc2739the sim does not crash for me
22:33:02 Join petur [0] (~petur@rockbox/developer/petur)
22:34:13 Quit funman (Quit: leaving)
22:45:24freddybshould the "while(1)" in font.c:font_get() be "while ( buflib_allocations[font] != -1 )" ?
22:48:40freddybscratch that
22:54:17 Quit TheLemonMan (Quit: WeeChat 0.3.5)
23:00
23:06:56 Quit ej0rge (Ping timeout: 255 seconds)
23:07:10 Join ej0rge [0] (~alhaz@207.135.137.71)
23:11:35 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
23:12:20 Quit mamarley (Remote host closed the connection)
23:21:41***Saving seen data "./dancer.seen"
23:31:27 Quit liar (Quit: hallowed are the ori!)
23:32:14 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
23:34:36 Quit liar (Client Quit)
23:39:59 Join Strife89 [0] (~Strife89@207.144.201.128)
23:44:08 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
23:51:15 Join funman [0] (~fun@rockbox/developer/funman)
23:51:49amiconnkugel: Will you commit the crash fix for r30383?
23:54:34 Quit ender` (Quit: When one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion.-- Robert Pirsig)

Previous day | Next day