--- Log for 25.02.113 Server: pratchett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 9 days ago 00.04.01 Quit shamus (Read error: Connection reset by peer) 00.04.38 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 00.11.37 *** Saving seen data "./dancer.seen" 00.11.47 Join thegeek [0] (~thegeek@222.37.34.95.customer.cdi.no) 00.13.20 Quit thegeek_ (Read error: Connection reset by peer) 00.13.34 Quit lebellium (Quit: ChatZilla 0.9.90 [Firefox 20.0/20130220104816]) 00.29.11 # are we releasing 3.13 for the Recorder? 00.29.31 # * [Saint] apparently missed something 00.30.18 # <[Saint]> Hum, nope, still riddled with errors. 00.30.42 # <[Saint]> I guess I mis-parsed that as "we now have a working recorder build again" for some reason. 00.31.00 # nope 00.34.54 # It builds with one or two features disabled. See gerrit 00.37.19 # <[Saint]> Aha. 00.37.38 # <[Saint]> I'm pretty sure the 2 people that use the target won't mind that. 00.39.26 # thats awefully arbitrary 00.39.30 # why those feautres? 00.40.13 # <[Saint]> Why any other? 00.40.34 # well indeed 00.40.37 # <[Saint]> The thing weighs a tonne, you'll break your wrist flipping it. ;) 00.40.38 Quit prof_wolfff (Ping timeout: 260 seconds) 00.40.57 # <[Saint]> And, morse input is nice...but, it's a novelty, really, isn;t it? 00.41.27 # I imagine it is MUCH faster to type with than the keyboard if you know morse 00.41.54 Quit n1s (Quit: Ex-Chat) 00.42.02 # <[Saint]> Ah, without a scrollwheel, yes. 00.42.17 # even with. 00.42.31 # <[Saint]> But, then, the virtual keyboard/typing at all seems a bit of a novelty to me anyway. 00.43.19 # morse can be done w/o sight or voice and I don't know how good Rockbox's implementation is, but 30WPM should be easy for a trained individual. 00.43.38 # <[Saint]> I assume most people use the standard "built in" keyboard layout, which is *really* terrible. 00.43.50 # <[Saint]> If you use your own .kbd file, it's not so bad. 00.43.57 # The recorder doesn't have that many features to disable in the first place 00.45.37 # <[Saint]> scrape out the ten-thousand skin engine features it won't/can't use. 00.45.38 Join copper [0] (~copper@unaffiliated/copper) 00.46.13 # Those don't have easy defines to comment out 00.46.37 # [Saint]: they are all usable 00.46.58 # the swcodec ones are already ifdefed 00.47.08 Quit copper (Client Quit) 00.50.04 Quit ender` (Quit: Variables won't. Constants aren't.) 00.50.04 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 00.50.35 # <[Saint]> AH. My mistake. 00.51.04 # * [Saint] is slightly wary about touching themes for a while 00.51.26 # trust me, you'll appreciate it in the end 00.51.39 # <[Saint]> ...I was going to do that today, but, since a lot of my themes are more "exotic" than most, I think I'll leave it until you're finished. 00.52.02 # the only thing I'm touching is the list tags 00.52.11 # <[Saint]> I don't want to have to re-write the list drawing parts, which are pretty silly. 00.52.16 # <[Saint]> heh...yeah ;) 00.52.18 # but i really need to get discussion on how to make these new tags be useable 00.52.56 # <[Saint]> Can we have a new tag for the recursive next and current metadata? 00.53.09 # <[Saint]> I can't stress how much I dislike using the current ones. 00.53.13 # there is no need 00.53.15 # <[Saint]> *re-using 00.53.30 # it won't end up being non-obvious 00.53.42 # plus, its exactly as broken as the current WPS playlist viewer 00.53.58 # <[Saint]> Yeah, you ever see that in my themes? ;) 00.54.01 # so in actual fact, I guess noone will use the feature 00.54.08 # indeed 00.54.12 # so it makes no difference 00.54.36 # <[Saint]> It makes a difference if all of a sudden tags start doing one thing in one place, and another everywhere else. 00.54.40 # <[Saint]> Nowhere else does this happen. 00.54.43 # they wont 00.55.03 # it wont magically trigger, it requires the repeater tag and then only for that viewporet 00.55.40 # <[Saint]> I still think it would make more sense to not re-use it. 00.56.24 # we'll see... but anyway, thats not the part i want to talk about... the 2 new child viewport tags really need syntax help 00.56.44 # my goal is for them to be 100% posotion and sizeable at runtime 00.57.45 # <[Saint]> Why at runtime? 00.58.16 # perhaps you want to draw the line selector the width of the text, not the full line length 00.58.42 # or you want to stick 3 viewports next to eachother 00.58.51 # and you want to shaee the one skin file among every target 00.59.50 # <[Saint]> Am I the only one that actually thinks that skinned lists are ok or something? 00.59.56 # <[Saint]> Or, gevaerts and I? :) 01.00.15 # fine, but the code to make it work is horrendous 01.00.31 # and it cant do everything the drawn one can which means it cant be removed 01.01.06 # <[Saint]> I understand what you're doing, but this seems more cumbersome to me. 01.02.00 # <[Saint]> But my main objection is the horrid creature %i* turned into. 01.02.28 # relax :) 01.03.28 # <[Saint]> Oh, I'm calm. You'd know if I wasn't. There'd be a lot more four letter words being said ;) 01.03.35 # hehe 01.04.08 # <[Saint]> I'm not sure I can describe myself accurately. The behavior of %i* in your demo is something I would've called a bug. 01.04.10 # I *may* be open to adding a new prefix for this if it really matters 01.04.22 # <[Saint]> When that tag, everywhere else, only ever returns data for the current track. 01.05.30 # <[Saint]> maybe add a prefix or suffix to %I*...but, see, even then I wouldn't like the fact that the behavior in lists different from the other screens. 01.05.30 # but pretty please... %vs() and %vp() need alot of thinking about... %vc(id) will always create a child vp at (0,0) of the outer viewport, w/h are undefined... so %vs() and %vp() need to be used to get the correct size 01.05.34 # but how 01.06.19 # %vs(foo, copy) <- copy the 'foo' child viewports size? 01.06.45 # %vp(bar, left, 10) <- position this child on the left of bar with 10 pixel gap? 01.08.34 # <[Saint]> Just so I understand your lingo for parent/child, every user-defined viewport is a child, yes? 01.08.51 # <[Saint]> And the default (fullscreen) vp always the parent? 01.09.53 # <[Saint]> Ah, nope. Right. 01.11.16 # no 01.11.36 # %V() is a real viewport (the parent) 01.11.48 # %v*() is a child viepwort of exxactly one parent 01.12.10 # all %v's in a parent are siblings and can refer to eachother, but not to other parent's children vp's 01.12.46 # the reason for this is the skin engine needs a real viewport to move around convininetly (for the repeating) 01.12.56 Quit saratoga (Ping timeout: 245 seconds) 01.13.32 # my idea is each %vp/vs moves or sizes one aspect of the child, so you'd need to have a few in each child to get it where you want it 01.13.41 # though maybe not if tha gets unwieldy 01.13.45 # <[Saint]> ...won't this fuck the touchscreen list spacing? 01.13.59 # no 01.14.22 # remember, this is replacing the entire list ui code, (I'll add touchscreen caps on once it is working) 01.14.26 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 01.14.40 # the default list code will function identically to the current code 01.14.52 # but it will be skin drawn instead 01.16.49 # <[Saint]> as for vp() and vs(), I can't, at the moment, think of a way to do that that even works. Let alone is remotely sane. 01.17.10 # which is why its all in my head so far... im stuck too 01.17.19 # <[Saint]> I can't think of a way it could make sense if you wanted multiple vps to share the same ident 01.17.21 # but it needs to be this flexible or it wont work 01.18.25 # <[Saint]> as you might want to fire a bunch of vps at the same time (so same ident is easiest), but have them all in a differnet location, with different sizing. 01.18.32 # <[Saint]> ...and, things would get weird. 01.21.07 Quit thegeek (Read error: Connection reset by peer) 01.21.27 Join thegeek [0] (~thegeek@222.37.34.95.customer.cdi.no) 01.22.11 # I'm open to other suggestions 01.22.40 # my benchmark is if the current list can be drawn with the skin then its likely good enough 01.23.25 # but yes, it also gets very interesting if the current selection item should be a bigger size than the others (whichshould just work with my idea) 01.23.30 # <[Saint]> Wavy should probably be the benchmark ;) 01.23.50 # wavy isnt doing anything interesting imo 01.24.18 # <[Saint]> More so than I imagine cabbiev2 would be. 01.25.12 # some new tags I need to add... "%Vu()" to get the UI viewport rect, %?? to get the text length 01.49.54 Join mikroflops [0] (~yogurt@h-34-210.a238.priv.bahnhof.se) 01.52.15 Quit dv_ (Ping timeout: 248 seconds) 01.55.59 Join dv_ [0] (~quassel@chello080108009040.14.11.vie.surfer.at) 01.57.36 Join jhMikeS [0] (~jethead71@50.4.240.19) 01.57.36 Quit jhMikeS (Changing host) 01.57.36 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 02.11.38 *** Saving seen data "./dancer.seen" 02.12.46 Quit krabador (Ping timeout: 264 seconds) 02.15.14 Join krabador [0] (~krabador@host101-49-dynamic.1-87-r.retail.telecomitalia.it) 02.16.10 Quit krabador (Max SendQ exceeded) 02.16.39 Join krabador [0] (~krabador@host101-49-dynamic.1-87-r.retail.telecomitalia.it) 02.17.51 Quit krabador (Max SendQ exceeded) 02.18.21 Join krabador [0] (~krabador@host101-49-dynamic.1-87-r.retail.telecomitalia.it) 02.20.27 Quit krabador (Max SendQ exceeded) 02.20.56 Join krabador [0] (~krabador@host101-49-dynamic.1-87-r.retail.telecomitalia.it) 02.33.09 Quit kadoban (Ping timeout: 252 seconds) 03.11.34 Quit krabador (Ping timeout: 264 seconds) 03.25.49 Quit Rower (Quit: Hmmm...) 03.39.17 Quit bluebrother (Disconnected by services) 03.39.22 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 03.42.38 Quit fs-bluebot (Ping timeout: 260 seconds) 03.44.00 Join fs-bluebot [0] (~fs-bluebo@f053154009.adsl.alicedsl.de) 04.02.42 Quit liar (Remote host closed the connection) 04.11.42 *** Saving seen data "./dancer.seen" 04.23.41 Quit uberushaximus (Remote host closed the connection) 04.23.50 Join uberushaximus [0] (~uberushax@hacked.thegov.us) 04.25.36 Quit [Saint] (Remote host closed the connection) 04.27.45 Join [Saint] [0] (~quassel@rockbox/user/saint) 04.29.35 Quit uberushaximus (Ping timeout: 264 seconds) 04.29.57 Join uberushaximus [0] (~uberushax@hacked.thegov.us) 04.43.32 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.43.32 Quit pixelma (Disconnected by services) 04.43.32 Quit amiconn (Disconnected by services) 04.43.32 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.43.32 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.43.33 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.46.51 Join AlexP_ [0] (~alex@rockbox/staff/AlexP) 04.47.24 Quit AlexP (Ping timeout: 260 seconds) 04.54.09 Join zamboni [0] (~bottledwa@unaffiliated/zamboni) 05.18.25 Quit shamus (Read error: Connection reset by peer) 05.18.41 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 05.39.55 Quit TheSeven (Disconnected by services) 05.40.04 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.01.57 Join dfkt [0] (dfkt@unaffiliated/dfkt) 06.02.50 Quit dfkt_ (Ping timeout: 260 seconds) 06.10.24 Quit SuperBrainAK (Quit: pbly going to sleep /_\) 06.11.45 *** Saving seen data "./dancer.seen" 06.14.00 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 06.25.23 Join sarg [0] (~sarg@89.169.51.37) 06.54.09 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 06.58.38 Quit froggyman (Ping timeout: 260 seconds) 07.03.30 Join olspookishmagus [0] (~pookie@host-84-205-241-1.cpe.syzefxis.ote.gr) 07.16.21 Quit zamboni () 07.18.46 # [Saint]: how does this look? http://pastebin.com/ZxeCh6mU 07.23.05 Join Dex [0] (~textual@c-76-101-230-123.hsd1.fl.comcast.net) 07.24.59 Quit Dex (Remote host closed the connection) 07.25.36 Join Dex [0] (~textual@c-76-101-230-123.hsd1.fl.comcast.net) 07.38.31 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 07.46.54 Part Dex 08.11.47 *** Saving seen data "./dancer.seen" 08.14.12 Join pretty_function [0] (~iHackiOS@61.12.96.10) 08.15.50 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 08.24.21 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 08.34.27 Join ender` [0] (~ender@foo.eternallybored.org) 08.43.59 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 08.50.07 # Is UCL unpacker in-place? 08.51.06 # I mean can we use ucl packed main binary? This would decrease load time most probably as loading from storage is usually the slowest part of the loading. 08.56.09 # nevermind, the question doesn't make any sense. 08.57.26 # but idea to use ucl packed main binary to speed up booting still holds, just as linux kernel is loaded in compressed form into ram. 09.07.11 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.10.16 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 09.12.49 Join LinusN [0] (~linus@giant.haxx.se) 09.13.43 Join petur [0] (~petur@rockbox/developer/petur) 09.14.43 # wodz: You can setup the linux kernel to decompress directly from flash. 09.18.52 # ukleinek: btw. C-M3 @ 48 should be capable to support mp3, vorbis and loseless formats. 09.19.38 # ukleinek: I know, zImage has 'built-in' decompressor 09.20.55 # for rockbox this is different thing usually, as bootloader loads main binary image to ram from storage and jumps to the entry point. For rombox we use ucl packing already IIRC 09.24.15 Quit bertrik (Read error: Operation timed out) 09.24.43 # wodz: alternatively the bootloader can decompress from storage directly into ram. (Note, I don't know ucl packing, so that might be the same) 09.26.01 # yes, but the downside is that you will need to update ALL bootloaders. I am not going to touch bootloaders when not strictly needed 09.26.42 # anyway it is faster to load blob from storage in one big chunk and decompress in mem 09.30.55 # wodz: i wrote a perl script for unpacking rk30/rk29 loader binaries https://gist.github.com/sarg/5028505 09.32.20 # BTW, scramble function is RC4 algorithm, so I used openssl to descramble files 09.33.27 # sarg: It is documented on our wiki that it is RC4 :-) http://www.rockbox.org/wiki/Rockchip27xx 09.33.51 # sarg: you still need the key 09.33.53 # yes, I but you should mention, that input is split by 512 bytes blocks 09.34.15 # sarg: well I documented this so you know... 09.35.08 # sarg: you want to substitue loader with uboot, right? 09.35.14 # what about ftl then? 09.35.30 # define ftl? 09.35.49 # flash translation layer 09.35.55 # *transition 09.36.12 # i don't know, it is questions I think you can answer ) 09.36.25 # what did you did in rk27 case ? 09.37.16 # i am novice to embedded, and this is my first experience, so I may be doing silly steps 09.37.24 # I am reverse engineering ftl but this is hard task. Currently we don't support internal flash at all. 09.37.45 # rockbox boots and supports uSD only for now. 09.38.19 # my main priority is to boot ubuntu native, without android chroot 09.38.45 # that is irrelevant, you need to boot from somewhere 09.39.15 # yes, i am saying that don't know if u-boot is necessary in my case 09.40.45 # right, if you can force original loader to load arbitrary image you don't 09.41.09 # but still the kernel would need to support ftl to read internal flash 09.41.24 # but i have kernel provided by manufacturer 09.41.47 # they released source codes, so ftl driver should be in there ? 09.41.57 # ok, out of curiosity ftl is in source form or as binary blob? 09.42.05 # dunno 09.42.44 # https://github.com/AndrewDB/rk3066-kernel 09.43.38 Join mortalis [0] (~kvirc@213.33.220.118) 09.44.39 # wodz: in Rockchip27xx wiki page you give detailed boot sequence, how did you obtain that information 09.45.44 # reverse engineering rom loader mostly 09.45.45 # how do i find offsets where loader parts are loaded 09.46.13 # leaked sdk just confirmed my findings 09.46.53 # for example, The bootrom copies this initialization image to the buffer at 0x18200E00 09.47.02 # where did this offset come from? 09.47.49 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 09.48.31 # 0x18200000 is uncached static ram e00 is just arbitrary offset taken by rockchip 09.49.33 # how do i find this offset for rk30 SoC ? 09.50.14 # I am afraid linux sources are the only reference as AFAIK no datasheet leaked 09.50.41 # sarg: the offset is in the ROM loader, too. 09.53.45 # ukleinek: please define what ROM loader is? is it loader put directly into SoC internal memory? 09.54.01 # it is placed in SoC masked rom 09.55.41 # no way to get this data using jtag ? 09.57.26 # It is mem mapped region but it may be shadowed (like in case of rk27xx), don't know how they did it in later versions 09.59.01 Quit kiwicam (Remote host closed the connection) 09.59.10 # and rk2705/6 don't have jtag available 09.59.17 # sarg: for rk2700 there is a way getting the data using wget :-) 10.00.35 # ukleinek: ? 10.01.13 # anyway gtg 10.01.16 Quit wodz (Quit: Leaving) 10.02.49 # wodz: google for "rk27 bootrom.tar.bz2" (without the quotes). 10.02.54 Join kiwicam [0] (~quassel@101.98.163.139) 10.10.39 # ukleinek: alemaxx is one of rockbox members ? 10.10.56 # sarg: I don't think so. 10.11.50 *** Saving seen data "./dancer.seen" 10.28.13 # <[Saint]> wodz: (logs) If Rockbox doesn't, you might want to take a look at eCORE 10.28.29 # <[Saint]> re: UCL compression for payload/binary 10.28.40 # <[Saint]> *emCORE too 10.30.30 # <[Saint]> JdGordon: One problem, you can't use %vs 10.30.45 # <[Saint]> (it is already "variable set") 10.32.45 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.33.07 # <[Saint]> wodz: I left a comment for you just now in the logs 10.33.10 # <[Saint]> re: UCL 10.33.18 # * wodz scrolls back 10.33.55 # <[Saint]> emCORE definitely has a very lightweight UCL implementation, could be a good start. 10.34.24 # I belive we use the same implementation of ucl unpacker 10.35.54 # Alemaxx is not our developer, nor actively follows rockbox rk27xx development. He answers emails though. 10.36.48 # and still this rom had to be dumped in the first place (kudos to Alemaxx!!!) 10.37.02 Quit DexterLB (Read error: Connection reset by peer) 10.42.27 Join DexterLB [0] (~dex@79.100.239.34) 10.46.40 Join AlexP [0] (~alex@rockbox/staff/AlexP) 10.47.18 Quit AlexP_ (Ping timeout: 260 seconds) 10.51.37 # wodz: so, do you know how he obtained bootrom? 10.56.37 # Yes, I know. He crafted custom binary image, forged it in rkw format known to stock loader and booted. The crafted image dumped rom and send it back using UART. 10.57.55 # or he used dfu loader, don't know which way was the first 10.57.56 # awesome :) 11.01.19 # hm, if i have android running on my rk30 device, I may write assembly code to retrieve any memory region? 11.02.24 # the main question is how to access this memory :-) 11.03.09 # on rk27xx you need to flip one register which ruins normal operation, dump the content and then restore special reg value 11.05.33 Quit Staphylo (Ping timeout: 272 seconds) 11.07.42 # * [Saint] wonders if anyone has any interest in the Department of Corrections modified Clip firmware I acquired from an individual recently released from their custody 11.08.24 # malloc some space, switch SoC in some mode, where every interrupts are disabled or so, copy sectors to allocated space, restore everything. repeat 11.08.26 # <[Saint]> Apparently they're doing a bunch of "weird things (TM)", none of which are particularly interesting for Rockbox, but may be interesting for other reasons. 11.08.53 # <[Saint]> (such as disabling the USB settings and requiring the device to sync with a main server every 14 days) 11.09.50 # sarg: this switching SoC thing... I guess you don't have a clue yet how to do it 11.11.28 # [Saint]: why not? 11.11.51 # <[Saint]> JdGordon: it's already used, you should know these things ;) 11.11.58 # <[Saint]> It is "variable set" 11.12.01 # and apart from that 11.12.07 # <[Saint]> (pairs with "variable get") 11.12.37 # <[Saint]> I'm not sure another reason is needed? 11.12.48 # <[Saint]> The tag is in use, you need another :) 11.13.06 # i mean, apart from not using that tag, other opinions 11.13.14 # * [Saint] does apologize for not spotting the double-up earlier 11.14.01 # <[Saint]> Being perfectly honest, I think the syntax is nightmarish...but, I couldn;t come up with anything better. 11.14.19 # i agree 11.14.29 # im very open to something more minimal 11.14.36 # <[Saint]> I'm deeply afraid you'll end up making an awesome system that is damn near impossible to use due to the nightmarish syntax required. 11.14.54 # hehe maybe 11.14.58 # im ok wit that :p 11.15.59 # (not really) 11.20.00 # wodz: the issue I have is that I don't really know what I'm doing :) 11.20.17 # Well, I mean, I won't know what I'm doing again when I get home tonight 11.20.56 # gevaerts: can i interest you in the pastebin i linked hours ago? 11.21.13 # http://pastebin.com/ZxeCh6mU 11.24.01 # gevaerts: What are you going to achieve? debuging with gdb or reflash? 11.24.26 # wodz: reflash is the most important one, but debugging could be useful too 11.24.44 # I built the bdm tools from bdm.sourceforge.org, and I built gdb 11.25.23 # gevaerts: this are not quite compatible with cf5049/50 11.25.35 # Ah, maybe that's my problem then 11.25.52 # gevaerts: I made some hacky patch once upon a time 11.26.03 # The h300 connects fine with bdm-chk, and I can *sometimes* connect to it from within gdb 11.26.42 # gevaerts: for reflashing you need to contact Niels 11.27.01 # I didn't have any luck with the h120, but the connector was a bit loose (and came off later...), so that's not a software issue probably 11.27.22 # LinusN: any documentation on how to actually flash an iriver over bdm? 11.27.36 # I believe there were some trickery involved like shorting some pin to prevent spontaneous reset\ 11.27.45 # ah, right it was Linus 11.28.09 # Ah, right 11.29.54 # JdGordon: I need to play with that a bit to get a good idea 11.30.04 # Not now though. I have work :) 11.30.24 # <[Saint]> gevaerts: It needs to exist in a place other than JdGordon's head first :) 11.30.35 # <[Saint]> ...you don't want to go in there and play, I'm guessing : 11.30.39 # <[Saint]> +P 11.30.50 # Well, I can try to copy parts of his head first :) 11.31.37 # I mean, just reading the description doesn't mean much to me. I need to work out an example, even if there's no code yet to parse it 11.32.00 Quit kiwicam (Remote host closed the connection) 11.32.06 Join TheLemonMan [0] (~LemonBoy@adsl-ull-86-255.45-151.net24.it) 11.32.06 Quit TheLemonMan (Changing host) 11.32.06 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman) 11.32.20 Join kiwicam [0] (~quassel@101.98.163.139) 11.32.54 # gevaerts: there are a few options 11.33.57 # LinusN: btw, do you have bdm server patch somewhere? I think I emailed it to you. Can't find it on my local computer 11.34.58 # 1) write a program that uses the BDM lib to write to the flash using only BDM commands. i did that with the p&E parallel port wiggler, and that works for the usb variant as well, but it is slooooooooooow. 11.38.19 # wodz: sure, i can send it back to you 11.38.35 # LinusN: great! 11.38.39 # gevaerts: did the h120 connector fall off? 11.41.51 # wodz: you mean the m68k-bdm-1.4-pre4.wo patch? 11.42.03 # LinusN: yes 11.44.07 # LinusN: it's not fully off, but yes, it came loose 11.45.10 # damn. i didn't have access to the best equipment. perhaps you could send me the pcb? 11.46.29 # anyway, option 2) is to write a flashing program which you load using gdb, along with a binary blob with the flash data to load into RAM, and then run the program to flash. it takes a little shorter time, but the transfer time of the flash data is still quite painful. 11.47.07 # option 3) is to put the flash image on disk, and let the flashing program load the image from disk and flash it. 11.47.19 # i have done option 1) and 2), but not 3). 11.48.03 # and you need to build the correctly patched tools 11.49.20 # option 4 is to load rockbox image into mem with bdm and use flash plugin from there 11.49.53 # assuming you have plugins on disk 11.52.10 # LinusN: many thanks, got the patch 11.54.02 # LinusN: I'll first see if someone here can do it 11.54.30 # Ah, right. I should be able to prepare the disk with a set of plugins and a working bootloader to flash 11.57.04 # LinusN: Am I correct that there was some pin to short on h300? 11.58.14 # yes, i just added that info to the iriverbdm wiki page 12.02.31 # I think alternatively one may hold 'power on button' during bdm transfer. At least this worked on hd200 which is based on the same reference design 12.04.50 # that works on the h100, but i'm not sure it works as well on the h300 12.05.33 # * gevaerts will find out! 12.09.10 # wodz: http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/ 12.10.20 # guy is just reading /dev/mem to get bootrom 12.10.28 # i'll give it a try 12.11.35 Join copper [0] (~copper@unaffiliated/copper) 12.11.53 *** Saving seen data "./dancer.seen" 12.20.54 # i just added some nice pictures to http://www.rockbox.org/wiki/IriverBDM showing the location of the (missing) resistors 12.22.53 # Ooooh! 12.26.25 Join petur2 [0] (~petur@dD5E0153A.access.telenet.be) 12.26.47 Join robin0800 [0] (~robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 12.27.00 Quit petur (Disconnected by services) 12.27.05 Nick petur2 is now known as petur (~petur@dD5E0153A.access.telenet.be) 12.27.15 Quit petur (Changing host) 12.27.15 Join petur [0] (~petur@rockbox/developer/petur) 12.38.42 Quit sarg (Quit: leaving) 12.41.51 Quit robin0800 (Quit: Leaving) 12.46.30 Join robin0800 [0] (~robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 12.53.06 Join mt [0] (~quassel@196.218.41.112) 12.57.19 Join Braindamaged [0] (~4d66fe0d@www.haxx.se) 12.58.25 # Hey Guys MY Sansa Clip+ is bricked and I dont have the means or skils to perform a recovery, does anyone in the UK want it? I'm willing to post it to anyone Free of charge if it will all go to the cause of makeing RB bigger and better :) 13.03.06 Quit petur (Quit: *plop*) 13.03.14 # <[Saint]> I guess international shipping (with compensation) is out of the question? 13.03.33 # * [Saint] doesn't really need any more half-bricked Sansas, though. 13.03.50 # i probably shouldn't take any more players until i'm done with the previous ones. 13.04.19 # <[Saint]> The Clip+ isn't really needed from a developer standpoint is it? 13.04.28 # <[Saint]> It's basically stable afaik. 13.04.51 # * [Saint] never uses his 13.05.43 # Hey Saint, Ive replaced it with another Clip+ so whoever wants it can have it as long as the postage is not going to kill me ;) 13.11.03 Quit robin0800 (Quit: Leaving) 13.11.19 Join Staphylo [0] (~Staphylo@mareo.fr) 13.19.43 Quit Braindamaged (Quit: CGI:IRC (EOF)) 14.11.07 Quit wodz (Quit: Leaving) 14.11.55 *** Saving seen data "./dancer.seen" 14.19.02 Quit olspookishmagus (Quit: All for nothing) 14.21.41 Quit pretty_function (Quit: SIGABRT) 14.40.16 Quit dfkt (Remote host closed the connection) 14.44.17 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 14.47.35 Quit mrkiko (Quit: leaving) 14.48.18 Quit shamus (Read error: Connection reset by peer) 14.48.36 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 14.51.00 # the battery charge indicator on the Fuze+ is alternating between 99% and 166% 14.51.51 Quit qoeme (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]) 14.53.45 Quit XavierGr (Ping timeout: 245 seconds) 14.56.46 # <[Saint]> Nice one ;) 14.57.25 Quit mt (Ping timeout: 240 seconds) 14.57.35 # <[Saint]> You could likely "fix" that with the skin engine alone. 14.57.54 # <[Saint]> ...but, that != fixing it, merely working around it. 14.59.15 # <[Saint]> %?if(%pv, <=, 99)<100|%pv> 14.59.33 # <[Saint]> copper: ^ 15.00.28 Join amayer_ [0] (~amayer@mail.weberadvertising.com) 15.01.17 # <[Saint]> %?if(%pv, <=, 99)<100%%|%pv%%> 15.01.29 # <[Saint]> oh, no, derp. 15.01.42 # <[Saint]> %?if(%pv, <=, 99)<100|%pv>%% 15.03.02 # Gesundheit 15.05.06 # <[Saint]> double fuck. 15.05.13 # <[Saint]> s/%pv/%bl/ 15.05.21 # * [Saint] needs some sleep, apparently. 15.06.15 # <[Saint]> (all the above snippet is doing is "if the battery level is ever above 99%, always display it as 100%", but, that's just a fix for it anoying you until it /really/ gets fixed) 15.09.04 # isn't the <= wrong there then? 15.09.22 Quit TheLemonMan (Read error: Operation timed out) 15.09.26 # <[Saint]> ...hahahaha, yes. 15.09.33 # * [Saint] is not having a good day. 15.10.14 # <[Saint]> Indeed, s/<=/ err... not ">"? Although I have to admit that I haven't looked at the if tag yet 15.13.54 # <[Saint]> Right. Bedtime. 15.15.52 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.21.51 # damn it 15.22.08 # the cover artwork is 3 x 3 pixels again 15.22.21 Quit pxb (Quit: leaving) 15.23.57 Join pxb [0] (pxb@2001:1b40:5600:e00::5079:3edb) 15.23.57 # <[Saint]> Which theme? 15.24.03 # <[Saint]> Still rayboradio? 15.24.34 # yes 15.24.40 # I had the same problem with the classic port 15.24.57 # I didn't have that problem with a 2012/12 build 15.25.05 # <[Saint]> Are you using embedded, or file-based AA? 15.25.09 # file 15.25.44 # and I can't find a 2012/12 build for the fuze 15.25.46 # fuze+ 15.26.13 # well, it needs to be fixed anyway 15.27.09 # gonna try a 3.12 build 15.27.13 # <[Saint]> The theme isn't doing anything weird (with regards to AA), though, it is quite nastily coded. 15.27.22 # <[Saint]> Also, I can't repro. 15.27.24 # er 15.27.36 # there's no stable build for the fuze+ 15.27.44 # grrrrrr 15.27.44 # <[Saint]> ...and? 15.27.54 # well I can't find a build that would work 15.28.11 # <[Saint]> There's no stable build, unsurprisingly, because it's no stable ;) 15.28.16 # <[Saint]> *not 15.28.21 # yes I realize that 15.28.38 # <[Saint]> ...kinda made the above a bit of a non-statement then? 15.28.58 Quit kevku (Read error: Connection reset by peer) 15.29.39 # what can I do? 15.29.58 # <[Saint]> File a bug report, with repro steps. 15.30.08 # <[Saint]> Like all bugs. 15.30.39 # <[Saint]> But, wait. 15.31.14 # <[Saint]> Before you do that, you're using an absolutely current build - from our build farm, yes? 15.31.42 # yes 15.31.59 # Are the files displayed correctly in our image viewer, so if selected separately? 15.32.00 # 130224 15.32.19 # <[Saint]> Ok, then shoot. File a bug report. And I'll try and reproduce it on real hardware later in the day. 15.32.35 # <[Saint]> The sim is behaving exactly as I would expect it to presently. 15.32.42 # pixelma: yes 15.35.08 # <[Saint]> There's absolutely no reason why this would affect any one target over another, and, I'm not seeing it and the targets I have near me. 15.35.29 # <[Saint]> I'll borrow a Fuze+ from our hackerspace this afternoon. 15.35.44 # <[Saint]> *on the targets I have near me 15.36.06 # https://www.dropbox.com/s/p0gts1ly7cq72oq/IMG_20130225_153440.jpg 15.36.34 # the tiny colored square at the top of the frame, in the middle, is the cover artwork 15.36.37 # 300x300 jpg 15.37.12 # <[Saint]> that seems /slightly/ larger than 3x3 :) 15.37.23 # well I didn't count :P 15.37.49 # <[Saint]> Is this a "sometimes" thing, or, an "always" thing? 15.37.56 # <[Saint]> I noted you said "again". 15.38.05 # always 15.38.24 # I said again because I had the same problem with rayboradio theme for the iPod Classic (iPod Video) 15.40.57 # <[Saint]> The relevant section is correct: 15.40.59 # <[Saint]> %Cl(0,0,120,120,c,c) 15.40.59 # <[Saint]> %Vl(a,60,46,120,120,-) 15.40.59 # <[Saint]> %Cd 15.41.22 # <[Saint]> ...there's nothing wrong there, but, there's some less-than-nice things going on elsewhere in the theme. 15.41.37 # <[Saint]> None of which should have any effect on AA, though. 15.44.03 # <[Saint]> lebellium seems to be pretty awesome at crafting themes that mess shit up, though. 15.44.12 # <[Saint]> and this was derived from one of his works. 15.44.24 # * [Saint] swears that man is cursed 15.45.36 # I'm currently porting my theme to the C200 but I'm sure I don't need my theme to get the USB connection not working :) 15.45.58 # <[Saint]> Hehe :P 15.46.37 # lebellium: USB on c200 should be pretty stable 15.46.50 # So far only the WPS is almost ready but with other theme's SBS, the USB connection doesn't work. 15.47.40 # [Saint]: http://www.rockbox.org/tracker/task/12830 15.48.21 # I guess I have 7 rockboxed players, the USB connection works properly on none... 15.48.56 # * gevaerts of course assumes that c200 == c200v1 15.49.27 # I bought a refurbished C200 last week. It's written c2 on the back cover but it runs a v1 firmware :) 15.49.33 # v2* 15.49.38 # so it's a v1 yes 15.52.11 # [Saint]: the cover art displays fine with the cabbie v2 theme 15.52.14 # USB works with cabbiev2 but with Onyx I get a Data abort everytime. 15.52.45 # If I already won't work with a normal theme like Onyx, it can only fail with my upcoming theme. Sad... 15.55.08 # if it* 15.55.21 # <[Saint]> Use cabbiev2 as a basis for "normal theme". 15.55.39 # <[Saint]> No user theme can really be judged as "normal" without a code review. 15.55.46 # indeed 15.56.36 # I'll let you know when my SBS is ready. I cross my fingers to make my first theme compatible with USB connection :D 15.57.04 # <[Saint]> lebellium: out of interest, how much available buffer does the Fuze+ have? 15.57.13 # <[Saint]> System - Rockbox Info 15.57.17 # <[Saint]> shit. 15.57.24 # I don't have the Fuze+, I used the R0 to make the theme 15.57.25 # <[Saint]> errr, copper, rather. 15.57.26 # <[Saint]> ^ 15.58.11 # <[Saint]> it /could/ be, that there's some strange effect caused by running out of buffer. 15.58.33 # <[Saint]> If that were the case though I would expect audio playback to be seriously hampered. 15.59.07 # [Saint]: 58.9 MB 15.59.26 # I don't really understand this new debug menu "skin engine usage". How am I supposed to know if it reached the limit or not? 16.00.26 # <[Saint]> copper: right, I didn't think that would be the problem, but it was worth checking. 16.00.35 # I see a "total usage" in bytes but I don't see how much is still available 16.00.44 # <[Saint]> The fact you said it also failed on the Classic made it quite highly unlikely. 16.03.00 # <[Saint]> lebellium: available buffer is listed at System - rockbox Info, iiuc. 16.03.25 # <[Saint]> That should always list the free buffer, and the skin engine can steal all remaining buffer if it wants to. 16.03.38 # <[Saint]> ...which obviously would make audio irrelevant. 16.04.08 Quit jhMikeS (Ping timeout: 244 seconds) 16.04.43 # for example on my C200 it says Buffer: 28,5MB and Total Usage: 197596 bytes 16.04.46 # <[Saint]> I think that the skin debug screen should /probably/ list the skin buffer usage as "used/remaining" though, and it's a trivial change. 16.05.09 # does that mean my theme could be 10MB more? 16.05.27 # <[Saint]> Yes. But, it would mean you couldn't play audio. 16.05.42 # <[Saint]> As the audio buffer is "all remaining buffer". 16.05.43 # lebellium: we've moved to dynamically allocating the skin buffer and many other things, these days 16.05.51 # <[Saint]> If you steal it all, audio will suffer badly. 16.05.54 # so lots of thing scan now use as much memory as they like until you run out altogether 16.05.59 # instead of having individual static limits 16.06.53 # ok thx. That means there is no longer a static limit for my theme size 16.06.55 # ? 16.07.14 # <[Saint]> On a flash target, with a low-I/O codec, you could probably get away with a hilariously small audio buffer, but the constant buffering will eat the battery. 16.07.16 # i'm not sure if every single thing is dynamic now 16.07.20 # but mostly, yes 16.07.30 # obviously smaller is still better :) 16.07.41 # since every bit of available ram for audio buffering helps ;) 16.07.45 Quit DonAman (Ping timeout: 244 seconds) 16.07.48 # <[Saint]> You want as much available buffer as possible to remain for audio. 16.08.10 # on my clip zip with my theme loaded: Buffer is only 5,30MB: could that explain all USB connection fails? 16.08.14 # <[Saint]> Otherwise you'll be constantly hitting the disk, which is a "Bad Thing"(TM). 16.08.19 # no. 16.08.22 # <[Saint]> No,.' 16.08.35 # we shouldn't need to allocate any memory for usb 16.08.41 # well, we do but it's static :) 16.08.55 # memory allocation is still not fully dynamic, on purpose 16.09.36 # ok 16.09.41 # We do grab the audio buffer for usb, and it needs to be 64K at least 16.09.54 # oh, hm, ok :) 16.10.04 # but yeah, 5.3mb is plenty for, well, anything really 16.10.34 Join DonAman [0] (~DocHollid@unaffiliated/phifedoc) 16.10.34 # ok... it's a pity, I thoughy I found out an easy reason for USB issues \o/ 16.10.43 # thought* 16.11.04 # <[Saint]> The important part is basically "skin buffer can use as much of the remaining buffer as it wants to, and the audio buffer is what gets left over". 16.11.31 # <[Saint]> Were that the reason for the USB failure, I would've hit that wall and found this bug years ago ;) 16.11.57 *** Saving seen data "./dancer.seen" 16.13.35 # <[Saint]> One of my themes for RaaA is using 50MB in fonts alone. 16.13.55 # <[Saint]> AA GNU Unifont is *massive*. 16.14.21 # No it's not 16.14.40 # <[Saint]> The bitmap version is ~7MB 16.14.49 # Or do you seriously allocate 50MB for it? If so, change that! That's what the font cache is for! 16.15.17 # <[Saint]> AA versions get up to ~30MB for a ~50pt font 16.15.24 Join lorenzo92 [0] (~chatzilla@host224-106-dynamic.249-95-r.retail.telecomitalia.it) 16.15.27 # The *files* 16.16.24 # my Fuze+ measures at 0.9Ω 16.16.40 # <[Saint]> I think the default is 200 glyphs, which still ends up pretty big, but nowhere near loading the entire font, correct. 16.25.42 Join robin0800 [0] (~robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 16.26.10 Join mt [0] (~quassel@196.218.41.112) 16.29.20 Quit robin0800 (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 16.29.44 Join robin0800 [0] (~robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 16.36.23 Part eckoit 16.41.19 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 16.51.10 # <[7]> [Saint], wodz (for the logs): emCORE's UCL unpacker is based on Rockbox's with some minor improvements 16.56.01 # <[Saint]> [7]: right, I didn't think it was one and the same exactly. 16.56.08 # <[Saint]> but I wasn't totally sure. 16.56.26 # <[Saint]> iirc, you trimmed it down to a much smaller footprint did you not? 16.57.17 Quit y4n (Read error: Connection reset by peer) 16.57.47 # <[7]> no, rockbox's one is already very optimized for size 16.58.13 # <[7]> I mostly swapped around registers and changed the ARM/Thumb interwork a bit to make it more convenient for my purposes 16.58.32 # <[7]> possibly squeezed out a few more bytes, but rockbox's one is already only a few hundred bytes 16.58.59 # <[7]> but yeah, that noteboot hack was awesome :P 16.59.14 # * [Saint] nods 16.59.15 Quit shamus (Read error: Connection reset by peer) 16.59.27 # <[Saint]> I still find it the most convenient form in installation. 16.59.30 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 16.59.38 # <[Saint]> s/in/of/ 16.59.44 # <[7]> yeah... if only it would work on the classic as well 17.00.07 # <[Saint]> Did they patch the notes exploit out, or, ? 17.00.34 # <[7]> the notes exploit is only present in very ancient firmwares on first generation classics 17.04.43 Join krabador [0] (~krabador@87.18.176.153) 17.05.48 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.08.08 Join froggyman [0] (~me@50.105.148.129) 17.08.08 Quit froggyman (Changing host) 17.08.08 Join froggyman [0] (~me@unaffiliated/froggyman) 17.21.38 # <[Saint]> Huh, awesome. 17.22.04 # <[Saint]> the EQ_*_FAST_STEP define is awesome. 17.22.49 # <[Saint]> I wasn't aware that the min amount and the repeat value were different. 17.25.44 Join eckoit [0] (~ryan@50.65.10.24) 17.25.48 # * [Saint] really wants someone to pull the trigger on g#401 17.26.10 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 17.26.27 # <[Saint]> errrr, #g401? 17.26.29 # 3Gerrit review #401 at http://gerrit.rockbox.org/r/401 : EQ Presets by Hayden Pearce (changes/01/401/3) 17.26.36 # <[Saint]> huzzah. 17.27.10 # <[Saint]> and also #g393 17.27.13 # 3Gerrit review #393 at http://gerrit.rockbox.org/r/393 : Implement "reverse stereo" channel configuration to reverse left and right audio... by Bertrik Sikken (changes/93/393/2) 17.28.25 Quit lebellium (Ping timeout: 252 seconds) 17.28.30 Quit lorenzo92 (Ping timeout: 255 seconds) 17.28.35 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 17.29.14 # <[Saint]> Has anyone else noticed that Rockbox USB seems to be stalling after disconnect/unplug? 17.29.41 # <[Saint]> (remains on the USB screen with a non-responsive UI, and constant disk access) 17.31.33 # <[Saint]> Oh, yay...the classic isn't mounting at all anymore. 17.31.39 # <[Saint]> :-S 17.33.04 Part crwl ("WeeChat 0.3.9") 17.33.57 # <[Saint]> The fallback image mounts, HEAD doesn't. 17.42.02 # <[Saint]> Hummm... 17.42.18 # <[Saint]> This seems to be an Ubuntu thing, not a Rockbox thing. 17.44.37 Join newbie|4 [0] (~robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 17.44.46 Quit newbie|4 (Client Quit) 17.45.31 Join AlexP_ [0] (~alex@rockbox/staff/AlexP) 17.46.02 Quit AlexP (Ping timeout: 252 seconds) 17.46.51 Quit mortalis (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/) 17.49.26 Join hashtagash [0] (~6d98ae5b@www.haxx.se) 17.49.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.52.39 Part eckoit 17.57.24 # can anyone tell me how the c8k files for the Chip8 emulator work? 17.58.18 # I've read the wiki and I don't get it 17.59.35 Quit pxb (Ping timeout: 245 seconds) 17.59.51 # you put them on the player then open them like you would a music file in the filebrowser 18.00.41 # I did that but I want to remap the keys and I don't understand the .c8k files 18.02.02 # ah the kaymapping thing, the manual has a description 18.02.07 # key* 18.03.01 # I read the manual but I don't get it 18.03.40 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) 18.03.48 # IIUC the position of the character corresponds to the key being remapped to the value of the character 18.04.43 # so the default mapping is 0123456789abcdef and the example remapping 0122458469ABCDEF 18.05.02 # oh, I get it now! thanks 18.05.10 # so the 3 key is remapped to 2, 6 to 8m 7 to 4, and 8 to 6 18.06.24 # * [Saint] is a bit late 18.06.32 # <[Saint]> But, yes, yes...what he said. 18.07.16 # <[Saint]> the easiest example is: AAAAAAAAAAAAAAA maps every key to A, etc. 18.07.43 # <[Saint]> (which would be highly silly, but, it's just an example) 18.09.40 # <[Saint]> the manual makes it look weird, as the table looks like there's two rows of values - "Chip8" and "Key" (which looks blank). 18.09.47 # <[Saint]> But, it's just odd formatting. 18.09.59 # hmm, I think I might know why I was so confused: the up key on my iPod nano 1g is quitting the emulator 18.10.14 # instead of being the third key in the c8k file 18.10.36 Join pretty_function [0] (~sigBART@123.252.212.242) 18.10.52 # <[Saint]> That's odd behaviour, yes, but it doesn't entirely surprise me. 18.11.17 # <[Saint]> The iPods especially have very non-sane (and sometimes totally arbitrary seeming) maps to exit plugins. 18.11.28 # agreed 18.11.45 # they should all be the same imho 18.11.46 # <[Saint]> IMO, it should be Menu+Select to exit every plugin where |<< isn't in use. 18.11.59 # <[Saint]> errr, *is* in use, rather. 18.12.00 *** Saving seen data "./dancer.seen" 18.12.00 # menu+select works on most 18.12.10 # <[Saint]> But, that's one of those "round-to-it" things. 18.12.26 # shame, I wanted to play blinky! 18.12.43 # <[Saint]> And, being perfectly honest, not a lot of developers care much about the plugins other than "builds, has bitmaps, and has a keymap" 18.12.55 # <[Saint]> "has a sane keymap" is often overlooked completely. 18.13.14 # if I knew anything about C I would fix it 18.14.00 # <[Saint]> It's a matter of converting everything over to pluginlib, which is actually fairly trivial, but boring. 18.14.39 # so nobody wants to do it :[ 18.15.06 # so pluginlib uses menu+sel for everything? 18.15.26 # <[Saint]> pluginlib provides a global set of actions for plugins so every plugin doesn't need to re-invent the wheel. But, conversion is a slow process because a lot of these plugins don't get used by developers I think. 18.16.09 # <[Saint]> Fairly recently someone made a pretty big stab at the plugins. But, it's not complete apparently. 18.16.37 # it was agreed on to not port every plugin to that, only ones that need a certain set of actions 18.16.49 # <[Saint]> Aha, my mistake. 18.17.02 # <[Saint]> I was under the impression that every plugin that could, should. 18.17.05 # consistency across plugins for one device is another matter, not just actions 18.17.29 # well every plugin that could isn't every plugin 18.17.46 # I might put it on flyspray as low priority, as it does make chip8 pretty much unusable 18.18.02 # <[Saint]> Yeah, go for it. It is certainly a bug. 18.18.26 # I need a jabber id to register on flyspray? 18.18.31 # <[Saint]> No. 18.19.09 # oh, its optional. 18.19.12 # <[Saint]> Only the fields with the red boxes are required. 18.19.21 # <[Saint]> real name, username, and email address iirc. 18.19.25 Quit Torne (Read error: Operation timed out) 18.19.41 Join Torne [0] (~torne@rockbox/developer/Torne) 18.22.51 # err, I can't change the priority of the task 18.23.08 # <[Saint]> No, only a developer can do so. 18.23.22 # <[Saint]> This prevents people from adding everything as high priority :) 18.23.31 # ok, to stop people putting things at high priority because it affects THEM :P 18.23.42 # <[Saint]> Yeppers. :) 18.37.44 # [Saint]: do we need bass/treble booster/reducer presets? we have distinct settings for that 18.38.58 # not really imho 18.40.22 # <[Saint]> Technically, no, but the EQ has a MUCH broader range of adjustment and finer control. 18.40.44 Quit pretty_function (Remote host closed the connection) 18.40.55 # <[Saint]> bass/treble is +/-6dB, EQ is +/-24 iirc. 18.41.08 # <[Saint]> (and the EQ has .5db steps) 18.41.15 # yay 18.41.20 # I modified the Acuity theme 18.41.27 # to fit my tastes 18.41.41 # it's all pretty now 18.41.55 Quit krabador (Ping timeout: 240 seconds) 18.42.14 # <[Saint]> I also have no idea (and neither does the user, really) what frequencies "bass" and "treble" actually adjusts. 18.42.16 # lol, I don't have acuity 18.42.57 # darn it, my theme went all messed up D: 18.43.13 # <[Saint]> The presets definitely sound a lot nicer (to me, at least) than simply raising/lowering bass/treble values. 18.43.29 # I disagree 18.44.00 # and IMO we shouldn't clutter the preset listing with such presets if they are easily available through other means 18.44.29 # <[Saint]> But, as I said, the level of control is completely different. 18.44.35 # if you can split the patch we can discuss these separately and merge the other improved presets 18.44.48 # <[Saint]> bass/treble is "the poor mans EQ" for people that seem daunted by a full GEQ IMO. 18.45.46 # <[Saint]> kugel: you know we *already* have bass/treble presets in HEAD, yeah? 18.45.52 # <[Saint]> ...they got in fine. 18.45.57 # <[Saint]> these are just a lot nicer. 18.46.07 # <[Saint]> a LOT nicer. 18.46.24 # IMO we don't need even more of them 18.46.37 # <[Saint]> That's why I depricated the old ones. 18.47.16 # <[Saint]> There's not more, or less of them. There's the same amoutn (wrt: bass/treble), just...better. 18.48.13 # <[Saint]> Actually, if that patch was committed, there would be less of them. 18.48.18 # <[Saint]> My mistake. 18.48.29 # I must be looking wrong then 18.48.52 # I see -1/+2 for bass and +2 for treble 18.48.57 # <[Saint]> There's currently Bass, Treble, Full Bass, Full Treble, and Full Bass and Treble 18.49.10 # <[Saint]> The newer patch doesn't have the "full bass and treble" one. 18.49.18 # oh yea, I see that now 18.49.36 # why did you rename? 18.50.34 Quit mt (Ping timeout: 252 seconds) 18.51.00 # <[Saint]> I just used the names from the presets they were adapted from. I thought the naming was a little clearer. 18.51.23 # <[Saint]> This set was adapted from Apple's presets, the ones in HEAD came from VLC. 18.52.02 # <[Saint]> I just used the names I thought users would already be used to. But where the names matched exactly to what was in the source already, I kept the naming. 18.52.10 Quit DexterLB (Quit: So long and thanks for all the fish) 18.53.20 Join DexterLB [0] (~dex@79.100.239.34) 18.53.30 # <[Saint]> I think the naming in that patch makes it clearer what each preset actually does, but, the naming isn't anything I'm prepared to fight over :) 18.55.06 # <[Saint]> I think, even with the added presets, due to the format change, there's actually a slight binsize decrease as well. 18.55.12 # <[Saint]> ...but nothing to write home about. 18.56.09 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.57.29 Join krabador [0] (~krabador@87.18.176.153) 18.58.47 Join pxb|honeycrisp [0] (pxb@honeycrisp.2yp.org) 18.59.42 Quit pxb|honeycrisp (Client Quit) 18.59.50 # * pixelma still wonders whether she's the only 19.00.06 # <[Saint]> Yes. 19.00.28 Quit hashtagash (Quit: CGI:IRC (Ping timeout)) 19.00.44 # only one where the Rockbox line in the notification bar is black on white on ICS RaaA 19.02.05 # unlike the other apps' notifications 19.02.15 Quit shamus (Read error: Connection reset by peer) 19.02.32 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 19.05.14 Join hype [0] (~hype@82.199.174.16) 19.06.58 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.07.12 Quit desowin_ (Read error: Operation timed out) 19.08.33 Join lorenzo92 [0] (~chatzilla@host188-111-dynamic.10-79-r.retail.telecomitalia.it) 19.08.54 Quit DexterLB (Ping timeout: 252 seconds) 19.09.17 Quit n1s (Read error: Connection timed out) 19.09.45 Quit robin0800 (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 19.14.45 Quit lorenzo92 (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130218103317]) 19.22.13 Join desowin [0] (~desowin@pandora.barbara.ds.polsl.pl) 19.23.41 Join DexterLB [0] (~dex@79.100.239.34) 19.24.55 Quit DexterLB (Read error: Connection reset by peer) 19.26.01 Join pxb|honeycrisp [0] (pxb@honeycrisp.2yp.org) 19.30.11 Join DexterLB [0] (~dex@79.100.239.34) 19.31.08 # I also have another problem with RaaA on my phone(s) - if music is playing and I want to switch to Rockbox I'm greeted with a black screen and the only way out is stopping the app through the app manager. Only recently I discovered that the screen is not completely black but shows a very few pixel rows of the status bar 19.35.34 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.37.40 Quit lebellium (Ping timeout: 252 seconds) 19.37.47 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.45.59 Quit krabador (Remote host closed the connection) 19.49.26 Quit thegeek (Read error: Connection reset by peer) 19.49.28 Join thegeek_ [0] (~thegeek@222.37.34.95.customer.cdi.no) 19.53.08 Join threethirty [0] (~three@w104.sem.earlham.edu) 19.56.41 # hello all I couldn't find a solution to my particular problem. I accadentally turned off the backlight on my sansa fuse when digging through the menus. Is there an easy way to reset that? 19.57.34 # <[Saint]> Mount the device and edit the config.cfg manually. 19.58.00 # <[Saint]> Or, you can hose the config by booting with hold enabled. 19.58.16 # <[Saint]> boot; immediately enable hold. 19.58.42 # <[Saint]> The manual editing method is a lot better, though. 19.58.52 # [Saint]: are you sure that this is the reset combo on the Fuze? 19.58.56 # <[Saint]> ...unless you're not worried about losing all your settings. 19.59.28 # <[Saint]> pixelma: I was under the understanding that was the reset combo for anything with a physical hold button? 20.00.08 # no idea actually 20.00.53 # <[Saint]> Anyway, I wouldn't recommend that method. Just edit the config.cfg and remove the backlight line. 20.01.16 # booya! editing th econfig totally worked, thanks a million! 20.01.24 # <[Saint]> Not a problem. 20.01.40 # <[Saint]> Perhaps I should file that as a bug. 20.01.57 # <[Saint]> You /probably/ shouldn;t be able to turn the LCD off completely ;) 20.02.15 # <[Saint]> (or, render it useless, as the case may be) 20.03.00 # [Saint]: is there *one* setting that makes the LCD totally invisible? 20.03.24 # As far as I can see, it's just some combinations of settings that are annoying 20.03.43 # Also, do you really want to force blind people to waste battery? 20.03.56 # <[Saint]> I'd check, but, my Fuze has no power currently. 20.04.06 # <[Saint]> ...apparently the battery is dead. Like, dead dead. 20.05.07 # <[Saint]> I was just thinking along the lines of dis-allowing a zero (or equal to) value for contrast/brightness. 20.05.54 # <[Saint]> Wastage would be minimal with the lowest possible visible setting. 20.07.16 # <[Saint]> errr...backlight. 20.07.17 # You'd still be annoying some people to add a safeguard against something that's easy to fix 20.07.23 # it also depends on the type of display but that could be taken care of 20.08.29 # <[Saint]> gevaerts: true, it is easy to fix (as long as you have ready access to a host device or the manual - for the reset combo), but, it'd be better if it just didn't happen. 20.09.09 # <[Saint]> In most cases, I'd find it unlikely that a person would want to turn off the backlight completely on a display that renders said display entirely useless after doing so. 20.09.17 # <[Saint]> with the exception of the blind. 20.10.09 # So what exactly are you proposing? 20.10.39 # Remember there's Backlight, Backlight on Hold, and Backlight (While Plugged In) 20.12.02 *** Saving seen data "./dancer.seen" 20.12.47 Join mt [0] (~quassel@196.218.41.112) 20.23.16 Join zamboni [0] (~bottledwa@unaffiliated/zamboni) 20.30.24 # pixelma: I know about the blank screen problem, but I don't know hte cause and i don't know how to reproduce 20.32.49 # <[Saint]> Hum...on FuzeV1 - the backlight setting for "off" seems to be completely ignored. 20.33.26 # * [Saint] also wonders about the inconsistency of some settings. 20.34.11 # <[Saint]> For example: some settings do nothing until they're applied, and others will apply temporarily to display their action if applied. 20.36.04 # <[Saint]> threethirty: what model Fuze is this? 20.36.16 # <[Saint]> V1/2/+? 20.37.23 # <[Saint]> I only have my FuzeV1 to play with presently, but, as far as I can see the "off" backlight setting is completely ignored. 20.37.40 # <[Saint]> But it functions just fine for backlight on hold and backlight while plugged. 20.37.49 # + 20.38.57 # * [Saint] can't tell if the "bug" (read bug as - non-obvious behaviour) lies with the V1 or the + 20.40.35 # I am not sure that it is a bug. the problem was totally pebcak I just wasnt paying enough attention 20.41.38 # <[Saint]> I don't think it's particularly obvious that some displays will be rendered completely useless with the backlight off. 20.42.10 # <[Saint]> If you're aware of the screen type, and know about hardware to some extent, it is. But, for most people I'd bet it comes as a surprise. 20.42.41 # fair enough, I just didn't want to create work for someone just because i was dumb :) 20.43.35 Join ml| [0] (~ml@unaffiliated/ml/x-3958674) 20.43.42 # <[Saint]> I don't think you're dumb. It's not immediately obvious. A large amount of displays will stay usable with the backlight off. 21.20.22 Quit mt (Ping timeout: 276 seconds) 21.21.20 Join n1s [0] (~n1s@rockbox/developer/n1s) 21.22.58 Quit akaWolf (Ping timeout: 276 seconds) 21.33.23 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.34.40 Quit lebellium (Ping timeout: 276 seconds) 21.34.50 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.38.59 Quit ml| () 21.39.16 Join ml| [0] (~ml@unaffiliated/ml/x-3958674) 21.40.14 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.41.08 # [Saint]: my backdrop: http://outpost.fr/stuff/stripes.png 21.41.46 # (wps) 21.43.07 Quit lebellium (Ping timeout: 276 seconds) 21.43.09 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.46.30 # kugel: ok, at least that one is know. I'll try to keep an eye on it, unfortunately I haven't found a pattern of when it'll occur and when it won't myself 21.46.37 # known too 21.55.19 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.57.49 Quit lebellium (Ping timeout: 256 seconds) 21.59.38 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 22.00.58 Part LinusN 22.01.22 Quit dfkt (Ping timeout: 264 seconds) 22.01.32 Quit melmothX (Quit: bau) 22.02.21 Quit lebellium_ (Ping timeout: 256 seconds) 22.03.10 # the music note icon is probably copyrighted though (probably by Apple) 22.03.48 # <[Saint]> There's absolutely nothing wrong with that (as far as I could care), so long as it never hits the theme site. 22.04.01 # <[Saint]> re-create it by hand, and, it's a different story. 22.04.10 # yeah 22.04.22 # <[Saint]> (that's how I managed to get my Apple OF clones up there - though, that's a slightly contentious issue) 22.04.39 # <[Saint]> And, I should /probably/ take them down. 22.04.59 # there's a noticeable hiss with the Fuze+ with my IEMs, when not playing music 22.06.44 # it measures pretty well though 22.08.22 # the fact that the screen is in portrait mode is very useful 22.09.00 # it shows like 20 lines at once 22.09.10 # with Helvetica 15pt 22.09.47 # and I like that Rockbox mapped the bottom left and right corners to page up / page down 22.10.37 # <[Saint]> iiuc, the entire pad should be mapped out as the grid-mode touch-pad. 22.10.53 # <[Saint]> a 3x3 grid of assorted functions that differs per-screen. 22.11.33 # <[Saint]> I _think_ it's supposed to be that way, or was, or will be...possibly. 22.12.02 # well there's top bottom left right, and top left / top right / bottom left / bottom right 22.12.05 *** Saving seen data "./dancer.seen" 22.12.07 # 3x3 indeed 22.13.24 # <[Saint]> Yeah, you may or may not be aware, but that is a mode that touchscreen devices can all use. 22.13.32 # <[Saint]> (but they default to absolute point) 22.13.48 # <[Saint]> The pad is basically treated as a touchscreen. 22.14.07 # without gestures, there isn't much of a point to it though 22.14.23 # <[Saint]> Ehhhhhh...yes and no. 22.14.44 # <[Saint]> It is activated by default on touchscreen devices when no touchscreen tags are present in the theme. 22.14.45 Join dfkt [0] (dfkt@unaffiliated/dfkt) 22.15.24 # <[Saint]> On this particular touchpad, it's a little bit surplus to requirement, though, as you've got a set of physical nav buttons as well. 22.15.34 # <[Saint]> s/touchpad/device/ 22.18.39 # <[Saint]> Very simple gestures (think of the Android pattern-based lock screen) would be very trivial to implement. 22.18.52 # <[Saint]> *actual* gesture recognition, notsomuch. 22.20.25 # <[Saint]> If you had it detecting something along the lines of: start at in 3x3 grid and traverse throush at least two other grid spaces without the digit leaving the screen - it would be pretty trivial. 22.21.01 # <[Saint]> If you wanted it to try and match gestures that can start and end at arbitrary points, things get a lot more complex. 22.21.50 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 22.22.13 # no I was only thinking about up-down left-right swiping gestures, along the printed cross 22.22.19 Join SuperBrainAK [0] (~Andy@71-36-160-229.phnx.qwest.net) 22.22.36 # <[Saint]> but, you could easily do things like: start at 0,0; move to 1x1, then move to 2x2 (a left-to-right and top-to-bottom diagonal across the entire pad) etc. 22.23.40 # <[Saint]> or, 0x0; 0x1; 0x2...etc. 22.24.40 # all in all I find the Fuze+ much more likable (IMHO) than the Clip+ 22.24.49 # the Clip+ is just too damn small 22.24.52 # and, not artwork 22.25.05 # <[Saint]> It pretty much just needs a known start, a known end, and to traverse through N known points in between doing so. 22.25.25 # and at €40 for 16 GB, it's a steal 22.25.28 # <[Saint]> (without the digit leaving the pad until the end point) 22.26.05 # <[Saint]> With a 3x3 grid, though would be trivial, but the idea is that touchscreens should be able to share these gestures - so, it's not really an option. 22.26.33 # <[Saint]> actual gesture recognition is *hard* stuff. 22.27.10 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 22.27.39 # <[Saint]> My favorite Rockboxed device is quite probably a one-of-a-kind. 22.28.44 # which is? 22.29.03 # <[Saint]> An iPod Color/Photo, with a 64GB compact flash card, a microUSB port for charging and accessing the compact flash, and bluetooth audio. 22.29.39 # bluetooth audio with rockbox?! 22.29.53 # <[Saint]> Not native, but, yes. 22.30.11 # <[Saint]> It's just a bluetooth dongle spliced into the headphone jack. 22.30.14 # oh you mean it doesn't actually exist :) 22.30.20 # oh, it does? 22.30.22 # <[Saint]> No, it exists. 22.30.41 # <[Saint]> She's ma baby. 22.30.50 # for bluetooth audio I'd use LossyFLAC, but you'd need quite a bit more space 22.31.53 # <[Saint]> lebellium: yeah, people always do that: "Wow, BlueTooth audio in Rockbox...wooo!", until they're told it's a hardware hack, not a software one. :) 22.32.26 # <[Saint]> If has enough room in the case, it's a *really* easy modification to make. 22.32.27 # bluetooth should be a system-wide thing, like, on smartphones 22.32.40 # no reason every player should have to implement it 22.32.47 # The YP-R1 Lorenzo is currently working on has a bluetooth chip, I would love to see a bluetooth menu in RB :D 22.33.25 # <[Saint]> The other thing people are amazed by is the microUSB port, but, it's pretty simple when you look at how I did it. 22.33.45 # [Saint]: you hacked something into the 30 pin dock? 22.34.23 # <[Saint]> It's simply a ZIF->CF adapter, that happened to have a microUSB port - which I desoldered from the board and mounted to the case backing. Then I spliced in the power between it and the dock connector. 22.34.30 # do you have some pics? 22.35.22 # <[Saint]> Not at present. I've been meaning to showcase the geeky awesomeness of it on G+ for a while 22.36.20 Quit Viperfang (Ping timeout: 246 seconds) 22.36.30 # <[Saint]> I'm not sure why, but, I can't access the CF via the microUSB if the device is powered on. 22.36.44 # <[Saint]> There's likely a very good explanation for this, but...meh. 22.37.08 # what's this weirdness: the Volume settings menu displays values with 5 dB gaps, but in the WPS I can adjust volume by 1dB? 22.37.26 # <[Saint]> I suspect it has something to do with Rockbox and the host trying to access the storage at the same time. 22.37.27 Join Viperfang [0] (~Viperfang@x.viperfang.net) 22.37.34 # and there's no 0dB value in the menu, just -4 and +1 22.37.47 # <[Saint]> That's...strange. 22.39.33 # <[Saint]> It really is a miracle that the port is as usable as it is. 22.39.52 # <[Saint]> pamaury is a ledgend for the work he has done here, in the time he has done it. 22.40.02 # <[Saint]> *legend 22.40.06 # was it harder than with other ports for some reason? 22.40.32 # <[Saint]> Not particularly, no, it's the time span that makes it so dramatic. 22.40.59 # I'm always in awe that you guys manage to reverse engineer those things like that 22.41.18 # <[Saint]> It's a gift. 22.41.25 # <[Saint]> A gift I certainly don't have ;) 22.41.36 # <[Saint]> And, I too, am in awe of those who do. 22.42.09 # also 22.42.34 # so many companies both shitty firmwares on the cheap, why don't they just license Rockbox, with maybe a custom theme? 22.42.39 # botch* 22.43.25 # actually I'm thinking of those chinese "audiophile" manufacturers 22.43.31 # (ew) 22.44.12 # <[Saint]> Audiophiles are manufactured in China!?! 22.44.15 # <[Saint]> I knew it! :P 22.44.43 # eh 22.44.51 # I don't know where THOSE come from 22.45.05 # but they replicate at an alarming rate 22.45.36 # * [Saint] wishes to add that one of the particularly great things about pamaury's efforts is how humble he is about it 23.02.41 Quit ender` (Quit: You can never be too careful with the truly righteous—their faith allows them to justify all kinds of underhanded behaviour. -- Simon R. Green: Just Another Judgement Day) 23.05.09 Quit hype (Quit: ["Textual IRC Client: www.textualapp.com"]) 23.09.48 Quit amayer_ (Ping timeout: 252 seconds) 23.13.19 Quit kevku (Ping timeout: 245 seconds) 23.19.48 Quit liar (Ping timeout: 260 seconds) 23.20.51 Quit esperegu (Ping timeout: 255 seconds) 23.24.20 Quit threethirty (Quit: Lost terminal) 23.29.21 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 23.51.11 Quit bertrik (Remote host closed the connection)