--- Log for 15.03.112 Server: card.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 7 days and 9 hours ago 00.07.25 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust848.3-3.cable.virginmedia.com) 00.10.07 Quit lebellium (Quit: ChatZilla 0.9.88.1 [Firefox 11.0/20120310173008]) 00.34.58 Join Keripo [0] (~Keripo@eng197.wireless-resnet.upenn.edu) 00.38.46 Quit Rower85 (Read error: Connection reset by peer) 00.39.09 *** Saving seen data "./dancer.seen" 00.44.28 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 00.45.33 Join kaner_ [0] (~kaner@zzz.strace.org) 00.45.34 Quit kaner (Read error: Operation timed out) 00.45.34 Quit scorche|sh (Read error: Operation timed out) 00.46.48 Join scorche|sh [0] (~scorche@squisch.net) 00.51.31 Quit factor (Quit: Leaving) 00.56.30 # [Saint_]: what do you think about using decimal numbers for viewport percentage sizing? 00.57.09 # so %V(0,0,.5,.75) would give a viewport at (0,0) which is half the width and 3/4 the highet of the display 00.57.44 # I'm not sure it would be easy to allow %V(0,0,50%,75%) unfortunately 00.57.48 # thjough it would be much better 01.00.52 Quit remlap (Read error: Connection reset by peer) 01.06.38 Quit Rondom (Remote host closed the connection) 01.07.10 Join Rondom [0] (~rondom@2a01:488:66:1000:b24d:4f2f:0:1) 01.11.01 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 01.13.07 Quit amithkk (Ping timeout: 240 seconds) 01.22.07 # actually, no checking for 50% is doable 01.29.43 Join amithkk [0] (u4289@2buntu/writers/amithkk) 01.31.56 # Commit f31e7a1 in rockbox by 03Jonathan Gordon: Revert "Fix FS#12606 - next track can cause the screen to be cleared" 01.34.42 # f31e7a1 build result: All green 01.35.12 # if anyone comes in asking why the file browser is crashing get them to try the current build... apparently that fix wasnt great 01.35.50 Quit saratoga (Ping timeout: 245 seconds) 01.51.51 Quit Thra11_ (Remote host closed the connection) 01.52.05 Quit robin0800 (Quit: Leaving) 02.00.53 # [Saint_]: kugel: g#184 02.00.55 # 3Gerrit review #184 at http://gerrit.rockbox.org/r/#change,184 : skin_engine: Support percentages for viewport positioning by Jonathan Gordon (changes/84/184/1) 02.04.05 Quit Keripo (Quit: Leaving.) 02.10.25 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 02.17.12 Quit anewuser_ (Read error: Connection reset by peer) 02.20.10 Quit evilnick (Ping timeout: 246 seconds) 02.22.57 Quit Riviera (Excess Flood) 02.23.38 Join Riviera [0] (~Riviera@92.51.147.16) 02.24.31 Quit MethoS- (Quit: Konversation terminated!) 02.24.59 Join anewuser [0] (~anewuser@190.207.136.156) 02.24.59 Quit anewuser (Changing host) 02.24.59 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 02.39.10 *** Saving seen data "./dancer.seen" 02.47.29 Join anewuser_ [0] (~anewuser@190.207.136.156) 02.48.33 Join factor [0] (~factor@r74-195-218-139.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 02.49.27 Quit anewuser (Ping timeout: 255 seconds) 02.54.37 Quit zchs (Remote host closed the connection) 02.57.02 Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) 02.57.10 Quit Riviera (Ping timeout: 260 seconds) 02.57.58 Quit zchs (Client Quit) 02.58.42 Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) 03.13.46 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 03.54.10 Quit perrikwp (Read error: Connection reset by peer) 03.55.21 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 03.56.24 Join passstab [0] (~v@c-68-80-37-73.hsd1.pa.comcast.net) 03.57.08 Quit perrikwp (Read error: Connection reset by peer) 03.58.23 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 03.58.56 Join OzzieJacks [0] (~OzzieJack@24-246-47-198.cable.teksavvy.com) 04.07.01 # OzzieJacks: ah nice timing 04.10.26 Quit pixelma (Disconnected by services) 04.10.26 Quit amiconn (Disconnected by services) 04.10.28 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.10.28 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.10.30 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.10.33 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.12.23 Quit passstab (Remote host closed the connection) 04.28.23 Quit [7] (Disconnected by services) 04.28.55 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.32.38 Quit factor (Quit: Leaving) 04.39.11 *** Saving seen data "./dancer.seen" 04.43.23 Quit kadoban_ (Remote host closed the connection) 04.51.41 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 05.04.09 Join Rob2223 [0] (~Miranda@p5B0254D9.dip.t-dialin.net) 05.07.32 Quit Rob2222 (Ping timeout: 245 seconds) 05.16.35 Quit enthdegree (Ping timeout: 260 seconds) 05.17.10 Quit anewuser_ (Read error: Connection reset by peer) 05.20.02 Join Keripo [0] (~Keripo@eng197.wireless-resnet.upenn.edu) 05.22.56 Quit bitcraft_ (Remote host closed the connection) 05.35.29 Quit ps-auxw (Ping timeout: 272 seconds) 05.39.06 Join ps-auxw [0] (~arneb@p4FF7F741.dip.t-dialin.net) 05.43.16 Quit wtachi (Quit: WeeChat 0.3.7) 05.43.50 Join wtachi [0] (~wtachi@bloom.wtachi.us) 05.46.03 # <[Saint_]> JdGordon: I've really not got a lot of opinion here...until its actually decided what direction we difinitely want to head in for multi-res/rotaion-aware-resizable/etc. skins I'd be hesitant to support work in any direction. 05.46.04 Quit ps-auxw (Quit: leaving) 05.51.37 # :( 05.52.52 # <[Saint_]> I just don't want you to waste your time man, that's all. 05.53.44 # <[Saint_]> I don't like the idea of you working on , and then someone else deciding the direction is totally wrong and making the work totally irrelevant. 05.54.26 # meh, thats not an issue, I just want to get something started 05.54.40 # <[Saint_]> And as yet, no one seems to have a clear idea what direction to head in to support multi-res/rotation-aware-resizable skins. 05.54.50 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 05.55.10 # <[Saint_]> Until there is one, I'm just hesitant about encouraging any one particular approach. 05.55.11 # I'm pretty sure this is going to end up being one of those "bits of everyones ideas" things 06.03.20 Quit curtism (Quit: Live Long and Prosper) 06.33.39 Quit KiwiCam (Quit: Leaving) 06.39.13 *** Saving seen data "./dancer.seen" 06.44.26 Quit scorche` (Read error: Connection reset by peer) 06.59.26 Join scorche [0] (~scorche@rockbox/administrator/scorche) 07.09.46 Join factor [0] (~factor@r74-195-218-139.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 07.38.35 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 08.17.07 Join mortalis [0] (~mortalis@77.108.98.176) 08.21.40 Quit OzzieJacks (*.net *.split) 08.28.05 Join OzzieJacks [0] (~OzzieJack@24-246-47-198.cable.teksavvy.com) 08.38.11 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 08.38.45 Join KiwiCam [0] (~KiwiCAM@101.98.171.48) 08.39.00 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.39.14 *** Saving seen data "./dancer.seen" 08.40.08 Quit perrikwp (Ping timeout: 244 seconds) 08.41.04 Quit Scromple (Read error: Connection reset by peer) 09.03.45 Join ender` [0] (~ender@foo.eternallybored.org) 09.07.42 Join LinusN [0] (~linus@giant.haxx.se) 09.18.12 # [Saint_]: have you got a drawing or something of where your cabbie viewports are supposed to be on the various targets? 09.19.00 # <[Saint_]> I do, yeah. One second. 09.19.07 # <[Saint_]> Howcome, btw? 09.19.08 # ignoring images I wonder if we can knock it down to one .wps that can scale the viewports correctly with percentag placement 09.19.25 # <[Saint_]> I sincerely doubt that. 09.19.33 # <[Saint_]> Its not linear. 09.20.10 # sure it is 09.20.11 # <[Saint_]> The viewports are /approximately/ the same on each port...but, far from being scales of each other. 09.20.17 # <[Saint_]> very much so in fact. 09.21.22 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 09.21.36 Quit mc2739 (Read error: Connection reset by peer) 09.21.43 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 09.21.58 # you've got the top part (which is just the banner image), then the AA+info or info viewports which should cover some percentage of the screen (though maybe using negative values is good enough there?) 09.22.08 # and the bottom which is pretty static 09.23.23 # <[Saint_]> You would also need to scale the images as well. 09.23.28 Quit perrikwp_ (Ping timeout: 245 seconds) 09.23.55 # right, ignoring the images 09.24.26 # <[Saint_]> You'll see...for each port to work well, they needed quite a bit of manual tweaking. They're not just enlarged versions of each other (though they're reasonably close). 09.24.56 # <[Saint_]> http://dl.dropbox.com/u/30204410/viewport%20mockups.zip 09.25.01 # the skins have two problems, viewport placement/sizing and images... we could easily add some tag which ays "for this range of screen sizes append X to all image filename) 09.25.45 # I assume red is touch ares, purpole is images? 09.26.02 # purple* 09.26.02 Join lebellium_gs2 [0] (~lebellium@tmo-111-132.customers.d1-online.com) 09.26.27 # <[Saint_]> Nup :) 09.27.01 # <[Saint_]> Well, in some cases, yeah, but its not a strict rule. 09.27.06 # JdGordon :( the previous build works fine for me and the file browser doesn't seem to crash hum 09.27.26 # lebellium_gs2: it crashes on cabbie 09.28.11 # Ah... Ok so I can still use the build hehe 09.29.20 # <[Saint_]> yellow is the textual viewports for the no aa case, magenta (where epresent) is touch areas (but some red areas are both viewports and touch areas of the same exact size also), and the rest are basically only coloured to offer a visual distinction but if you're aware of the port and how the theme looks you can work it out. 09.30.00 # right 09.30.06 # <[Saint_]> Keep in mind, I made these for myself, and I'm colour blind. It wasn't eveer supposed to be a key for anyone else to use. 09.30.36 # <[Saint_]> I should be able to make that so, though, with rather minimal effort. I just can't do it now. 09.33.04 # <[Saint_]> Its not really until one sees that mockup that it becomes obvious that I'm using a metric f**k-tonne of viewports. 09.35.48 # you're using too many :) 09.37.03 # <[Saint_]> Nah, I don't think that "one viewport per item, even if static" is "wrong" per se...and think how difficult it'd be for you to work out positioning of individual images in a shared viewport if I didn't :) 09.37.17 # <[Saint_]> I had rotation aware positioning in mind from the get go. 09.37.26 # right 09.37.37 Quit lebellium_gs2 (Quit: Bye) 09.37.46 # but then you manually place them anyway, and rejected my viewport relative positioning scheme 09.38.15 # * JdGordon thinks we really are past the point where the skin engine just inst bloody good enough 09.39.04 # <[Saint_]> I went with what was currently implemented. Otherwise I would've been constantly redoing my work or sitting around waiting for some implementation to be finished or the bugs to be knocked out of it. 09.39.11 # <[Saint_]> I can't build themes with dreams :) 09.40.13 # bugger :p 09.41.32 # any suggestions for the tag for "draw rectangle"? 09.57.24 Quit bitcraft (Remote host closed the connection) 10.03.30 # <[Saint_]> is %dr too obvious? 10.04.22 # <[Saint_]> /most/ of our tags seem to at least try and be some form of acronym of their function or description. 10.04.31 # <[Saint_]> (with a few glaring exceptions) 10.09.13 Join nick_p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 10.09.59 # %dr is what im testing with, yeah 10.10.14 # what are the cabbie backdrop gradient start/end values? 10.12.57 Quit OzzieJacks (Remote host closed the connection) 10.13.49 Join OzzieJacks [0] (~OzzieJack@24-246-47-198.cable.teksavvy.com) 10.17.06 Join Youbi [0] (~youbi@AToulon-151-1-30-181.w83-197.abo.wanadoo.fr) 10.17.18 # Hello 10.17.50 Quit OzzieJacks (Remote host closed the connection) 10.17.55 # sometimes, while listening music, i get sort of jumps forward 10.18.31 # <[Saint_]> JdGordon: "Rockbox Grey" CCCCCC and "True Black" 000000 10.18.31 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 10.19.01 # <[Saint_]> Youbi: check your filesystem 10.19.11 # As if 1 second of the song was eaten by the codec 10.19.29 # [Saint_]: i’ll try it 10.22.44 # Nothing wrong :/ 10.24.15 # [Saint_]: if we wouldn't do any work unless the direction we want has been decided, rockbox would still only be half-working on the AJB 10.24.32 # <[Saint_]> WHat device is this, and, what version of Rockbox are you running? 10.24.34 # The way the direction is decided is by proving that an approach works 10.26.01 # <[Saint_]> gevaerts: Oh, sure...but from my standpoint I'm unwilling to say "Yes, its sane to go down this route" when in all likelihood someone else, or multiple someone elses, will likely pull it in a different direction. 10.26.12 # I’m running 3.9.1 on a sansa clip+ 10.26.18 # <[Saint_]> I just didn't want to personally say "Yes, do that". 10.27.06 # <[Saint_]> Youbi: That build is very old. 10.27.14 # <[Saint_]> Please try with at least the current release. 10.27.36 # <[Saint_]> Preferably with a build from HEAD 10.28.20 # Ok, thanks :) 10.29.18 # [Saint_]: with that reasoning nobody would ever offer any opinion at all! 10.30.02 # <[Saint_]> Youbi: The upside of installing the current build (not the current release) is that you will have functional USB in Rockbox. 10.30.31 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.31.07 # Oh, great 10.31.15 # <[Saint_]> gevaerts: Not necessarily, no. I treat this as different insofar as in some situations, no one knows what to do, so any suggestion is a good one. In this situation there's at least three individuals working on the idea, all with slightly or not so slightly different visipons on how to approach it. 10.31.19 # But is there a way to install rockbox without the GUI ? 10.31.51 # <[Saint_]> Yes, of course there is. But it is far easier to do so with RBUtil. 10.32.22 # <[Saint_]> The manual method involves checking out mkamsboot from the Rockbox Git repository, and patching a firmware manually. 10.32.34 # Yes, but get qt and compil with is boring. 10.32.48 # Oh god. So KISS 10.34.08 # <[Saint_]> RBUtil is specifically designed to "just do everything for you". It is by far the easiest method of installation. 10.35.28 # [Saint_]: uhm, there *are* mkamsboot binaries available for download 10.37.19 # <[Saint_]> Well, yeah, sure. Good point. Its still orders of magnitude easier to use RBUtil though. 10.37.51 # Yes, but qt is so… lightweigt… 10.38.07 # I wouldn't think that for using the Rockbox Utility compiling is involved 10.38.13 # Youbi: you don't actually have to build it yourself, you know 10.38.29 # <[Saint_]> pixelma: ? 10.39.18 *** Saving seen data "./dancer.seen" 10.39.33 # gevaerts: yes, unless i wanna use current version 10.39.53 # <[Saint_]> Youbi: The point of having a GUI installer is that someone already did the work for you. 10.39.55 # <[Saint_]> see: http://www.rockbox.org/download/ 10.40.07 # <[Saint_]> you can still install the current version with RBUtil. 10.40.44 # <[Saint_]> In fact, you can install the release, the current, and archived daily builds unless I'm mistaken. 10.41.04 # or do you mean a current version of the Utility? I'm a bit confused 10.42.01 # <[Saint_]> Well, if he does: http://tinyurl.com/rbutil-dev 10.42.47 # [Saint_]: only windows binaries there I believe 10.42.56 # I was confused too :/, i’ll use RButil to install last version of rockbox 10.42.59 # Sorry 10.48.22 Join Riviera [0] (~Riviera@92.51.147.16) 11.26.12 # would anyone mind if i change the default for dircache to be OFF for sim builds? 11.29.44 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 11.29.55 # Commit cde74aa in rockbox by 03Amaury Pouly: (Author: Jean-Louis Biasini) Fuze+: update minor keymaps mapping for manual consistency/simplicity 11.31.20 # Commit dcc78cb in rockbox by 03Amaury Pouly: (Author: Jean-Louis Biasini) Fuze+/calendar's plugin update keymaps and manual 11.31.25 # <[Saint_]> JdGordon: I wouldn't see why not, but, what is the reasoning for doing so? 11.32.34 # because it takes about 15s to start debugging once i simlink my music directory into simdisk so its usable 11.32.46 # cde74aa build result: 4 errors, 1 warnings (Jean-Louis Biasini committed) 11.32.54 # Oh, is that why? 11.33.01 # * gevaerts doesn't mind 11.34.55 # hum, someone should fix warble 11.35.02 Quit Keripo (Quit: Leaving.) 11.35.39 # dcc78cb build result: 0 errors, 2 warnings (Jean-Louis Biasini committed) 11.41.11 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 11.41.19 # JdGordon: Why not use a subdirectory of your music directory? 11.41.34 # Not that I mind either :) 11.42.32 Quit domonoky (Client Quit) 11.42.58 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 11.43.10 Nick kaner_ is now known as kaner (~kaner@zzz.strace.org) 12.11.43 Join anewuser [0] (~anewuser@190.207.136.156) 12.11.44 Quit anewuser (Changing host) 12.11.44 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 12.14.39 Quit domonoky (Read error: Connection reset by peer) 12.24.17 Join Thra11 [0] (~thrall@87.112.233.69) 12.31.03 # [Saint_]: re: removig CustomWPS, sure, but someone needs to fix the manual 12.31.14 # and personally i think the manual is the wrong place for it anyway 12.32.06 # <[Saint_]> JdGordon: I started compiling a list of missing tags that night. And I'll be comparing that with the parser code to make sure I haven't missed any. 12.32.46 # <[Saint_]> And, I kinda agree...but the manual is "the official documentation" and there's an air of obligation to update it, while the wiki can go untouched for a long time. 12.33.14 # yes, there should be a seperate proper guide to skinning that doesnt belong in the manual 12.37.14 # seriously, to do it properly it needs a full chapter of explanation, in addition to the existing tag listing 12.39.22 *** Saving seen data "./dancer.seen" 12.45.29 # Ideally *not* written in TeX because that sucks ass! 12.46.46 Join anewuser_ [0] (~anewuser@190.207.136.156) 12.47.05 # The theme language has evolved to the point (with all the viewports) that to a non-programmer, it's completely opaque and there's a huge barrier to entry to get started on making a nice theme (I think) 12.48.01 # right 12.48.09 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 12.48.10 # Artist-y people and people with a bent for programming is a pretty small overlap, I'd think :) 12.48.13 Quit [Saint_] (Quit: Quit) 12.48.27 Quit Thra11 (Ping timeout: 245 seconds) 12.49.04 Quit anewuser (Ping timeout: 255 seconds) 12.50.39 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 12.51.31 Join [Saint__] [0] (~Saint]@unaffiliated/saint/x-8516940) 12.51.48 Quit [Saint] (Read error: Connection reset by peer) 12.53.15 # evilnick: time to dig in and make a gui theme editor then. how hard can it be? 12.54.00 # heh 12.54.27 # * Torne might suggest a much more verbose and "magic" theme language (e.g. not having to manually specify viewports and the like), and a compiler for it 12.54.50 # Commit 014a08c in rockbox by 03Jonathan Gordon: skin_engine: New tag to draw a rectangle (optionally with a gradient) 12.55.10 # right, readable keywords instead of tags would probably help a bit 12.55.10 Quit [Saint_] (Ping timeout: 252 seconds) 12.55.28 # well, also i'm thinking of things like a hierarchical structure so you can specify layering more sensibly, etc 12.55.46 # something that requires a "real" parser 12.55.58 Join Thra11 [0] (~thrall@87.112.233.69) 12.55.58 # XML! 12.56.10 # if you like. it's not the worst way. 12.56.16 # i'd prefer not, but that wouldn' tbe terrible 12.56.59 # doing it in a gui is always going to be better 12.57.14 # You say that, but people still write HTML in a text editor instead of in a WYSIWYG editor 12.57.15 # It would be an improvement to what we have now - from the perspective of someone who wanted to make a theme but was put off by the arcane %sT|50|42|a|b|c style of things :) 12.57.30 # Named keywords, named attributes, and grouping/nesting, would go a long way 12.57.36 # Torne: THIS! 12.57.47 # 014a08c build result: 132 errors, 0 warnings (Jonathan Gordon committed) 12.57.53 # evilnick: we havnt had that syntax for more than a year! 12.58.10 # arg 12.58.14 # XML would be one way to do that which a lot of people are already familiar with in concept 12.58.36 Quit nick_p (Quit: Leaving) 12.58.40 # i'd probably do it in YAML :) 12.58.56 # It wasn't a serious example, but I bet I can find something similar from CabbieV2, or at least [Saint]'s work on the RaaAa port 13.01.03 # Torne: I think the bigger issue is the difficulty in seeing the output more than writitng it 13.01.09 # which is why the editor would be better 13.01.25 # i'm really not sure that's true 13.01.35 # I disagree 13.01.36 # JdGordon: you have my vote. go go go! :-) 13.01.43 # couldn't the simulator grow the ability to preview a skin "live"? 13.01.54 # being edited by an arbitrary external editor 13.02.01 # and jsut re-parsing and redisplaying it when it changes 13.02.06 # i suppose checkwps *could* 13.02.10 Join MethoS- [0] (~clemens@134.102.106.250) 13.02.16 # Torne: that's a neat idea 13.02.24 # well, i say the simulator because then we could reuse the entire existing skin engine 13.02.27 # 100% compatibility 13.02.29 # To me, having more explicit names for the various tags would help the new artist understand what each of them are doing. 13.02.39 # That on its own might be a great help, even with the current syntax :) 13.02.58 # it doesn't have the divergence problem that an editor would 13.03.05 # (and did, in fact) 13.03.06 # sure 13.03.10 # Wasn't there some talk a while back about using XML (or YAML!) which would get "compiled" into the proper theme language? 13.03.26 # probably :) 13.03.32 # As like an additional layer so that it'd be human-readable 13.03.39 # if the input format was sufficiently reasonable you could do the compilation in a plugin, even 13.03.44 # Commit 182a6c8 in rockbox by 03Jonathan Gordon: Fix compile errors 13.03.50 # and then people would be able to load the human readable ones on device. 13.04.19 # but anyway. changing the format is kinda independant of how to make edit/preview easier 13.04.51 # i think getting the simulator to be able to reload a being-externally-edited skin "live", and give you parsing errors or output, as appropriate, would be great, and probably not that hard 13.05.20 # much easier than implementing a working WYSIWYG editor 13.05.39 # And it'd stay up-to-date without any additional effort 13.05.43 # indeeed 13.05.44 # * evilnick likee 13.05.51 # plus people can actually play music, change settings, etc 13.05.59 # to see trivially how the skin changes as state changes 13.06.37 # 182a6c8 build result: All green 13.06.50 # if you add the bits to get notified if the loaded skin file changes on disk, i'll make the rest work 13.07.02 # * JdGordon reall needs to get debugging going in the sim again too 13.07.08 # that sounds reasonable 13.07.17 # a basic attempt could just poll, which will work on all OSes :p 13.07.27 # just poll stat() in the background every few seconds 13.07.30 # not a big deal on a host PC 13.07.41 # and reload if mtime changes 13.08.00 # actual file-chagne notification might be nice, but is probably not worth it for this limited case 13.09.49 # step 1, fix the lack of debugging in the sim 13.10.08 # well, that's also kinda independant, i think 13.10.12 # it would definitely be nice. 13.19.44 Quit evilnick (Quit: Bye) 13.20.04 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 13.21.08 # Is anyone looking at test builds functionality of our buildfarm? 13.26.42 # [Saint__]: soo.... don't kill me buuuuut..... 13.26.56 # Commit 5edae54 in rockbox by 03Jonathan Gordon: skin_engine: Reenable skin debugging in the sim (use --debugwps) 13.27.31 # <[Saint__]> What, why would I? 13.27.54 # <[Saint__]> It's been a long time coming :) 13.27.59 # :) because it was a 5min fix that should have been done months ago 13.28.50 # <[Saint__]> *cough* year(s)? *cough* 13.29.21 # <[Saint__]> Its been broken since before the very first 'bug's skin break :) 13.29.23 # 5edae54 build result: 23 errors, 3 warnings (Jonathan Gordon committed) 13.29.35 # GROAN 13.29.40 # <[Saint__]> *big skin break 13.29.53 # JdGordon: probably not yours 13.30.07 # yay, they arent :) 13.30.24 # cb9bc3b got exactly the same error 13.30.44 # By the way, would that be safe for 3.11? 13.31.00 # sure 13.31.05 # Most people make skins for stable releases I think 13.31.14 # ok, hang on 13.31.54 # Commit 9837bc3 in rockbox v3.11 by 03Jonathan Gordon: skin_engine: Reenable skin debugging in the sim (use --debugwps) 13.31.59 # too easy :) 13.32.12 # Thanks! 13.32.19 # Slasheri: ping 13.32.20 # not like crappy svn! :D 13.32.44 # * gevaerts wants to disable dircache persistence in 3.11 13.32.56 # <[Saint__]> Now...if only there was an existing 480x800 target... 13.33.07 # use the sdl-app if you can build it 13.35.02 # it would be nice if the sdl-app simulator target built 13.38.12 # * [Saint__] thinks that sdl apps (in the existing supported raaa resolutions) and device specific sims should be in the build system. 13.38.34 # <[Saint__]> Perhaps not built per-commit, but, daily. It'd be nice. 13.39.02 # [Saint__]: for which OS? 13.39.25 # <[Saint__]> ALL TEH OSes! 13.39.30 # Also, the sims are in there! 13.39.33 # * gevaerts hides 13.40.27 # <[Saint__]> Are they in there like RaaA is in there? As in built but never distributed? 13.40.36 # yes 13.40.48 # <[Saint__]> Stoopid. 13.40.50 # Why? 13.40.51 # <[Saint__]> :) 13.41.05 # Distributing them isn't a three minute change 13.41.24 # <[Saint__]> Because sims are useful, and were it not for rasher there wouldn't be any. 13.41.34 # <[Saint__]> *any available 13.41.59 # they're built on Linux 13.42.10 # so not terribly useful for distributing 13.42.17 # Why they should be available ideally and why not having them uploaded is stupid are two rather different questions 13.43.27 # <[Saint__]> rasher: there's not /too/ much involved to build on Linux for Windows (wrt sims) 13.44.04 # There is. You're asking for people to install the same mingw environment on rather diverse systems 13.44.17 # And also compile sdl 13.44.20 # That's *not* trivial 13.44.22 # which is a bit annoying 13.44.46 # Could be done on at least "enough" systems that it was there, I bet 13.45.08 # <[Saint__]> It only need be one machine, really. Hell, even if they were done weekly it'd be a massive improvement IMO. 13.45.49 # <[Saint__]> You can also just grab an SDL binary pre-built, no need to build one (which I'll admit is a pita). 13.46.13 # You need sdl stuff for building don't you? 13.46.17 # So what you're basically asking for rasher's stuff to be hosted on rockbox.org somewhere? 13.46.30 # s/what// 13.47.25 # <[Saint__]> Not /really/, but, close. I'd also like more targets added (namely sdl apparently for the supported raaa resolutions). 13.47.38 # <[Saint__]> Then the sims would be "complete". 13.48.29 # <[Saint__]> I've noticed people freak out at the warning rasher gives re: his sims, and think their systems will explode or the world will end if they use them...that is, if they find them. 13.49.09 # I build my sims using the release script, so it's not like it takes a lot of work 13.49.11 # <[Saint__]> The warning is justified, but people see it as "unofficial" and not to he trusted. 13.49.15 # <[Saint__]> *be 13.49.57 # [Saint__]: to be honest, I trust rasher's sims more than I'd trust sims built by the build system :) 13.49.59 # rasher: if you're willing to keep that going it seems reasonable that we could host that on rockbox.org, with a notice saying it's best-effort :) 13.50.06 # * [Saint__] sees an autocomplete error. 13.50.22 # There's actually no warning on the sims page I think? 13.50.23 # <[Saint__]> s/apparently/app/ 13.50.25 # Just the android builds 13.50.36 # I can't find a warning anyway 13.51.11 # I can create an upload account if you think we should host them on rockbox.org instead 13.51.14 # <[Saint__]> Hum...my mistake, sorry. I must've confused the android builds. 13.52.58 # <[Saint__]> Would it be a massive f**k-tonne of effort to add Windows SDL sims as well? I assume people would also like to "test-drive" raaa as well. 13.53.07 # [Saint__]: yes 13.53.18 # <[Saint__]> That's a shame. 13.53.20 # AFAIK that won't even build currently 13.54.05 # Zagor: if everyone's fine with it, just say the word 13.55.19 # <[Saint__]> Now jd has fixed up skin debugging, the sims are also quite useful again for themers too. 13.56.46 # I'm often tardy about making the release sims though :\ 13.58.58 # rasher: any reason for that apart from not remembering? 13.59.32 # Not really, no 13.59.51 # Also it takes effort! Finding the release tag and checking out to it :) 14.00.06 # Well, yes :) 14.00.18 # But no good reason, no 14.00.25 # But that means adding "poke rasher" to the release checklist would probably help a bit at least 14.00.45 # heh, yeah 14.01.08 Quit mortalis (Ping timeout: 248 seconds) 14.01.14 # * gevaerts makes a note of this :) 14.04.08 # <[Saint__]> I'm going to be overhauling my home server in a few weeks, and when I do so I'll have ~90% of the previous server as superfluous, and a fat pipe with unlimited data. When the time comes, I'll look into dedicating that to building windows/linux sdl apps, and possibly sharing some of rasher's machine's workload for the sims if necessary. 14.15.45 Join anewuser [0] (~anewuser@190.207.136.156) 14.15.45 Quit anewuser (Changing host) 14.15.45 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 14.17.55 Quit anewuser_ (Ping timeout: 252 seconds) 14.21.07 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 14.21.20 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.22.19 Join funman [0] (~fun@rockbox/developer/funman) 14.24.09 Quit [Saint__] (Read error: Connection reset by peer) 14.28.15 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 14.31.19 Quit perrikwp (Ping timeout: 260 seconds) 14.39.23 *** Saving seen data "./dancer.seen" 15.01.35 # Commit a4fd5bf in rockbox by 03Amaury Pouly: imx233: enable charging in bootloader USB mode by including powermgmt 15.01.35 # Commit 9caffa8 in rockbox by 03Amaury Pouly: imx233/fuze+: rework i2c and fmradio_i2c init 15.04.18 # 9caffa8 build result: All green 15.08.40 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 15.10.30 Join mortalis [0] (~mortalis@77.108.98.176) 15.17.00 Join passstab [0] (~v@c-68-80-37-73.hsd1.pa.comcast.net) 15.18.31 Quit Lalufu (Quit: Changing server) 15.25.01 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 15.25.33 Quit wodz (Quit: Leaving) 15.46.09 Quit [Saint] (Remote host closed the connection) 15.48.04 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 15.49.01 Part LinusN 15.56.21 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 16.00.16 Quit bitcraft (Remote host closed the connection) 16.00.27 Join freqmod_s [0] (~freqmod@2001:700:303:8:21a:4dff:fe4f:4e67) 16.01.07 Quit freqmod_s (Remote host closed the connection) 16.19.07 Join shanttu [0] (~shanttu@dsl-hkibrasgw3-ffdec300-4.dhcp.inet.fi) 16.22.34 # When plugged in, what is the significance of the flashing lightning bolt on the battery as opposed to the plug symbol? 16.23.39 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 16.26.16 # plugged in, and plugged in + charging 16.26.21 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 16.33.46 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 16.36.35 # ok. thought it might be. It used to be different, so for a while I wasn't sure if the icons had changed or my battery had started doing something different 16.38.19 # <[Saint]> Are you talking about a particular theme? 16.38.58 # <[Saint]> If you're talking about the default, it hasn't changed in...a looooooong time. 16.39.18 # Hmmm. just the theme I use has changed then 16.39.27 *** Saving seen data "./dancer.seen" 16.40.07 # Which is a bit odd, since when I upgraded rockbox I'm not sure I downloaded a newer version of the theme.. 16.40.28 # <[Saint]> What theme is this? 16.41.01 # let me check 16.42.27 # CabbieV3mod I think 16.43.27 # <[Saint]> Settings - Theme Settings - Browse Themes 16.43.38 # <[Saint]> will tell you definitively. 16.44.11 # nope. just lists all available themes. no indication which one is active 16.44.28 Quit mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/) 16.44.44 # <[Saint]> The active theme should be the one highlighted on entry. 16.45.58 # the one highlighted is the one at the top of the list. but anyway, it's definitely CabbieV3mod 16.47.00 # <[Saint]> If you didn't specifically update it, it didn't update. 16.47.10 # True 16.47.44 # <[Saint]> RBUtil does nothing automatically (not in this sense, at least). 16.47.59 # <[Saint]> So, you probably only just noticed it. 16.48.26 # RBUtil does nothing whatsoever if you don't use it :p 16.49.11 # I guess either I didn't notice it before, or I redownloaded the theme and forgot 16.50.05 Join antil33t [0] (~Ahurhurr@101.98.150.103) 16.50.07 # <[Saint]> You can easily check when the last theme update was on the website. 16.52.16 # <[Saint]> I'm fairly confident cabbiev3 just uses the built in status bar, though, which definitely hasn't changed. 16.54.56 # <[Saint]> I don't recall touching it at least, and even if I did it was a couple of years ago. There's a chance cabbiev3 uses its own status bar but I seem to recall it just uses the built in one. 16.57.07 # * Mir thinks cabbie3 is more popular than rockboxed 16.57.23 Join bakdafukup_2002 [0] (~bakdafuku@host-195-123-111-24.midco.net) 16.57.37 # i could be wrong 16.57.44 # * Mir lurks off 16.57.55 # * [Saint] thinks that's a very speculative statement 16.58.33 # it is 16.58.34 # ez peeps... i was wondering if their is anyway to increase the transfer speed im only gettin like 20kb/s when transfering to my device? 16.59.26 # bakdafukup_2002: is there anything else transfering large amoutns of data on the USB interface? 17.00.14 # not at the same time i dont 17.00.29 # i found that if i am transfering multiple groups of files like lets say 4 different discogropharies in FLAC my speeds slows down to 56kb/s 17.00.51 # * gevaerts misses some rather essential information 17.00.54 # while if i do one i get 5mb/s 17.01.04 # Such as model, OS used, rockbox version 17.01.18 # yeah, that was the speed i was getting doing them one by one lol 17.02.04 # could it be my ipod? 17.03.01 # <[Saint]> It could be a host of things, but you've given approximately no information to discern the problem if any. 17.03.38 Quit Thra11 (Quit: kthxbai) 17.06.12 # well i told you all i know.. Its transferring slow and i was curious if they're ways of increasing the speed 17.07.30 Quit bitcraft (Remote host closed the connection) 17.08.18 # and i mentioned it might not be the ipod 17.08.21 # You've told us very little! What model of ipod, what OS on your computer, what version of rockbox all can affect the transfer speed 17.08.25 # it may be some background thing 17.08.51 # * Mir agrees with evilnick 17.09.33 # its a ipod classic 120gb running hte newest version of rockbox and im on windows 7 64bit 17.09.56 # 3.9, 3.10 or 3.11 or daily builds 17.10.19 # Mir: there are no 3.x releases for the classic 17.10.22 # The newest version? What does it say under System > Rockbox Info 17.10.25 # And there's no 3.11 for anything 17.10.54 # Also, I got confused earlier. Did you say it's faster if you only start one single copy operation at a time? 17.11.25 # thats what happens for me 17.11.28 # its the same speed for me if i add one folder at a time or many 17.12.21 # If you start one copy operation of one artist folder (for example) and then another copy operation, and then another, then each copy operation can only use a fraction of the 5MB/s speed 17.12.24 # the version is r31516-120101 17.12.33 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 17.12.37 # That's ages old, not current 17.12.39 Quit n1s (Changing host) 17.12.39 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.12.42 # oh 17.13.18 # well i had to use emcore to be able load it on the classic 17.14.00 # i just used what they told me to download, figured it was the newest version.... can i download the newest version and just add it? 17.14.28 Join mshathlonxp [0] (msh@84.237.141.70) 17.15.33 # <[Saint]> Of course, however, if you read while you were installing it you would know that USB on the Classic is very highly sub-optimal. 17.15.44 # <[Saint]> Its a known issue. 17.17.04 # <[Saint]> It doesn't even mount on some operating systems. Basically, be thankful it does transfer at all. 17.17.15 # is that release december 1st 2001? 17.17.33 # Mir: huh? 17.17.35 # Mir: Probably 2012-01-01 17.17.42 # whew 17.17.42 # <[Saint]> Mir.....seriously? 17.17.50 # <[Saint]> Think dude, think. 17.17.58 Join TheLemonMan [0] (~LemonBoy@adsl-ull-108-220.50-151.net24.it) 17.18.02 # i did 17.18.02 # Or it could have been before the iPod Classic was designed :) 17.18.08 # usualy month day year 17.18.25 # <[Saint]> Obviously, as that's perfectly sane, right? ;) 17.18.51 # <[Saint]> We always have ports out before the product its designed for is even invented. 17.18.59 # also i only recently rolled out of bed onto the keyboard so i am not fully awake 17.19.02 # <[Saint]> We're really timelords. 17.19.09 # yea 17.19.18 # time is only a wibbly wobbly thing 17.19.22 # evilnick: the first ipod was only 2 or so months old at that time 17.19.28 Quit n1s (Read error: Operation timed out) 17.19.31 # alright guys.... cheers for the help... 17.19.41 # scorche|sh: Can't get much more classic than the original... 17.20.39 # on the Fuze to get the rockbox usb connectivity do i have to wait until 3.11 comes out or is it avalible on the daily builds 17.21.34 # <[Saint]> You could always try and see, no? 17.22.06 # i'd rather not kill the fuze like i did the clipv2 17.22.13 # which didnt brick 17.22.16 # it died 17.22.56 # <[Saint]> Ok, then don't update ever and live in fear for the rest of your life. Its up to you. ;) 17.23.21 # hehe 17.23.45 # the reason i ask is on the wiki it says something about upgrading to the "current build" 17.24.14 # <[Saint]> Right, so, you think its a fallacy there just to trick you? 17.24.17 # i just needed some claification on what "current build" is 17.24.26 # no 17.24.35 # Mir: how long have you been in this channel now? 17.24.39 # It's a build that looks a little like a raisin 17.24.43 # <[Saint]> Current build == (wait for it...) current build, unsurprisingly. 17.25.03 # :| 17.25.11 # i thought it was the build for devices that want to charge faster 17.25.24 # so that means its still the 3.10 build which has no usb connectivity 17.25.31 # <[Saint]> Nah, that's the high-current build. 17.25.36 # <[Saint]> :) 17.25.42 # Mir: a current build is a build of current source code 17.25.43 # ok 17.26.02 # <[Saint]> Mir: really? You're actually serious aren't you? 17.26.05 Quit bakdafukup_2002 (Remote host closed the connection) 17.26.09 # yes 17.26.21 # i am serious 17.26.54 # <[Saint]> We have a distinction between release and current for a reason. Current is always a later version than the release. 17.27.40 # where does the daily build fit in? 17.27.48 Join Strife89 [0] (~Strife89@207.144.201.128) 17.28.16 # That's basically a current build from at most one day old 17.28.26 # ok 17.28.28 # <[Saint]> Release can be anywhere up to 4 months old, current can be updated several times per day, daily (unsurprisingly) is built once daily, to clarify. 17.28.51 # thats good to know 17.28.58 # thank you for clarifying 17.29.22 # <[Saint]> Is the wording non-obvious? Could we improve on it somehow? 17.29.31 # no 17.29.34 # <[Saint]> (Serious question) 17.29.47 # I guess "current" could be called "latest" 17.31.01 # I think changing that is going to be rather difficult 17.31.04 # its just that "current" is much harder to find and the fact that daily is basicly == to current although it may be a few days older than 'current build' from what i understand you are telling me 17.31.21 # rather not have it changed for one person 17.31.22 # * [Saint] votes for "Super-Happy-Fun-Time-Mega-Surprize Build" 17.31.31 # I for one wouldn't know where to find the daily builds 17.31.33 # just a definition somewhere would be nice 17.31.53 # thats another issue i had 17.32.23 # <[Saint]> Well, this is also why there's date stamps. 17.32.36 Part Zagor 17.32.42 # the wiki would not let me register so i could post some hardware for donation 17.33.13 # kept saying my username was innappropriate 17.33.32 # * Mir doesnt know how Mir is an inappropriate username 17.33.57 # The instructions there do mention us wanting real names I think 17.34.08 # ahh 17.35.35 # that clarifies that. 17.35.37 # thank you 17.35.39 Join saratoga [0] (980329b4@gateway/web/freenode/ip.152.3.41.180) 17.35.41 # * Mir lurks off to work 17.35.48 # <[Saint]> Reading instruction usually does. 17.38.37 Quit ved (Ping timeout: 260 seconds) 17.43.21 Join ved [0] (~ved@2001:41d0:1:5914::2) 17.43.23 Join XMen [0] (~r0uz@123.136.106.194) 17.45.57 Join bitcraft_ [0] (~bitcraft@66.254.199.148) 17.49.46 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.58.26 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 18.01.47 Quit XavierGr (Ping timeout: 276 seconds) 18.02.01 # pamaury: thanks for the push, are you planning some more modification on the bootloader soon? Or can I update the bootloader on the wiki page now? 18.02.41 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 18.05.01 Quit alexbobp (Ping timeout: 245 seconds) 18.05.17 Quit TheLemonMan (Quit: WeeChat 0.3.7) 18.07.19 # You should probably update it, charging in the bootloader is really useful 18.07.51 # ok 18.08.51 # We could test it like for a week and then send it on the server in order to have rockboxutility also handling it 18.10.00 Quit Rower85 (Read error: Connection reset by peer) 18.10.49 # yeah, we will need to do a bootloader at some point 18.11.27 # I have a question regarding g#173 : where did you get the image ? 18.11.29 # 3Gerrit review #173 at http://gerrit.rockbox.org/r/#change,173 : Fuze+ simulator: update image with keys indication by Jean-Louis Biasini (changes/73/173/1) 18.12.44 # also did you saw that? FS#12592 are you planning to work on it or can I start with it? 18.12.44 # http://www.rockbox.org/tracker/task/12592 3mkimxboot calls exit() on errors (bugs, new) 18.13.07 Join Topy44 [0] (Topy44@g228171006.adsl.alicedsl.de) 18.13.28 Quit [Saint] (Remote host closed the connection) 18.14.57 # pamaury: the image is the one I made for the manual 18.15.09 # I just added number on it 18.16.34 # I made it from scratch in inkscape so no copyright issue here if this is your concern 18.16.44 Quit T44 (Ping timeout: 272 seconds) 18.17.02 Quit bluebrother (Disconnected by services) 18.17.10 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 18.19.25 Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) 18.19.28 Quit remlap1 (Client Quit) 18.19.38 Quit fs-bluebot (Ping timeout: 260 seconds) 18.21.16 Quit remlap (Ping timeout: 246 seconds) 18.21.28 Join fs-bluebot [0] (~fs-bluebo@g225253105.adsl.alicedsl.de) 18.21.31 # pamaury: also regarding backlight and button issue, this one could be related: FS#12594 18.21.31 # http://www.rockbox.org/tracker/task/12594 3[Fuze+] Unexpected behavior of touchpad when backlight is off (bugs, new) 18.24.53 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 18.36.49 Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) 18.37.31 # pamaury: wiki updated 18.37.39 # ok thanks 18.38.22 # so are you planning something on FS#12592 18.38.22 # http://www.rockbox.org/tracker/task/12592 3mkimxboot calls exit() on errors (bugs, new) 18.38.28 # ? 18.38.35 # by the way, I will commit an update that add an ADC channel of which the value can be read in the debug menu, if you can have a look at it regularly and tell me if the value is really different from VddIO that would be nice 18.38.46 # jlbiasini: it's already fixed I think 18.38.55 # ah ok 18.39.07 Quit remlap (Ping timeout: 246 seconds) 18.39.28 *** Saving seen data "./dancer.seen" 18.39.38 # I'll ask bluebrother but I fixed all calls to exit for really unlikely errors 18.40.12 # pamaury: I don't understand what do I could test? 18.40.33 # wich value? 18.40.47 # battery power? 18.40.57 # go into debug menu > HW Info, third screen: there a few values (battery, vddio, vdd5v) 18.42.14 # I will add one called "channel 2". The OF reads it but I'm unable to determine what it does with it, so I'm trying to understand its meaning but I've never found a situation where it's mostly different from vddio 18.42.16 # ah ok so I'll wait your commit, update rockbox and go to this screen to compare the values 18.45.16 Quit evilnick (Remote host closed the connection) 18.46.45 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 18.46.52 Quit evilnick (Remote host closed the connection) 18.47.23 Quit XavierGr (Ping timeout: 255 seconds) 18.48.44 # pamaury: is your last push supposed to solve radio bug? 18.49.00 # because on my device it won't 18.49.05 # no, it's just code simplification 18.49.40 # Commit e07b22f in rockbox by 03Amaury Pouly: fuze+: add unknown channel to debug menu 18.50.08 # I'm now pretty convinced that the radio problem happen when some i2c transfers with the tuner chip fail 18.50.23 # then the code never manages to read some registers again and get stuck in a loop 18.51.03 # backlight seems to confuse the touchpad on other occasion to FS#12594 18.51.03 # http://www.rockbox.org/tracker/task/12594 3[Fuze+] Unexpected behavior of touchpad when backlight is off (bugs, new) 18.51.33 # yes, it creates some interferences it seems. The touchpad is also i2c driver 18.51.34 Quit MethoS- (Ping timeout: 272 seconds) 18.51.35 # *driven 18.52.04 # e07b22f build result: All green 18.52.09 # I alos notice that somatime the touchpad run crazy 18.52.15 # yeah, me too 18.52.41 # ok I'll test the new value 18.53.07 Quit remlap1 (Ping timeout: 246 seconds) 18.53.58 # I also noticed something which could explain some weird behaviours: VddIO is usually 3.6V (you can see the value in the debug menu, it's in mV). But sometimes, the OF bootloader will set it to 3.0V only and then the device runs strangely 18.54.10 # I need to reverse more code to understand this behaviour 18.54.56 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 18.56.40 # pamaury: channel 2 *SEEMS* to be a little lower than vddIO like 10 18.57.45 # jep it's definitly a little lower 18.58.26 # 10 is completely negligeable, it's within measurement error 18.58.44 # if you see a different greater than 100, then it matters 18.58.47 Quit Sleepy_Coder (Ping timeout: 252 seconds) 18.59.02 # vddIO is about 3670 and channel 2 about 3650 18.59.11 # same thing for me 18.59.23 # except when VddIO is 3000 but I think it's not normal 19.02.45 Join anewuser_ [0] (~anewuser@190.207.136.156) 19.05.16 Join Sleepy_Coder [0] (~z_Z_z_Z_z@unaffiliated/sleepycoder/x-938672) 19.05.32 Quit anewuser (Ping timeout: 260 seconds) 19.19.26 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.19.26 Quit bertrik (Changing host) 19.19.26 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.22.56 Join alexbobp [0] (~alex@247-250-193-199.rdns.scalabledns.com) 19.26.20 Join lebellium [0] (~chatzilla@g231210184.adsl.alicedsl.de) 19.27.32 Quit remlap (Ping timeout: 248 seconds) 19.34.40 Quit alexbobp (Ping timeout: 255 seconds) 19.35.19 Join alexbobp [0] (~alex@247-250-193-199.rdns.scalabledns.com) 19.38.59 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 19.43.00 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 19.44.48 Quit remlap (Client Quit) 19.55.29 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 19.57.56 Quit alexbobp (Ping timeout: 248 seconds) 20.10.45 Join alexbobp [0] (~alex@246-250-193-199.rdns.scalabledns.com) 20.15.15 # pamaury, any luck with the fuze+ fmradio stuff yet? 20.35.26 Quit Strife89 (Ping timeout: 255 seconds) 20.39.30 *** Saving seen data "./dancer.seen" 20.44.13 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 20.45.42 # pamaury, candidates for the unknown adc channel could be battery temperature, charge current, or battery current 20.48.09 # battery current hsould be easy to test, just change the screen brightness 20.50.13 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 20.50.13 Quit curtism (Changing host) 20.50.13 Join curtism [0] (~curtis@unaffiliated/programble) 20.50.15 Quit passstab (Read error: Connection reset by peer) 20.57.10 Quit scorche|sh (Changing host) 20.57.10 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 20.58.44 Quit bitcraft_ (Remote host closed the connection) 20.59.08 Join bitcraft [0] (~bitcraft@66.254.199.148) 21.03.08 # saratoga: pamaury: so it's not battery current: i set backlight to 5 and still had the same value 21.03.32 Quit benedikt93 (Quit: Bye ;)) 21.04.46 # jlbiasini, does it change at all? 21.06.29 # put it in the freezer and see if its a thermistor 21.07.25 # but don't actually freeze it 21.08.04 Quit y4n (Quit: PANTS OFF!) 21.20.21 Join wodz [0] (~wodz@89-76-160-35.dynamic.chello.pl) 21.26.20 Join randumbum [0] (~IRCclient@c-71-193-176-198.hsd1.wa.comcast.net) 21.30.55 # the fact is that the value is pretty close to another one that is in mV 21.31.31 # ~3600 21.32.09 # saratoga: bertrik: so that might not be a temperature 21.35.51 # and no it doesn't seems to change. 21.38.51 Join TheLemonMan [0] (~LemonBoy@adsl-ull-108-220.50-151.net24.it) 21.42.25 Quit bitcraft (Remote host closed the connection) 21.42.50 Join bitcraft [0] (~bitcraft@81.sub-75-249-15.myvzw.com) 21.47.39 # jlbiasini: about your recent Rockbox Utility question: something I'd like to see implemented is a changelog dialog that can be used to (a) show the changes between Rockbox Utility releases and (b) the changes between Rockbox releases 21.48.22 # for that a simple text input is to be used. The simplest case would be showing a plain text without any formatting 21.48.41 Quit pamaury (Ping timeout: 264 seconds) 21.48.54 # (i.e. similar to the display of the speex license) 21.55.24 Join Strife89 [0] (~Strife89@adsl-068-213-037-174.sip.mcn.bellsouth.net) 21.58.28 # bluebrother: ok I will have a look at it 22.04.06 Quit TheLemonMan (Quit: WeeChat 0.3.7) 22.20.41 Quit wodz (Quit: Leaving) 22.23.02 # jlbiasini, do you know what the other ADC voltage channel is? 22.23.50 # I think I've seen on some sansas that there are two channels connected to the battery voltage, only during charging I see a difference 22.31.13 Quit shanttu (Remote host closed the connection) 22.33.16 Join MethoS- [0] (~clemens@134.102.106.250) 22.35.37 Quit n1s (Quit: Ex-Chat) 22.39.34 *** Saving seen data "./dancer.seen" 22.57.30 Join anewuser [0] (~anewuser@190.207.136.156) 22.57.37 Quit anewuser (Changing host) 22.57.37 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 22.59.50 Quit anewuser_ (Ping timeout: 265 seconds) 23.03.42 # bertrik: you should talk with pamaury about it. I was just doing some test for him. 23.04.36 # it seems the value is around 3600 but that sometime the OF set it 3000 23.06.22 Quit enthdegree (Ping timeout: 245 seconds) 23.14.53 Join bitcraft_ [0] (~bitcraft@66.254.199.148) 23.17.06 Quit bitcraft (Ping timeout: 240 seconds) 23.17.46 Join anewuser_ [0] (~anewuser@190.207.136.156) 23.19.16 Join Scromple [0] (~Simon@119.225.209.134) 23.20.56 Quit anewuser (Ping timeout: 276 seconds) 23.23.54 Part jlbiasini 23.31.22 Quit kadoban (Read error: Connection reset by peer) 23.31.59 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 23.32.21 Quit Strife89 (Ping timeout: 255 seconds) 23.33.21 Join kadoban_ [0] (~mud@97-124-67-238.phnx.qwest.net)