--- Log for 06.10.114 Server: rajaniemi.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 14 days and 0 hours ago 00.00.18 # <[Franklin]> oh yeah, we're in the 1000s of gerrit tasks! :) 00.00.18 # i'm not really able to review that 00.00.45 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 00.01.16 # * [Franklin] waits for the XRick author to push his code to gerrit 00.01.29 # <[Franklin]> I mean seriously, how hard is it? 00.02.08 Quit ender` (Quit: You must know by now we Brits are going metric inch by inch! -- Greg Chapman) 00.06.54 Quit xorly (Ping timeout: 250 seconds) 00.07.42 Quit shamus (Ping timeout: 260 seconds) 00.08.43 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 00.24.08 Quit shamus (Ping timeout: 272 seconds) 00.24.18 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 00.26.37 # <[Saint]> [Franklin]: have you considered the author might not care to do so, or that the licence or authorship may be ambiguous or incompatible? 00.38.30 # <[Franklin]> to me, it seems like he wants to 00.39.03 # <[Saint]> Based on what? 00.39.11 # <[Saint]> No one is stopping him, and he surely knows it exists. 00.39.49 # <[Franklin]> "Sounds good. Just to be sure, should I do one big commit with plain files with no history? Should I go via the subtree merge route? " 00.39.58 # <[Franklin]> in response to "you should commit it to gerrit" 00.42.17 Quit saratoga (Ping timeout: 246 seconds) 00.43.13 # <[Franklin]> to me, it seems like he wants to push it to gerrit ;) 00.43.32 # <[Franklin]> and like pacbox, the proprietary data can be hosted elsewhere 00.43.49 # <[Saint]> He can't. 00.43.59 # <[Saint]> So, I'd stop worrying about it. 00.44.04 # <[Saint]> It isn't getting merged. 00.44.16 # <[Franklin]> Why can't he? 00.44.19 # <[Franklin]> He doesn't know how? 00.44.25 # <[Saint]> ** LICENSE AGREEMENT & LEGAL BABLE 00.44.25 # <[Saint]> I have written the xrick code. However, graphics and maps and sounds 00.44.25 # <[Saint]> are by the authors of the original Rick Dangerous game, and "Rick 00.44.25 DBUG Enqueued KICK [Saint] 00.44.25 # <[Saint]> Dangerous" remains a trademark of its owner(s) -- maybe Core Design 00.44.25 # <[Saint]> (who wrote the game) or FireBird (who published it). As of today, I 00.44.27 # <[Saint]> have not been successful at contacting Core Design. 00.44.29 # <[Saint]> This makes it a bit difficult to formally release the whole code, 00.44.32 # <[Saint]> including data for graphics and maps and sounds, under the terms of 00.44.34 # <[Saint]> licences such as the GNU General Public Licence. So the code is 00.44.37 # <[Saint]> released "in the spirit" of the GNU GPL. Whatever that means. 00.44.38 # <[Saint]> This program is distributed in the hope that it will be useful, but 00.44.40 # <[Saint]> WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 00.44.42 # <[Saint]> or FITNESS FOR A PARTICULAR PURPOSE. 00.44.48 # <[Franklin]> FLOOD!!! 00.44.49 # <[Saint]> As I thought, ambiguous license. 00.45.02 # <[Saint]> Soooo, yeah. Not happening. 00.45.09 # <[Franklin]> aww 00.45.24 # <[Franklin]> it had tons of potential 00.45.41 # <[Saint]> It still does, just, not in the official tree. 00.46.02 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 00.46.02 # * [Franklin] can't imagine a plugin being distributed separately 00.46.16 # <[Franklin]> except wikipedia 00.46.23 # <[Franklin]> and all the other stuff on FS 00.46.44 # <[Saint]> I /guess/ it could be managed in a similar fashion to DooM, where we could point to a blob we don't distribute. 00.46.49 # <[Saint]> But, that's a lot of work. 00.46.51 # <[Franklin]> exactly 00.47.28 # <[Saint]> Though the DooM thing is for binsize, not licensing, IIUC. 00.47.28 # <[Franklin]> wait... what? 00.47.35 # <[Saint]> But, the same concept could be used. 00.47.47 # <[Franklin]> so distribute a binary blob of EXECUTABLE code? 00.47.51 # <[Franklin]> or just of data? 00.48.10 # Doom is a bad example 00.48.23 # Pacbox is more similar 00.48.25 # <[Franklin]> yeah 00.48.33 # <[Saint]> I was thinking more along the lines of resources, as it only seems to be the graphics and sound that are in contention. 00.48.50 # <[Franklin]> [Saint]: the data IS distributed separately from the code tree 00.48.54 # <[Saint]> also, yes. Pacbox is a much better example, thanks. 00.49.00 # * [Franklin] said it first ;) 00.49.26 # Well, a lot depends on whether these data can be legally downloaded 00.49.40 # <[Saint]> Right. 00.49.49 # <[Franklin]> isn't it technically abandonware? 00.49.58 # <[Saint]> In that case, I guess that could be handled a similar way to pacbox as well. 00.50.11 # <[Saint]> Just list the hashes of said files and leave it up to the installee. 00.50.29 # <[Franklin]> yep 00.50.45 # <[Franklin]> or don't have the hashes at all, and let people mod it easier 00.50.52 # [Franklin]: and what's that, *technically*? 00.51.03 # <[Franklin]> an emulator 00.51.11 # <[Franklin]> :P 00.51.20 # I mean "abandonware" 00.51.22 # <[Saint]> He meant regarding abandonware. 00.51.43 # <[Saint]> It being abondoned doesn't mean its magically up for grabs and licensing doesn't matter anymore. 00.52.21 Quit shamus (Ping timeout: 240 seconds) 00.55.34 Quit charlie (Ping timeout: 272 seconds) 00.57.11 # "Abandonware" usually means "I suspect nobody cares enough about this to actually sue me, so it's in the public domain as far as I'm concerned" 00.58.25 # <[Franklin]> [Saint]: just like pacbox, we distribute the emulator and leave the actual data out 00.58.39 # <[Franklin]> right? 00.59.35 # <[Franklin]> the actual source code is GPL 00.59.42 # <[Franklin]> not the data 00.59.43 # If the actual data are redistributable or have a stable official download location, we can do a bit better 01.00.21 # <[Franklin]> github isn't stable? 01.00.50 # It might be 01.01.14 # <[Franklin]> just let it be hosted on there until it gets a DMCA C+D letter :) 01.01.48 # <[Franklin]> (the latter it being github) 01.01.57 # But if the blob is "all rights reserved, we'll hunt you down with a horse whip if you copy it", linking to it might not be acceptable 01.02.07 Join charlie [0] (~c@unaffiliated/charlie) 01.02.24 # <[Franklin]> but we're not LINKING to it, right? 01.02.27 # <[Franklin]> the blob only has data 01.02.31 # <[Franklin]> not code 01.02.47 # <[Franklin]> as in a text editor would view the data, the game is just viewing the assets 01.03.01 # See pacbox 01.03.07 # <[Franklin]> exactly 01.03.22 # <[Franklin]> the emulator "views" the code 01.03.39 # <[Franklin]> nothing illegal about z80 emulator, right? :) 01.03.51 # Yes, which is *entirely* not what I'm talking about 01.04.06 # <[Franklin]> then what are you talking about? 01.04.53 # <[Franklin]> XRick doesn't execute the blob 01.05.10 # <[Franklin]> it's not technically linking to it then 01.05.29 # <[Saint]> He means, us saying "Here, go to this place to download this" 01.05.37 # If there's no clean download location, the user is expected to find an old floppy and get the data from there (or whatever the original format is) 01.05.51 # <[Franklin]> which makes merging the code perfectly legal 01.06.02 # <[Franklin]> as long as the data isn't distributed with it 01.06.10 # The *code* is not the issue 01.06.20 # Nobody ever said it was 01.06.27 # <[Franklin]> merge the code, leave out the data. simple! 01.06.36 # <[Franklin]> (once its ready) 01.06.50 # <[Saint]> *headdesk* 01.12.48 Join JdGordon [0] (~jonno@ppp118-209-143-204.lns20.mel8.internode.on.net) 01.13.35 Quit JdGordon_ (Ping timeout: 245 seconds) 01.15.23 # * [Franklin] still doesn't get it 01.15.40 # <[Franklin]> what's wrong with including PERFECTLY LEGAL source code? 01.15.54 # <[Franklin]> the data can stay where it is 01.16.04 # WE ARE NOT DISCUSSING SOURCE CODE! 01.16.18 # <[Franklin]> ME THINKS gevaerts SHOULD STOP USING CAPS 01.16.25 # <[Franklin]> but yes, I know 01.16.41 # <[Saint]> You clearly don't. Or, if you do, you're deliberately being a cunt. 01.16.44 # <[Saint]> Pick one. 01.16.44 # So stop trolling 01.17.10 # <[Franklin]> the data is in questionable legal status, I get that 01.17.26 # <[Franklin]> but as long as we don't distribute it, it's fine, right? 01.18.01 # There are levels of not distributing things 01.18.22 # <[Franklin]> leave it the guy's github 01.18.30 # <[Saint]> Not necessarily, no. As gevaerts said, if it is controlled by particularly anal rights holders, even pointing to a place where it can be acquired could potentially put us in hot water. 01.18.48 # Well, I don't think I want something in my Rockbox that doesn't work and then tells me I have to get the data from somewhere, possibly illegally, if I'm understanding this correctly. 01.18.58 # <[Saint]> WHich is the issue you've been missing the point on for the past ten minutes. 01.19.02 # the-kyle: too late 01.19.11 # <[Saint]> too late, the-kyle 01.19.17 # <[Saint]> better uninstall now then. 01.19.19 # lol 01.19.30 # We don't tell you to get things illegally though 01.19.44 # Well no, which was what I was referring to. 01.19.46 # <[Franklin]> exactly! 01.19.50 # <[Saint]> We give you enough info to figure it out, though. 01.19.54 # <[Franklin]> don't say anything about the data 01.19.59 # We tell you to personally dump the ROMs from your pacman machine 01.20.04 # <[Franklin]> just say that "data filse missing" 01.20.08 # <[Franklin]> *files 01.20.11 # <[Franklin]> when you start xrick 01.20.20 # <[Franklin]> and then they google for "xrick data" 01.20.37 # <[Franklin]> and they find it! voila! 01.20.55 # It's perfectly fine to explain how to legally acquire the data and how to verify that you did it correctly 01.21.07 # Yes. 01.21.22 # <[Franklin]> LOL 01.21.44 # This I understand, but I think a link to data of questionable legality may be going too far. One can Google that, it can't be "official." 01.22.00 # * gevaerts nods 01.22.01 # <[Franklin]> exactly' 01.22.19 # <[Franklin]> the name is enough 01.24.33 # <[Franklin]> merge it, and delete all changes to the wiki 01.24.40 # <[Franklin]> that reveal how to get the data 01.24.58 # You don't get it, do you? 01.25.23 # * [Franklin] doesn't understand 01.25.40 # The wiki should tell you how to get the data legally 01.25.51 # * [Franklin] meant that 01.26.01 # <[Franklin]> no "illegal" or "questionable" link 01.26.05 # <[Franklin]> +s 01.26.19 # It's *not* supposed to then suggest that there are other ways 01.26.59 # There has to be a way to obtain the data legally, without question. Then the instructions can be given for how to do this. 01.27.24 # <[Franklin]> and make those seem extremely hard, so people naturally google "xrick data" 01.27.42 # * gevaerts gives up 01.28.01 # <[Franklin]> or not 01.28.23 # The idea is to make it *easy* to figure out how to obtain the data *legally*. 01.29.05 # <[Franklin]> but what if you don't have the LEGAL version of rick dangerous? 01.29.48 # If there is no way to obtain the data legally, then there is no point in distributing the code. 01.29.49 # <[Franklin]> so just explain how to get the data legally on the wiki 01.30.00 # <[Franklin]> of course there's a way 01.30.07 # <[Franklin]> but it isn't that easy 01.30.39 Join Sansa01 [0] (ad3bbec2@gateway/web/freenode/ip.173.59.190.194) 01.31.08 Part Sansa01 01.34.44 *** Saving seen data "./dancer.seen" 01.40.27 # <[Franklin]> gevaerts: so it CAN legally be included? 01.45.37 # <[Franklin]> yes or no, so I know whether or not to work on it 01.46.20 Quit DiaTommy (Ping timeout: 246 seconds) 01.48.30 Quit Scall (Ping timeout: 260 seconds) 02.03.19 Join Scall [0] (~chat@unaffiliated/scall) 02.11.56 Join Pierluigi [0] (~quassel@host-2-99-162-1.as13285.net) 02.12.14 # <[Franklin]> hi Pierluigi 02.12.56 # hi guys 02.13.19 # anyone I can ask some git info? 02.13.24 # <[Franklin]> sure 02.13.30 # <[Franklin]> don't ask to ask :) 02.13.59 # alright thx man :) 02.14.11 # so in regard to this: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2014-10/0000.shtml 02.14.32 # <[Franklin]> oh yeah, thanks for the port :) 02.14.42 # I've been quite busy this week and now looking forward checking stuff in gerrit 02.14.50 # <[Franklin]> [Saint]: see :P 02.14.56 # (you're welcome) 02.15.13 # <[Franklin]> Pierluigi: one bug, in system_rockbox.c, the call to rb->sleep(HZ/1000) is useless 02.15.20 # <[Franklin]> just rb->yield() is fine 02.15.28 # <[Franklin]> sleep is unneccessary 02.15.55 # * [Franklin] can't write to the list 02.15.58 # uhm ok good i'll change it then 02.16.21 # can u elaborate more on it actually? 02.16.27 # just wondering 02.16.27 # <[Saint]> We were just discussing the hilariously vague license terms of the xRick port about an hour ago. 02.16.39 # eh eh I know guys :D 02.16.48 # <[Franklin]> read the logs ;) 02.17.00 # <[Franklin]> In function sys_yield() 02.17.19 # <[Franklin]> all you need is rb->yield() 02.17.21 # <[Franklin]> that's it 02.17.21 # what day should I look at? Today's log? 02.17.28 # <[Franklin]> an hour or so ago 02.17.30 # <[Saint]> Long story short; it can happen, but it'd need to be treated similarly to pacbox in regards to resources of questionable origin 02.17.40 Quit Strife89 (Ping timeout: 245 seconds) 02.17.41 # <[Franklin]> yes 02.17.56 # yes sure I understood but I was just wondering why sleep is useless instead of yeld 02.18.29 # <[Franklin]> all you need is yield, sleep and yield is equivalent to yield twice 02.18.34 # I mean what does yeld (or sleep) do under the hood? 02.18.44 # <[Franklin]> yield switches threads 02.18.45 # didn 't bother checking the sources 02.18.53 # <[Franklin]> so the clock thread can run, for example 02.19.06 # <[Saint]> its essentially the same as yeild() 02.19.17 # <[Franklin]> LOL so many misspellings of yield 02.19.23 # <[Franklin]> yeld, yeild 02.19.30 # <[Saint]> indeed. clumsy fingers here. 02.19.34 Join Strife89 [0] (~Strife89@adsl-98-80-208-37.mcn.bellsouth.net) 02.19.37 # eh eh indeed 02.20.20 # <[Franklin]> so just read the logs :) 02.20.23 # <[Franklin]> and ask about git 02.20.36 # ok gimme few mins :) 02.21.01 # <[Franklin]> sure thing 02.21.07 # <[Saint]> Pierluigi: http://www.rockbox.org/wiki/UsingGit 02.21.18 # <[Saint]> This describes setting up the gerrit hooks in detail 02.21.34 # <[Saint]> and a bit about git in general. 02.21.50 # <[Franklin]> and BTW, commit it as one giant commit 02.21.57 # <[Saint]> FOr more git advice, see gitref.org 02.22.02 # <[Franklin]> it gets annoying with 20 or so commits 02.23.31 # <[Franklin]> you can keep a working branch, and a pushed branch 02.23.51 # <[Franklin]> make all the random commits you want on the working branch, and cherry-pick them to the pushed on 02.23.54 # <[Franklin]> *one 02.24.02 # <[Franklin]> then rebase and push to gerrit when you want to 02.24.57 # <[Franklin]> ( 02.25.02 # <[Franklin]> (at least that's what I do) 02.25.53 # * [Franklin] doesn't know if that's the "right" way 02.26.03 # ok read it 02.26.44 # sorry I thought specifying a sleep value was good to save some extra battery, but if it's just another random yield, yes pretty useless 02.27.05 # <[Franklin]> don't apologize for code you wrote in the past :) 02.27.16 # dunno how sleep and yield are implemented under the hood so, alright we'll definitely change it 02.27.22 # <[Franklin]> BTW, HZ is 100, so HZ/1000 is zero anyway 02.27.25 # *I'll definitely..* 02.27.53 # <[Franklin]> but this is your first plugin? 02.28.11 Quit charlie (Ping timeout: 260 seconds) 02.28.25 # <[Franklin]> if so, wow! 02.28.29 # <[Franklin]> good job 02.28.30 # yes sure 02.28.42 # didn't have much time to look at rockbox sources 02.28.50 # * [Franklin] tried porting Wolf4SDL and failed MISERABLY 02.29.01 # * [Franklin] can't port 02.29.05 # <[Franklin]> only writer 02.29.06 # <[Franklin]> *write 02.29.28 # the idea was to check it in on gerrit, let people test it and refine it based on your review 02.29.40 # <[Franklin]> that's the whole point of gerrit ;) 02.29.58 # definitely faster than trying to look at ALL rockbox sources myself and trying to guess the "right thing" :) 02.30.02 # * [Franklin] wrote 2048, BTW ;) 02.30.21 # <[Franklin]> if you are ever in doubt about how to write a plugin, look at 2048 ;) 02.30.22 # cool franklin :D 02.30.31 # <[Franklin]> (the plugin, not the real game) 02.30.45 # anyway, back to my main question... 02.30.54 # <[Franklin]> LOL sure 02.30.57 # as I asked later on in the email thread... 02.31.19 # I was wondering what the best commit approach would be here 02.31.22 # I mean... 02.31.24 # <[Franklin]> one big commit 02.31.28 # <[Franklin]> definitely 02.31.33 # hmmmm ok 02.31.44 # but then you guys will lose all history 02.31.50 # (I guess?) 02.32.05 # or are u planning to do a merge from my repo at the end? 02.32.18 # I was thinking about the subtree merge as I mentioned 02.32.35 # <[Franklin]> the history doesn't really matter 02.32.53 # hmmm ok 02.33.02 # <[Franklin]> just the final product ;) 02.33.12 # eh eh I appreciate the honesty :) 02.33.24 # <[Franklin]> though any patch sets you commit will be saved on Gerrit indefinitely 02.33.38 # <[Franklin]> so each gerrit revision (patch set) will be saved for future reference 02.34.03 # <[Franklin]> so the sooner you get it on gerrit, the better ;) 02.34.36 # ok so my only other "concern" was about a future merge from my branch, cause I'll probably add stuff/feature/code changes 02.35.02 # <[Franklin]> you can do that, too 02.35.14 # <[Franklin]> after the initial merge, you can push more patches 02.35.18 # but I guess at that point I'll have to generate patches for each change manually and submit to original gerrit thread? 02.35.39 # <[Franklin]> once it gets merged, you start a new gerrit task for each change 02.35.51 Join charlie__ [0] (~c@unaffiliated/charlie) 02.36.21 # (well...I guess I'll just overwrite files locally and commit whatever the overwritten file on my local rockbox repo has...) 02.36.48 # * [Franklin] did something like that with 2048 02.37.00 Join Strife1989 [0] (~Strife89@adsl-98-80-230-126.mcn.bellsouth.net) 02.37.03 # <[Franklin]> after the initial commit, I started a new task to add clip+ support, for example 02.37.58 # * [Franklin] had 47 patch sets for 2048: http://gerrit.rockbox.org/r/#/c/888 02.38.27 # <[Franklin]> and then and then this one http://gerrit.rockbox.org/r/#/c/917/ 02.38.36 # <[Franklin]> no hassles whatsoever 02.38.43 # <[Franklin]> git is magic 02.39.01 Nick megal0maniac is now known as Guest58626 (~megal0man@105.229.173.138) 02.39.01 Quit Guest58626 (Killed (verne.freenode.net (Nickname regained by services))) 02.39.04 Join megal0maniac [0] (~megal0man@105.229.249.119) 02.39.51 Quit Strife89 (Ping timeout: 260 seconds) 02.40.26 # <[Franklin]> so you'll want to commit the installed files (all the files under apps/plugins/xrick) and push to gerrit 02.40.36 # <[Franklin]> git push origin HEAD:refs/for/master 02.40.50 # <[Franklin]> and then it'll be there for all to see ;) 02.40.57 # sounds good 02.41.22 # * [Franklin] thinks all the legal issues have been sorted out now, right [Saint]? 02.41.37 # btw sorry for being so late in checking this thing in, but really had a crazy week 02.42.00 # actually, has anyone tried it already? :D 02.42.05 # <[Franklin]> yes!!! 02.42.09 Quit Strife1989 (Ping timeout: 272 seconds) 02.42.10 # <[Franklin]> it's GREAT 02.42.20 # cool :D 02.42.21 # <[Franklin]> but it has some problems 02.42.25 # <[Franklin]> no load/save 02.42.25 # which hardware? 02.42.28 # <[Franklin]> ipod classic 02.42.45 # oh yes sure the original game has no load/save at all 02.42.50 # <[Franklin]> and it doesn't build (missing keymaps) on some (many) other targets 02.43.05 # <[Franklin]> but it ought to be easy to add, right? 02.44.05 # yes of course keymaps should be added by (hopefully) you guys or whoever it's gonna test it on an hardware other than the ones that I've already got 02.44.21 # <[Franklin]> I mean, just write ammo, lives, position to a file 02.44.54 # <[Franklin]> Pierluigi: we MOST LIKELY are not going to do your work for you ;) 02.45.08 # <[Franklin]> we will help you out, sure 02.45.27 # * [Franklin] got plenty of help with 2048 from these guys, too 02.45.54 # <[Franklin]> but you may want to consider using PLA 02.45.58 # oh yes sure I just was making the point that I can't really commit stuff that I have no hardware for :P 02.46.04 # <[Franklin]> actually you can 02.46.09 # <[Franklin]> that's what the sim's for 02.46.38 # uhm...don't trust it really... 02.46.39 # <[Franklin]> be sure to test on 1-bit, greyscale, and color targets 02.46.48 # <[Franklin]> Pierluigi: the sim is fine for testing plugins, really 02.46.52 Nick megal0maniac is now known as Guest55078 (~megal0man@105.229.249.119) 02.46.52 Quit Guest55078 (Killed (sinisalo.freenode.net (Nickname regained by services))) 02.46.54 # got a very different behaviour on real hardware 02.46.56 Join megal0maniac [0] (~megal0man@ti-224-252-12.telkomadsl.co.za) 02.47.01 # I'm talking about diagonals for example 02.47.05 # <[Franklin]> for lower-level stuff, you need real HW, but for most things, the sim is fine 02.47.15 # <[Franklin]> excuse me? 02.47.16 # not to mention iram 02.47.19 # <[Franklin]> ahh 02.47.21 # iriver for example 02.47.21 # <[Franklin]> true 02.47.25 # <[Franklin]> very true 02.47.43 # <[Franklin]> but most of the time, you should at least test on the sim 02.47.49 # <[Franklin]> all the time, actually 02.48.35 # hmmm I thought better to check it in on gerrit first 02.48.48 # getting some feedback from other devs and then tweak 02.48.50 # <[Franklin]> yeah, get the code out first, that's for sure 02.49.03 # <[Franklin]> but then test 02.49.04 # afterall this is what peer review is about right? 02.49.06 # <[Franklin]> and add features 02.49.09 # <[Franklin]> and fix stuff ;) 02.50.32 # <[Franklin]> oh yeah, don't forget to add yourself to the CREDITS 02.50.46 # tested iriver h120 sim and it worked...I'm actually very curious if it's gonna ever work on the real greyscale targets :) 02.51.11 # <[Franklin]> if DOOM can work, then this can :) 02.51.15 # ou..ok will do... :P 02.51.33 # eh eh very true :) 02.51.36 # <[Franklin]> but strangely enough... 2048 WON'T run on archos :) 02.51.59 # <[Franklin]> or will it? 02.52.27 # also the initial implementation I had wasn't using audio buffer ram at all 02.52.53 # I had it running with sound in the 512k plugin ram 02.53.00 # <[Franklin]> wow 02.53.10 # * [Franklin] likes that his ipod has 64M ram 02.53.16 # <[Franklin]> great for calculating pi 02.53.21 # but the only reason why I wanted that to happen was because I wanted people to be able to stop and play audio 02.53.39 # <[Franklin]> Pierluigi: also, don't forget the manual entry 02.53.40 # so I had it running quite nice 02.54.24 # manual? uhm...maybe I'll add later as an additional patch... 02.54.36 # <[Franklin]> no... every plugin needs to come with a manual entry 02.54.42 # * [Franklin] learned it the hard way 02.54.43 # no time to write it right now 02.54.47 # :) 02.54.49 # <[Franklin]> well sure 02.54.59 # <[Franklin]> but if you want it to get merged, it needs a manual 02.55.25 # yeah sure agree, controls at least might be tricky to get without a manual 02.56.01 Join CaptainKewl [0] (~captainke@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 02.56.15 # anyway, I learned the "hard way" that once u start playback u can't use ingame audio 02.56.22 # or viceversa I can't remember 02.56.48 # * [Franklin] didn't need one 02.57.38 Quit Scall (Ping timeout: 244 seconds) 02.57.47 # so, for example, user can't start stop playback using, say, xrick playback menu, and then having xrick making sound again 02.58.44 # or maybe because I couldn't recall/regive requested audio buffer back 03.00.01 Quit AlexP (Remote host closed the connection) 03.00.01 # would be nice if I could "release" the requested audio buffer so that the system can play audio again, and maybe request it back if I (for example) decide to stop audio and load my sounds 03.00.51 # but anyway...there was also the problem of continuos disk swap happening for pretty much every sound 03.01.18 # so in the end I had to scrap my design and just allocate all sounds into audio buffer memory 03.01.43 # at least now everything is preallocated so no disk access while playing = better battery life 03.02.52 # but it would be could if I people could play their favourite mp3 and having the plugin spitting out game sounds that would be mixed on top of the main mp3 by rockbox engine 03.03.23 # *it would be cool if people* 03.04.00 # so... on sim everything fancy and cool but then on hardware....it's a different story :) 03.04.25 # well that's what embedded dev is about afterall :) 03.04.31 Join Strife89 [0] (~Strife89@adsl-98-80-240-127.mcn.bellsouth.net) 03.05.54 # ok enough said, I'll go have a look at gerrit info (never used it before) and have xrick checked it tonight/tomorrow 03.06.21 # thx guys 03.06.27 # <[Franklin]> thank you 03.06.33 # * [Franklin] has to go 03.06.36 Quit [Franklin] (Remote host closed the connection) 03.09.19 Join Scall [0] (~chat@unaffiliated/scall) 03.09.23 Quit Pierluigi (Remote host closed the connection) 03.10.38 Join Strife1989 [0] (~Strife89@adsl-98-80-218-87.mcn.bellsouth.net) 03.10.57 Quit Strife89 (Ping timeout: 258 seconds) 03.11.29 Join joshuasm32 [0] (~joshuasm3@cpe-67-49-188-187.hawaii.res.rr.com) 03.11.36 # Hello 03.11.40 # Can I get some help? 03.11.50 # I am new to Rockbox. 03.11.59 # I would like to install it on an iPod Classic. 03.12.05 # But I'm having some problems... 03.15.21 Quit Strife1989 (Ping timeout: 240 seconds) 03.15.22 # Hello? 03.15.27 # Anyone home? 03.15.38 # :-/ 03.16.19 # Aw... 03.16.30 # Looks to me like this is a dead IRC. 03.16.34 # Shame. 03.16.42 # I'll have to use the forum. 03.17.06 # >_> 03.17.09 # Hey 03.17.11 # >no answer in 20 minutes 03.17.16 # >dead IRC 03.17.19 # Can you help? 03.17.20 # >117 users 03.17.32 # Ok. 03.17.34 # just describe your problem 03.17.42 # I'm trying to install Rockbox on an iPod classi c 03.17.44 # someone who understands might roll back and read it and respond, however latent 03.17.49 # I reformatted it 03.18.06 # Then used the rockbox utility (on ubuntu) with sudo 03.18.16 Join Strife1989 [0] (~Strife89@adsl-98-80-200-73.mcn.bellsouth.net) 03.19.08 # I installed it (with all themes) 03.19.12 # And hard reset the iPod 03.19.16 # but nothing happened 03.19.21 # I tried this several times 03.19.26 # even without reformatting it 03.19.36 # and it won't boot into anything but the apple os 03.19.42 # I selected the right mount point 03.19.45 # any solutions? 03.25.13 Quit Strife1989 (Ping timeout: 272 seconds) 03.26.12 Join Strife1989 [0] (~Strife89@adsl-98-80-200-118.mcn.bellsouth.net) 03.26.42 # no idea 03.26.45 # maybe someone else will 03.28.13 Join varogami1 [0] (~varogami@dynamic-adsl-94-34-4-47.clienti.tiscali.it) 03.28.37 # What should happen? 03.28.52 # When I install it? 03.28.57 # On boot? 03.29.26 # I would naturally assume that rockbox boots up 03.29.43 # it dual-boots on mine, but I have no idea if that is the standard 03.30.48 Nick varogami1 is now known as varogami (~varogami@dynamic-adsl-94-34-4-47.clienti.tiscali.it) 03.31.21 # Wow 03.31.24 # That's awesome. 03.31.33 # You have an iPod classic? 03.31.37 # With it working? 03.31.41 # No, a random other machine 03.31.44 # I was worried, because it is "experimental" 03.32.11 # A sansa zip clip 03.32.17 # Oh nice 03.32.25 # Anyone else? 03.32.26 # :/ 03.32.33 # well, it's like I just said 03.32.42 # if anyone's going to answer, it's not going to be because you summoned them 03.32.48 # it's just like a forum, wait for someone to answer 03.32.58 # right... 03.33.03 # idk just slow here :)\ 03.33.12 # well, if it went 'fast' 03.33.16 # you'd never get a word in edgewise 03.33.26 # this is arguably better, the chances of someone reading your complaints are incredibly high 03.34.46 *** Saving seen data "./dancer.seen" 03.40.10 # <[Saint]> What do you mean by "iPod Classic" 03.40.42 # iPod Classic, 6G 03.40.45 # <[Saint]> Are you are, that, if you mean the 6th or 7th generation, that Rockbox Utility cannot install the bootloader, and clearly states this if you try. 03.40.46 # Last model made 03.40.50 # It was discontinued 03.40.57 # <[Saint]> see above. 03.41.22 # <[Saint]> Rockbox Utility cannot and will not install the bootloader required for Rockbox to function. 03.41.35 # <[Saint]> That is an entirely unrelated and unsupported product. 03.41.46 # <[Saint]> Handled by the Freemyipod team, called emCORE. 03.41.49 Join saanaito [0] (~Strife89@adsl-98-80-229-7.mcn.bellsouth.net) 03.42.13 # Really? 03.42.19 # I thought it was a dev version! 03.42.28 # <[Saint]> No. I justmade it up. 0_o 03.42.35 # So... Rockbox can and will not go on my iPod? 03.43.06 # <[Saint]> Rockbox can be installed on the device. Yes. But we don't have any part in the bootloader required to run it. 03.43.17 # <[Saint]> That is an entirely separate project. 03.43.35 # <[Saint]> see: http://www.freemyipod.org/wiki/EmCORE 03.43.53 # Thank you 03.44.14 Quit Strife1989 (Ping timeout: 260 seconds) 03.44.26 # <[Saint]> Rockbox Utility can update a Rockbox installation, and install the Rockbox binary, but only because no special permissions are required to do so. 03.44.44 # <[Saint]> All "installing Rockbox" is doing here is extracting an archive to the root of the device. 03.45.16 # <[Saint]> Its the bootloader that is actually key to functionality, and that part Rockbox Utilty cannot handle. Neither installation nor removal. 03.45.23 # "Fastboot was an emCORE application that was used to launch Rockbox or OF instantly when the iPod turns on. It is now discontinued, and its functionality is moved to the Boot menu." 03.45.29 # Does this still work? 03.45.46 # <[Saint]> see: http://www.freemyipod.org/wiki/EmCORE_Installation 03.46.37 # <[Saint]> The relevant channel for support with said product is #freemyipod-support 03.46.55 # <[Saint]> Support for emCORE or its installation isn't handled at all by Rockbox. 03.46.58 # Thank you so much! 03.47.20 # <[Saint]> Myself and several other from this channel reside there also. 03.47.25 # <[Saint]> *others 03.48.04 # I already extracted Rockbox... Do I need to remove it and start over? 03.48.06 # <[Saint]> If at all possible, avoid the Windows installation methods like the plague. I'll offer that much advice here. 03.48.14 # I'm using Linux. :) 03.48.24 # <[Saint]> No. You do not. Installation will format the entire storage. 03.48.31 # Ok. 03.48.32 # Good. 03.48.34 # <[Saint]> So, remember to backup any content you don't want to lose. 03.48.43 # Already done. :) 03.48.56 # I believe Rockbox is open-sourced... Is this true? 03.49.11 # If so, is it a Linux fork of some kind? 03.49.18 Nick saanaito is now known as Strife89 (~Strife89@adsl-98-80-229-7.mcn.bellsouth.net) 03.49.18 # <[Saint]> If you have any more specific queries of issues with installation of emCORE< I can handle them at #freemyipod-support 03.49.26 # <[Saint]> And, yes. It is. 03.49.29 # alright 03.49.38 # <[Saint]> http://git.rockbox.org/ 03.49.43 # :D 03.49.45 # Nice 03.58.28 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 04.01.47 Quit amiconn (Disconnected by services) 04.01.47 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.01.47 Quit pixelma (Disconnected by services) 04.01.48 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.01.50 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.01.50 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.20.35 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 04.25.23 Part joshuasm32 04.29.21 # Is there a simple way to disable font glyph caches in Rockbox? I mean by a small code change 04.30.10 # I think they're causing some problem, because when I delete the *font*.gc file, the problem goes away and returns after the .gc file has been regenerated. 04.30.42 # <[Saint]> What is "some problem"? 04.30.53 # <[Saint]> What's the actual issue you're seeing? 04.33.30 # Textviewer runs too slow, as in it takes 10 seconds to move a line 04.34.09 # Only on certain files that seem to have some strange (probably not in font) characters in them 04.34.39 # <[Saint]> Ahhh, possibly fighting to do glyph substitution. 04.34.57 # So what could I do? 04.35.46 # <[Saint]> I'm not sure of that at all. 04.36.08 # <[Saint]> Sorry. I don't know a thing about the font subsystem except for where it attaches to the theme code. 04.36.47 # Would disabling it slow it down even worse? 04.40.09 # <[Saint]> That iPod Classic user was an absolute pleasure todeal with. 04.40.20 # <[Saint]> God I wish they were all like that... 04.50.00 # ikeboy: is it all fonts? 04.51.28 # I haven't tried others. I just tried now commenting the font_path_to_glyph_path calls, which makes rendering slower but doesn't help the problem, so it may not be related 04.52.15 # I'll try other fonts now. I was using the 12 adobe helvetica one 04.57.24 # Trying a few others, it appears to only show up on that font 04.57.48 # Any known peculiarities of 12 adobe helvetica? 04.59.15 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.59.15 Quit amiconn (Disconnected by services) 04.59.16 Quit pixelma (Disconnected by services) 04.59.16 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.59.19 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.59.19 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.59.25 Quit charlie__ (Ping timeout: 272 seconds) 05.01.12 Join charlie [0] (~c@unaffiliated/charlie) 05.11.58 Join joshuasm32 [0] (~joshuasm3@cpe-67-49-188-187.hawaii.res.rr.com) 05.14.28 # One other thing... 05.14.35 # I'm trying to add Doom. :) 05.14.48 # When I run it, it says it is missing its encoding engine. 05.15.01 # I copied all of the files where they need to go... 05.17.39 # Nevermind. 05.23.05 Quit the-kyle (Remote host closed the connection) 05.27.35 Join the-kyle [0] (~kyle@kyle.tk) 05.29.43 Quit TheSeven (Ping timeout: 260 seconds) 05.30.59 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.34.50 *** Saving seen data "./dancer.seen" 05.35.52 Quit joshuasm32 (Ping timeout: 260 seconds) 05.37.44 Quit krabador (Read error: Connection reset by peer) 05.42.05 Quit varogami (Ping timeout: 272 seconds) 05.50.13 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 06.16.37 Quit ikeboy (Quit: Leaving) 06.22.02 Join yuriks [0] (~quassel@opentyrian/developer/yuriks) 06.22.10 # Hi 06.22.38 # does anyone know what's the status on this? http://www.rockbox.org/tracker/11108 Has there been any development on the required parts of the USB stack? 06.34.42 # I get an Internal Server Error every time I try to set a username, anyone knows what's up? 06.44.50 Join kugel [0] (~kugel@rockbox/developer/kugel) 06.53.39 Quit kugel (Ping timeout: 272 seconds) 07.01.01 Quit Strife89 (Ping timeout: 245 seconds) 07.01.38 # <[Saint]> 1 - no. 07.01.48 # <[Saint]> 2 - works for me, ne user registration went smoothly 07.01.52 # <[Saint]> *new 07.02.11 # <[Saint]> The progress you see in the task is all the progress that exists. 07.03.31 # <[Saint]> that was fr you, by the way, yuriks 07.04.34 # [Saint]: er, oops. I meant on Gerrit, just realized I hadn't mentioned that 07.04.41 # and thanks 07.12.20 # <[Saint]> TheSeven: what do you make of "ATA Error -2147483542: Press ON to Debug"? 07.12.28 # <[Saint]> ...failing disk? 07.12.38 Join Strife89 [0] (~Strife89@adsl-98-80-232-103.mcn.bellsouth.net) 07.12.50 # I'd be interested in developing that, but as per the usual, I probably don't have time and don't have the slightest clue about USB stacks 07.23.05 Join kugel [0] (~kugel@89.204.153.80) 07.23.21 Quit kugel (Changing host) 07.23.21 Join kugel [0] (~kugel@rockbox/developer/kugel) 07.33.22 Quit kugel (Ping timeout: 240 seconds) 07.34.53 *** Saving seen data "./dancer.seen" 08.04.06 Nick megal0maniac is now known as Guest49312 (~megal0man@ti-224-252-12.telkomadsl.co.za) 08.04.06 Quit Guest49312 (Killed (card.freenode.net (Nickname regained by services))) 08.04.10 Join megal0maniac [0] (~megal0man@ti-226-128-178.telkomadsl.co.za) 08.07.12 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.22.18 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.23.38 Join JdGordon_ [0] (~jonno@ppp118-209-247-118.lns20.mel8.internode.on.net) 08.24.52 Quit kugel (Remote host closed the connection) 08.25.14 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.25.14 Quit kugel (Changing host) 08.25.14 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.25.50 Quit kugel (Remote host closed the connection) 08.25.59 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.26.07 Quit JdGordon (Ping timeout: 272 seconds) 08.26.39 Join mortalis [0] (~kvirc@212.44.150.238) 08.27.31 Quit kugel (Remote host closed the connection) 08.27.41 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.27.41 Quit kugel (Changing host) 08.27.41 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.33.07 Join ender` [0] (krneki@foo.eternallybored.org) 08.33.31 Quit kugel (Ping timeout: 245 seconds) 08.38.23 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.39.16 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 08.40.09 Join kugel__ [0] (~kugel@rockbox/developer/kugel) 08.41.02 Join kugel___ [0] (~kugel@rockbox/developer/kugel) 08.41.02 *** Alert Mode level 1 08.41.02 DBUG Enqueued KICK kugel 08.41.02 DBUG Enqueued KICK kugel_ 08.41.02 *** Alert Mode level 2 08.41.02 DBUG Enqueued KICK kugel__ 08.41.02 DBUG Enqueued KICK kugel___ 08.41.02 *** Alert Mode level 3 08.41.58 Join kugel____ [0] (~kugel@rockbox/developer/kugel) 08.41.58 *** Alert Mode level 4 08.41.58 *** Alert Mode level 5 08.41.58 DBUG Enqueued KICK kugel____ 08.41.58 *** Alert Mode level 6 08.41.58 *** Alert Mode level 7 08.41.58 *** Alert Mode level 8 08.41.58 *** Alert Mode level 9 08.42.57 Join kugel___1 [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.43.31 Quit kugel (Ping timeout: 245 seconds) 08.43.45 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.43.45 *** Alert Mode level 10 08.43.45 *** Alert Mode level 11 08.43.45 DBUG Enqueued KICK kugel 08.43.45 *** Alert Mode level 12 08.43.45 *** Alert Mode level 13 08.43.45 *** Alert Mode level 14 08.43.45 *** Alert Mode level 15 08.44.20 Quit kugel_ (Ping timeout: 260 seconds) 08.44.30 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 08.44.30 *** Alert Mode level 16 08.44.30 *** Alert Mode level 17 08.44.30 DBUG Enqueued KICK kugel_ 08.44.30 *** Alert Mode level 18 08.44.30 *** Alert Mode level 19 08.44.30 *** Alert Mode level 20 08.44.30 *** Alert Mode level 21 08.45.06 Quit kugel___ (Remote host closed the connection) 08.45.16 Quit kugel__ (Ping timeout: 245 seconds) 08.45.48 Quit kugel (Remote host closed the connection) 08.45.56 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.46.00 # [Saint]: ping 08.47.37 Quit kugel____ (Ping timeout: 272 seconds) 08.48.03 Quit kugel___1 (Ping timeout: 260 seconds) 08.50.14 Quit kugel_ (Remote host closed the connection) 08.50.53 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.51.38 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 08.52.24 Join kugel__ [0] (~kugel@rockbox/developer/kugel) 08.53.18 Join kugel___ [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.53.21 Quit kugel___ (Changing host) 08.53.21 Join kugel___ [0] (~kugel@rockbox/developer/kugel) 08.53.21 *** Alert Mode level 22 08.53.21 *** Alert Mode level 23 08.53.21 DBUG Enqueued KICK kugel 08.53.21 DBUG Enqueued KICK kugel_ 08.53.21 DBUG Enqueued KICK kugel__ 08.53.21 DBUG Enqueued KICK kugel___ 08.53.21 *** Alert Mode level 24 08.53.21 *** Alert Mode level 25 08.53.21 *** Alert Mode level 26 08.53.39 # <[Saint]> wodz: good timing, found some Rockbox time, just started the build now, its about 30s away from completion. Then testing. 08.53.54 # [Saint]: cool 08.54.01 # [Saint]: Rockbox is a linux fork? 08.54.02 Quit kugel___ (Remote host closed the connection) 08.54.10 Join kugel___ [0] (~kugel@rockbox/developer/kugel) 08.54.10 *** Alert Mode level 27 08.54.10 *** Alert Mode level 28 08.54.10 DBUG Enqueued KICK kugel___ 08.54.10 *** Alert Mode level 29 08.54.10 *** Alert Mode level 30 08.54.10 *** Alert Mode level 31 08.54.14 # <[Saint]> g#842 - g#843, and g#844 08.54.24 # 3Gerrit review #842 at http://gerrit.rockbox.org/r/842 : 3Revert "Change control handling to start expecting host packets before sending data... by Michael Sparmann 08.54.24 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 08.54.25 # 3Gerrit review #844 at http://gerrit.rockbox.org/r/844 : 3usb-designware: New USB driver for Synopsys DesignWare USB OTG core. by Michael Sparmann 08.54.52 # <[Saint]> pixelma: ...wha? 08.55.09 Join kugel____ [0] (~kugel@rockbox/developer/kugel) 08.55.09 *** Alert Mode level 32 08.55.09 *** Alert Mode level 33 08.55.09 DBUG Enqueued KICK kugel____ 08.55.09 *** Alert Mode level 34 08.55.09 *** Alert Mode level 35 08.55.09 *** Alert Mode level 36 08.55.09 *** Alert Mode level 37 08.56.04 Join kugel___1 [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.56.27 # The joshua guy asked two questions (if Rockbox is free and if it is a linux fork of some kind) and your "yes, it is" can be understood as if both is true 08.56.30 Quit kugel (Ping timeout: 272 seconds) 08.56.53 Quit kugel_ (Ping timeout: 250 seconds) 08.56.53 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.56.53 *** Alert Mode level 38 08.56.53 *** Alert Mode level 39 08.56.53 DBUG Enqueued KICK kugel 08.56.53 *** Alert Mode level 40 08.56.53 *** Alert Mode level 41 08.56.53 *** Alert Mode level 42 08.57.03 # <[Saint]> Ah, sorry, I didn't catch that bit. Was just referring to the source availability. 08.57.25 Quit kugel (Remote host closed the connection) 08.57.40 # Not "free", "open-sourced" was his question 08.57.47 Quit kugel__ (Ping timeout: 272 seconds) 08.57.47 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.58.22 Quit kugel (Remote host closed the connection) 08.58.44 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.58.44 Quit kugel (Changing host) 08.58.44 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.59.16 Quit kugel (Remote host closed the connection) 08.59.20 Quit kugel___ (Ping timeout: 260 seconds) 08.59.38 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 08.59.38 Quit kugel (Changing host) 08.59.38 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.59.40 # <[Saint]> Arrrrrgggghhhh. For fucks sake! 08.59.47 # <[Saint]> I fucking hate this patch series. 08.59.50 # <[Saint]> Its a cock. 09.00.10 Quit kugel (Remote host closed the connection) 09.00.11 Quit kugel____ (Ping timeout: 245 seconds) 09.00.15 # <[Saint]> Build fails, fix error, build fails again, revert clean, ...conflict. 09.00.22 # <[Saint]> Fuck this shit man, honestly. 09.00.32 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 09.00.32 Quit kugel (Changing host) 09.00.32 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.01.01 Quit kugel___1 (Ping timeout: 245 seconds) 09.01.04 Quit kugel (Remote host closed the connection) 09.01.57 # <[Saint]> Aaaaaand, no .rej file. 09.02.00 # <[Saint]> Fucking classic. 09.03.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.04.05 Quit pamaury (Ping timeout: 272 seconds) 09.04.28 Quit kugel (Remote host closed the connection) 09.04.41 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.05.35 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 09.06.10 Quit kugel_ (Remote host closed the connection) 09.06.17 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 09.06.23 # <[Saint]> Fucks sake. The patch series won't even apply on head anymore and I really cannot be fucked finding out why. 09.06.54 *** Alert Mode OFF 09.07.04 Quit kugel_ (Remote host closed the connection) 09.07.06 Join kugel__ [0] (~kugel@rockbox/developer/kugel) 09.07.51 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 09.08.11 # [Saint]: you fuck too much, thats why 09.08.38 Join kugel___ [0] (~kugel@rockbox/developer/kugel) 09.08.38 *** Alert Mode level 1 09.08.38 DBUG Enqueued KICK kugel 09.08.38 DBUG Enqueued KICK kugel__ 09.08.38 *** Alert Mode level 2 09.08.38 DBUG Enqueued KICK kugel_ 09.08.38 DBUG Enqueued KICK kugel___ 09.08.38 *** Alert Mode level 3 09.08.38 Quit kugel__ (Remote host closed the connection) 09.08.39 Quit kugel_ (Remote host closed the connection) 09.08.44 # <[Saint]> 949 won't apply with its depend anymore. 09.08.58 # <[Saint]> And it gives me absolutely zero indication as to why. 09.09.21 Quit kugel (Ping timeout: 240 seconds) 09.09.39 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.10.18 Quit kugel (Remote host closed the connection) 09.10.38 # <[Saint]> 843 and 843 apply no worries. 949 just dies, and I don't get a .rej file, nor a clear explanation as to why. 09.10.40 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.11.03 # <[Saint]> "error: could not apply 30663c9... usb-designware: New USB driver for Synopsys DesignWare USB OTG core. 09.11.03 # <[Saint]> hint: after resolving the conflicts, mark the corrected paths" 09.11.07 # <[Saint]> ...descriptive. 09.11.12 Quit kugel (Remote host closed the connection) 09.11.14 # <[Saint]> That really helps me, like, a lot. 09.11.34 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 09.11.34 Quit kugel (Changing host) 09.11.34 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.12.10 Quit kugel (Remote host closed the connection) 09.12.32 Join kugel [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 09.12.32 Quit kugel (Changing host) 09.12.32 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.13.11 Quit kugel (Remote host closed the connection) 09.13.16 Quit megal0maniac (Ping timeout: 244 seconds) 09.13.24 Join megal0maniac [0] (~megal0man@ti-224-255-152.telkomadsl.co.za) 09.13.25 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.13.43 Quit kugel___ (Ping timeout: 260 seconds) 09.14.13 Quit kugel (Remote host closed the connection) 09.14.18 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 09.14.53 Quit kugel_ (Remote host closed the connection) 09.15.07 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.15.44 Quit kugel (Remote host closed the connection) 09.16.11 # <[Saint]> Ohhhhh. Crap. 09.16.22 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.16.54 Quit kugel (Remote host closed the connection) 09.17.08 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.17.21 # [Saint]: hehe, my friend used to say : " easy stuff is for waiters" :-) 09.18.02 Join kugel_ [0] (~kugel@p5DDB6F1F.dip0.t-ipconnect.de) 09.18.02 Quit kugel_ (Changing host) 09.18.02 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 09.18.36 Quit kugel_ (Client Quit) 09.18.39 *** Alert Mode OFF 09.19.23 # <[Saint]> Right. Finally figure that mess out. Take two. 09.19.59 Join petur [0] (5bb7304d@rockbox/developer/petur) 09.22.27 Quit kugel (Ping timeout: 272 seconds) 09.24.21 # ahh, looks like I finally found out hw init part in atj firmware. 09.28.06 # <[Saint]> [ 9268.947010] sd 7:0:0:0: [sdc] 19537686 4096-byte logical blocks: (80.0 GB/74.5 GiB) 09.28.06 # <[Saint]> [ 9268.948380] sd 7:0:0:0: [sdc] Attached SCSI removable disk 09.28.06 # <[Saint]> [ 9320.721538] sdc: detected capacity change from 80026361856 to 0 09.28.06 # <[Saint]> [ 9323.718439] usb 1-5: USB disconnect, device number 5 09.28.06 # <[Saint]> [ 9345.732094] usb 1-5: new high-speed USB device number 6 using ehci-pci 09.28.07 *** Alert Mode level 1 09.28.07 # <[Saint]> [ 9360.844097] usb 1-5: device descriptor read/64, error -110 09.28.11 # <[Saint]> Oh dear. 09.28.34 # <[Saint]> No hard lock - but, no mount, either. 09.28.52 # <[Saint]> And that capacity change to 0 tweaks my interest. 09.28.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.29.48 # <[Saint]> The difference between my case and TheSeven's seems to be my devices don't lock up on connect. 09.30.24 # <[Saint]> Just so we're clear, this is with g#842, g#843, and g#949 applied. 09.30.31 # 3Gerrit review #842 at http://gerrit.rockbox.org/r/842 : 3Revert "Change control handling to start expecting host packets before sending data... by Michael Sparmann 09.30.31 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 09.30.32 # 3Gerrit review #949 at http://gerrit.rockbox.org/r/949 : 3usb-designware: New USB driver for Synopsys DesignWare USB OTG core. by Michael Sparmann 09.30.45 # n2g or classic? 09.30.57 # <[Saint]> Classic. Just trying N2g now. 09.31.23 # I am not entirely sure you need #843 on classic but should not harm either 09.32.04 # <[Saint]> I do need it for n2g, though. 09.32.09 # [Saint]: yes 09.32.22 # <[Saint]> Aha. n2g *does* hard lock. 09.32.25 # <[Saint]> Interesting. 09.32.34 # <[Saint]> Same capacity at 0 in dmesg. 09.32.42 # [Saint]: wait, so the previous version (without timeouts) worked and this one doesn't? Thats insane 09.33.01 # <[Saint]> That's how it appears, yes. 09.33.12 # same compiler? 09.33.40 # <[Saint]> I wonder whats triggering the reported capacity to change after connect... 09.34.12 # <[Saint]> Yes, same compiler, but the build system went trhough a rather radical round of updates in the past month or so. 09.34.34 # <[Saint]> So I can't in good confidence say the environment is identical. 09.34.54 *** Saving seen data "./dancer.seen" 09.35.35 # <[Saint]> Aha. Just got my Classic to lock up. 09.35.42 # <[Saint]> Though, its not a _hard_ lock. 09.35.59 # <[Saint]> The backlight thread appears to still be running, unlike n2G, which locked up hard. 09.37.14 # <[Saint]> Perhaps interestingly, the Classic is no longer responding to long play to shut down, which I had thought was hardware controoled. 09.37.31 # <[Saint]> I had to force a menu+select reboot. 09.38.08 *** Alert Mode OFF 09.38.13 # <[Saint]> Nano2g behaved as it should when I went to reset it. Perhaps my play key on this Classic is slightly dodgy. 09.42.04 # <[Saint]> Hmmm...if I boot with USB plugged, dmesg never sees Rockbox at all. 09.42.13 # <[Saint]> It still thinks its the emCORE debugger. 09.44.09 Join xorly [0] (~xorly@m180.dkm.cz) 09.44.52 # <[Saint]> wodz: TheSeven: http://pastebin.com/bwHVTkhA 09.45.23 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.46.30 # <[Saint]> And another, with more (and wildly different) detail: http://pastebin.com/WUQzTqnV 09.53.24 # <[Saint]> wodz: if you've any idea on what to try next - I'll be watching the logs 09.53.49 # [Saint]: You can try to dump usb traffic with wireshark or so 09.55.03 # <[Saint]> So, my guess is its failing to mount because the reported capacity abruptly changes after a disconnect/reconnect? 09.55.31 # <[Saint]> I imagine its quite difficult to mount a disk that reports a capacity of 0 09.56.03 # <[Saint]> also - will do, I'll have a poke. Been a while since I played with wireshark. 09.57.30 # Anyone has an idea how to see raw rgb565 values as actual image? 10.03.47 # <[Saint]> Just pack it with an .srf extension, I thought? 10.05.31 # <[Saint]> imagemagick can do it, but I can't seem to recall how. 10.08.47 Join foolsh [0] (~bbrown@c-67-174-138-234.hsd1.in.comcast.net) 10.10.22 Quit Strife89 (Ping timeout: 272 seconds) 10.13.15 # http://rawpixels.net/ did the trick 10.18.03 Ctcp Ignored 18 channel CTCP requests in 27 minutes and 36 seconds at the last flood 10.18.03 # * [Saint] stops searching through his imagemagick snippets 10.18.14 # <[Saint]> Also - nice find. That's a cute service. 10.22.30 Join Strife89 [0] (~Strife89@adsl-98-80-237-113.mcn.bellsouth.net) 10.31.57 # wodz: you can load teh dump into gimp 10.32.48 # kugel: I failed to find easily how to set rgb565 input format 10.33.14 # man, these USB specs are terrible 10.33.25 # name the file *.data, and open with gimp. for this file extension gimp will show a dialog for you to set the format 10.33.38 # kugel: I'm not sure it support 565 with that 10.34.25 # anyway the service I linked is pretty nice for my purpose 10.34.58 # wodz: also in the file open dialog there is an expander in the bottom area, allowing you to override its guess. select data there and it'll show the same dialog 10.35.31 # kugel: thanks for the hing 10.35.34 # *hint 10.35.51 # the website seems to support a lot more formats, though 10.36.45 # [Saint]: did the decryption reverse engineering efforts on the newer ipods ever get anywhere? 10.40.10 # <[Saint]> we have arbitrary execution on the nano4g, and, in theory, a nano3g port is mostly already written, as it is incredibly similar to known hardware in the tree in many ways and we have an active exploit for it (it was actually a guy drawing attention to the nano3g exploit possibility that lead to the Classic port, if I remember correctly...but its been a while). 10.40.39 # <[Saint]> can't talk to the storage on nano4g, though, so you're limited to poking around in RAM. 10.41.11 # <[Saint]> No one has tried to port to the nano3g to my knowledge, at all. 10.41.21 # <[Saint]> That device was hilariously unpopular. 10.41.28 # sounds like good progress anyway. It's been years since I had last checked. I made my life happier by just buying a clip :P 10.42.04 # [Saint]: hey, I had one :P 10.42.17 # <[Saint]> As for the nano5g, no. But, some of the iPhone/iPod Touch tethered exploits might bear fruit. 10.42.30 # [Saint]: AFAIK n3g FTL is the blocker 10.42.41 # <[Saint]> Aha, thanks. 10.44.26 # <[Saint]> Oh. I told a lie. 10.45.01 # <[Saint]> user890104 has done some work porting emCORE to the 1st gen (untethered jailbreakable) iPod Touch. 10.45.49 # <[Saint]> One could, in theory, compile Rockbox to run on the jailbroken iPod/iPod Touches. 10.46.26 # would probably be more productive to improve the android version and port it to iOS 10.46.37 # <[Saint]> Likely with fairly minimal changes to the codebase, too. 10.46.55 # <[Saint]> I...huh? 10.47.26 # hm? 10.47.50 # <[Saint]> Sorry, if it wasn't clear, I mean "as an application", not as an OS replacement. 10.47.57 # <[Saint]> That's a whole other ballgame. 10.48.09 # ah, yeah, then that's also what I'm talking about 10.48.17 # I thought you were saying as an OS replacement :) 10.48.38 # <[Saint]> Like we already do on Android. But, it wouldn;t be porting Android version to iOS, it would be a distinct original creation. 10.49.13 # well, wouldn't you share most of the app code? 10.49.50 # the transition from embedded hardware with buttons to multitasking OS with a touchscreen only needs to be done once, was my point 10.51.00 # <[Saint]> It would, yes, but that would also enable one to say that a new Rockbox device port would be a port of the Android version. Or vice versa. 10.51.33 # Is anyone seriously consider iOS as a platform considering their licensing terms? 10.51.54 # whats the point of free software on completely locked down platform? 10.51.54 # wodz: where there's hardware, there'll be someone wanting to run code on it :) 10.51.58 # <[Saint]> No one would consider pushing it to the app store. 10.52.00 # <[Saint]> fuck that. 10.52.07 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 10.52.09 # <[Saint]> Cydia. 10.52.24 # [Saint]: I guess what I said would make more sense if Android was the only app target, which it isn't anymore... 10.52.48 # <[Saint]> Nor was it the first. 10.53.23 # <[Saint]> We had an SDL app for an age before the other hosted ports. 10.55.03 # indeed 10.55.37 # well, I'll sleep. Maybe I'll continue reading USB specs and exploring the rockbox code some other day, maybe not 10.56.05 # anyway rockboxlib is the way to go BUT 1) kugel has no time to finish 2) noone stepped up to be workhorse of this development 10.57.38 # <[Saint]> I tried wrapping a very basic native UI around warble on Android but didn't get very far. 10.58.10 # <[Saint]> In fact I got so not far I think that's the first time I ever mentioned it. 10.58.28 # *ages*? 10.58.53 # <[Saint]> For varying definitions thereof, yes. 10.59.01 # I don't remember the exact sequence, but the sdl app and the android app were within a few weeks of each other 10.59.28 # <[Saint]> I thought it was more a factor of months? 10.59.30 # <[Saint]> Hmmm. 11.00.41 # <[Saint]> There is of course the high possibility I'm misremembering the timeframe, but I'm fairly confident the SDL app was the first of the two. 11.02.08 # 31b5c471 Tue Jul 6 15:11:56 2010 +0000 Rockbox as an application: Add an 320x240 SDL application target. 11.02.11 # 240923a8 Mon Aug 2 20:34:47 2010 +0000 Rockbox as an application: Commit current Android port progress 11.02.24 # Of course neither of them was fully finished at those times 11.02.32 # Still, four weeks is hardly ages 11.07.41 Join hannes3 [0] (~hannes3@port-92-196-38-215.dynamic.qsc.de) 11.07.56 # hey, i just saw "2014-09-28: Improved battery life on the Clip v2, Clip+, Clip Zip and Fuze v2" at http://www.rockbox.org/wiki/MajorChanges 11.08.05 # where i can find some more info, ilke benchmarks? 11.12.31 # [Saint]: that was 2g, not 1g 11.13.30 # <[Saint]> Sorry, yeah, I was needlessly vague. I meant the 1st generation 2G IPT. 11.13.47 # <[Saint]> Which are more permissive. 11.14.51 # <[Saint]> hannes3: no benchmarks, just a measured reduction of several mA combined. 11.15.02 # ah nice 11.15.30 # <[Saint]> g#988 and g#989 11.15.35 # 3Gerrit review #988 at http://gerrit.rockbox.org/r/988 : 3Make sure the USB PHY is disabled after use. Patch by Mihail Zenkov who has by Mihail Zenkov 11.15.35 # 3Gerrit review #989 at http://gerrit.rockbox.org/r/989 : 3Don't enable the current sink for the Clip Zip backlight until its actually needed. by Mihail Zenkov 11.16.14 # time to update then :) 11.17.17 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) 11.17.52 # <[Saint]> see: http://forums.rockbox.org/index.php/topic,48549 11.17.55 # <[Saint]> hannes3: ^ 11.21.01 # impressive 11.22.09 Quit pamaury_ (Ping timeout: 272 seconds) 11.24.24 Join varogami [0] (~varogami@dynamic-adsl-94-34-4-47.clienti.tiscali.it) 11.25.10 Join edhelas [0] (~edhelas@193.172.124.224) 11.32.14 Quit jhMikeS (Ping timeout: 246 seconds) 11.34.22 Quit ploco (Quit: Page closed) 11.34.56 *** Saving seen data "./dancer.seen" 11.42.56 # huh, init sequence in atj binary is vastly different to this found in object file of LCM driver. Now select one :{ 11.59.23 # <[Saint]> Ugh. 11.59.59 # <[Saint]> Having a discussion with someone about how LibreSSL is the future and not at all a demonstarbly insane kneejerk reaction 12.00.10 # <[Saint]> Argh. WHoops, wrong channel. 12.02.04 Quit xorly (Ping timeout: 272 seconds) 12.05.08 # hmm, maybe not 12.05.20 # or there are a few different sequences 12.25.21 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 12.34.46 Quit foolsh (Ping timeout: 245 seconds) 12.35.33 Join foolsh [0] (~bbrown@c-67-174-138-234.hsd1.in.comcast.net) 12.40.57 Part hannes3 ("Leaving") 12.42.19 Quit foolsh (Ping timeout: 260 seconds) 12.42.39 Join foolsh [0] (~bbrown@c-67-174-138-234.hsd1.in.comcast.net) 12.49.02 Join nk2032 [0] (~nick001@ANantes-652-1-269-113.w2-8.abo.wanadoo.fr) 12.52.43 Quit Catelite` (Ping timeout: 272 seconds) 13.14.06 Join kugel_ [0] (~kugel@avm-guido.avm.de) 13.14.07 Quit kugel_ (Changing host) 13.14.07 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 13.16.56 Quit kugel (Ping timeout: 245 seconds) 13.25.31 Quit [Saint] (Read error: Connection reset by peer) 13.26.27 Join [Saint] [0] (~saint@rockbox/staff/saint) 13.30.22 Quit shamus (Ping timeout: 260 seconds) 13.31.33 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 13.33.09 Join cheese [0] (5ec7ebc6@gateway/web/freenode/ip.94.199.235.198) 13.33.27 Join mg_ [0] (martigam@cassarossa.samfundet.no) 13.33.40 Part cheese 13.34.57 *** Saving seen data "./dancer.seen" 13.35.50 # Hello! I have a sd clip with rockbox on it, and my laptop sound output has died (the 3.5mm jack is physically broken). Is there any way to use the clip as a USB dac? Either with rockbox or something else? 13.36.01 # Or if this is not implemented, is it technically possible? 13.37.24 # It's technically possible, and there's an old proof-of-concept implementation for e200v1, but it's going to be quite a bit of work to (a) update that proof of concept, and (b) make it work on the USB controller in the clip 13.38.49 # gevaerts: e200v1 is another sansa device? 13.39.01 # It is, but it's based on a different chipset 13.39.05 # (sorry for the stupid questions, but I'm totally new to the project) 13.39.09 # I see 13.39.36 # gevaerts: so is it a stand alone firmware or a plugin to rockbox or something like that? 13.42.04 # gevaerts: and can you point me to the code? I might be interested at having a go at this as a project (: 13.44.13 # https://github.com/pamaury/rockbox/tree/usb-api has the code 13.44.41 # It's plain rockbox except the USB code has been reworked to add audio 13.45.26 # pamaury might still remember bits :) 13.45.48 # usb audio ? 13.46.49 # Yes :) 13.46.52 # the tree is quite outdate the most of the code is straightforward, the tricky part is to make isochronous transfer work 13.47.13 # this tree also rework the usb api, not sure if that's really necessary on second thought 13.47.29 # but isochronous transfer cannot really be handled the same as bulk and interrupt though 13.48.32 # so rockbox has no support for isochronous USB atm 13.48.55 # no 13.49.31 # And what is needed for something to work as a USB DAC? I presume you have to adhere to some spec? 13.49.38 # if ypu want to implement it, the main issue you'll probably face is that controllers probably handle it in very different ways, and some don't handle them at all 13.49.50 # yes, USB Audio class 13.49.58 # there are two versions, the code on github works for v1 13.50.04 # https://github.com/pamaury/rockbox/blob/usb-api/firmware/usbstack/usb_audio.c 13.50.31 # pamaury: you mean the usb controller on the device? 13.50.37 # yes 13.51.25 # the crucial thing to keep in mind is that at High Speed, there are 10 micro-transfers per frame, that's over 1000 iso transfers/second, you cannot realistically fire an interrupt each time 13.51.50 # I see 13.52.14 # so on the ARC controller (the one used by e200v1, fuze+, and many others), each interrupt might need to process several packets, and similarly you need to setup transfers for several packets at once and not just one 13.53.09 # I think I have to use some time to familiarize my self with the project structure and hardware! 13.53.59 # But thanks for your input, I'll see what I can figure out and ping you with questions :p 13.55.29 # yeah don't hesitate, I think USB DAC for rockbox would be great, it's just a shame a never took time to merge this 13.56.45 # Yeah, it seems like it could be a cool feature 13.57.32 Quit Provel (Ping timeout: 260 seconds) 13.58.13 Join Provel [0] (Provel@75-132-30-64.dhcp.stls.mo.charter.com) 13.59.52 Quit cmhobbs (Ping timeout: 260 seconds) 14.04.28 # pamaury: any ETA for e100? 14.04.47 # I would say end of the week, not before :( 14.05.16 # since I'm buying from someone, it depends on how he needs to process the check and send me the device 14.05.21 # *how long 14.05.45 # checks can take stupidly long to clear 14.06.30 # with enough time to go around the world a couple of times 14.06.55 # pamaury: I made interesting discovery today about OF. I think I found out the place where lcm is initialized. Maybe I get lcd working then which will increase on-device debugging capabilities. 14.07.00 Quit kugel_ (Quit: leaving) 14.07.17 # good news :) 14.16.45 Join Jinx [0] (Dojo@unaffiliated/jinx) 14.16.52 Join kugel [0] (~kugel@ewnw-dhcp35.avm.de) 14.16.52 Quit kugel (Changing host) 14.16.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.21.23 Quit edhelas (Ping timeout: 272 seconds) 14.49.16 Quit Strife89 (Ping timeout: 272 seconds) 15.00.23 Join Strife89 [0] (~Strife89@adsl-98-80-238-113.mcn.bellsouth.net) 15.12.42 Quit wodz (Quit: Leaving) 15.18.32 Quit Strife89 (Ping timeout: 258 seconds) 15.31.57 Join Strife89 [0] (~Strife89@adsl-98-80-220-8.mcn.bellsouth.net) 15.34.09 Join chrisb [0] (~chrisb@pool-71-175-243-4.phlapa.east.verizon.net) 15.35.00 *** Saving seen data "./dancer.seen" 15.37.51 Quit krnlyng (Ping timeout: 260 seconds) 15.42.30 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.42.46 Join krnlyng [0] (~liar@83.175.90.24) 15.47.39 Quit WakiMiko (Remote host closed the connection) 15.47.54 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 15.57.32 Quit pamaury (Remote host closed the connection) 16.03.51 Quit foolsh (Remote host closed the connection) 16.09.46 Quit kugel (Ping timeout: 246 seconds) 16.12.34 Join krabador [0] (~krabador@unaffiliated/krabador) 16.22.10 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 16.22.23 Join ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net) 16.25.46 Join advcomp2019__ [0] (~advcomp20@65-131-187-162.sxct.qwest.net) 16.25.46 Quit advcomp2019__ (Changing host) 16.25.46 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 16.29.34 Quit advcomp2019_ (Ping timeout: 260 seconds) 16.55.18 Join trampel [0] (~trampel@c-24-22-235-214.hsd1.wa.comcast.net) 17.00.19 Join foolsh [0] (~bbrown@c-67-174-138-234.hsd1.in.comcast.net) 17.31.34 Join einhirn [0] (~Miranda@p5B0C4240.dip0.t-ipconnect.de) 17.35.03 *** Saving seen data "./dancer.seen" 17.37.27 Quit ikeboy (Quit: Leaving) 17.38.48 Quit petur (Quit: Page closed) 17.46.03 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.46.08 Join AlexP [0] (~alex@rockbox/staff/AlexP) 18.06.52 # Is the git hosting down? http://pastebin.com/xauY3nS2 18.10.41 # and is there some guide to the general structure of the project/code somewhere? 18.29.02 Quit mortalis (Ping timeout: 272 seconds) 18.30.44 Quit trampel (Quit: Leaving) 18.37.35 # Apparently there is some silliness going on use "git clone http://gerrit.rockbox.org/p/rockbox" 19.06.08 Quit Strife89 (Ping timeout: 250 seconds) 19.17.15 Join Catelite [0] (~Deluge@Powder/Staff/Catelite) 19.17.42 Quit foolsh (Remote host closed the connection) 19.19.25 Join Strife89 [0] (~Strife89@adsl-98-80-233-69.mcn.bellsouth.net) 19.31.47 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.35.05 *** Saving seen data "./dancer.seen" 19.40.54 Quit krabador (Ping timeout: 260 seconds) 19.45.10 Join n17ikh [0] (~n17ikh@unaffiliated/n17ikh) 19.49.18 Join krabador [0] (~krabador@unaffiliated/krabador) 20.03.48 Quit chrisb (Ping timeout: 272 seconds) 20.14.21 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 20.17.21 Quit fs-bluebot (Ping timeout: 240 seconds) 20.17.21 Quit bluebrother^ (Ping timeout: 240 seconds) 20.23.48 Join xorly [0] (~xorly@m180.dkm.cz) 20.23.51 Join fs-bluebot [0] (~fs-bluebo@g231123203.adsl.alicedsl.de) 20.27.10 Join jhMikeS [0] (~jethead71@c-68-43-2-35.hsd1.mi.comcast.net) 20.27.10 Quit jhMikeS (Changing host) 20.27.10 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 20.31.56 Quit bertrik (Ping timeout: 245 seconds) 20.32.05 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 20.55.09 Join petur [0] (~petur@rockbox/developer/petur) 21.16.06 Join ivanf [0] (~ivan@unaffiliated/kferdous) 21.16.24 # Anyone use their clip+ with ext cs card to play in the car? 21.16.37 # For some reason my ext sd card files do not show up 21.16.56 # ext cs? 21.17.01 # You mean the car thing doesn't see it, or rockbox doesn't? 21.17.34 # sd card* sorry 21.17.41 # car. 21.17.53 # how is the car relevent? 21.17.57 # I can play whats in on the clip+ but not the in the sd car 21.18.00 # Right. That's a fairly common issue 21.18.02 # relevant* 21.18.06 # Oh I see 21.18.11 # sd car? 21.18.25 # Many car systems seem not to handle USB devices with more than one "disk" 21.18.41 # is he actually talking about automobiles? 21.18.44 # There's a setting in rockbox to work around this. Let me find out where it is 21.18.45 # Oh that sucks. Because it's 50/50 for me. 21.19.00 # 50% I listen in the car the other 50% via iem 21.19.06 # Thank you gevaerts 21.19.19 # how do you play music in your car? 21.19.35 # Using the USB cable connected to the clip+ 21.19.47 # ivanf: Settings->General Settings->System->USB Hide Internal Drive 21.20.12 # oh 21.20.21 # If you enable that, you won't be able to access the internal storage over USB, so remember to disable it again when connecting to a normal computer 21.20.25 # But both cannot be used at once? 21.20.32 # I see 21.20.48 Join chrisb [0] (~chrisb@pool-71-175-243-4.phlapa.east.verizon.net) 21.20.59 # gevaerts: would be great to enable it on the fly with a keypress combination while plugging it in 21.21.47 # erm that's already used for disabling USB mounting 21.22.07 # ivanf: there's not much else we can do. Those systems only see one device... 21.22.09 # shortcut maybe? 21.22.29 # gevaerts thank you anyway. 21.22.52 # I mean I am getting a 64gb sd card for the clip+.. guess this will be a bit annoying 21.23.24 # With a 64GB card, the internal storage starts becoming small enough to ignore :) 21.23.35 # yeah 21.25.06 # copper: the problem with buttons when plugging in is that there aren't any buttons that are guaranteed to be harmless apart from the menu one (and even that is a bit annoying)... 21.25.31 # But yes, a shortcut might work, or you could put that setting on the quickscreen 21.26.05 # Thank you 21.27.55 # We could conceivably fake one big disk with several partitions (although that's going to be tricky to get right in all cases), but I bet those things won't handle multiple partitions anyway... 21.35.06 *** Saving seen data "./dancer.seen" 21.54.01 Quit chrisb (Ping timeout: 245 seconds) 21.59.07 Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) 22.18.49 Quit babylonlurker (Quit: No Ping reply in 180 seconds.) 22.18.56 Join babylonlurker [0] (~quassel@veda.xs4all.nl) 22.30.41 Join Pierluigi [0] (~quassel@host-84-13-171-182.opaltelecom.net) 22.31.04 # hello people 22.32.02 # is there anyone out there with a good knowledge of pluginlib actions? 22.47.06 Quit xorly (Ping timeout: 260 seconds) 22.48.30 Join wodz [0] (~wodz@89-75-106-114.dynamic.chello.pl) 22.49.00 # Pierluigi: Ask specific question if you have one 22.58.11 # ok, so here is the thing: just tried to use PLA with no luck 22.58.35 # had a look at other plugins and used this line: 22.58.50 # "currentKey = pluginlib_getaction(TIMEOUT_NOBLOCK, plugin_contexts, ARRAYLEN(plugin_contexts));" 22.59.16 # it looks like "currentKey" is always 0 22.59.43 # tried to debug it on SIM and If I press like crazy sometimes I get values other than 0 23.00.01 # and then I got suspicious: doom and pacman don't use it... 23.00.31 # I wonder if it's because of what the intended usage of that function is 23.01.05 # maybe it can be used only on plugins with non intensive cpu usage? 23.01.38 # so first of all, what is its intended usage? 23.03.04 # considering that I have a very busy main loop that cannot be delayed much (due to both graphics and sound mixing happening), can PLA cope with that? 23.03.22 # I'd expect it to make sense to block waiting for some key event 23.03.25 # grr 23.03.49 # basically I cannot block for too long and wait for event press 23.04.09 # otherwise sound would stutter (depending on specific target) 23.04.29 Quit nk2032 () 23.04.59 # how did you handled input before? 23.05.24 # so I was using pluginlib_getaction() basically as a button_status() 23.05.31 # via button_status() 23.05.54 # and checking for a button change only when I could 23.06.54 # also, it looks like pluginlib_getaction() does a lot of things which could slow my engine down and I don't necessarily need 23.07.48 # but for now just focusing on its usage anyway 23.07.49 Quit amayer (Quit: Leaving) 23.08.02 # ok, use button_status() then 23.08.27 # sure, but then specific keymaps will have to be added for each target 23.08.35 # its just that defining keymaps is really a pain 23.08.44 # I know and I totally understand it 23.08.59 # I'm happy to change code to use PLA, but I can't really figure how 23.09.52 # and just wanted to double check I didn't miss anything obvious 23.10.21 # and to be fair... I think some specific keymaps will have to be added regardless 23.11.31 # because for example IriverH320 has no diagonals and I have to map both arrows and some buttons to game actions in order to let people move diagonally 23.12.37 # I mean 2 buttons doing the same thing so I can detect two keypress at once and still allow people to play naturally 23.12.56 # anyway, any advice on this PLA issue? 23.13.35 # sorry to say but I am not expert in this area 23.16.13 Quit Pierluigi (Read error: Connection reset by peer) 23.17.26 Join Pierluigi [0] (~quassel@host-84-13-171-182.opaltelecom.net) 23.28.27 Quit lebellium (Quit: ChatZilla 0.9.91 [Firefox 33.0/20141002185629]) 23.31.20 Quit chkktri (Ping timeout: 250 seconds) 23.34.43 Join chkktri [0] (~chkktri@unaffiliated/chkktri) 23.35.09 *** Saving seen data "./dancer.seen" 23.41.03 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 23.48.45 Quit wodz (Quit: Leaving) 23.49.36 Quit krabador (Quit: Sto andando via) 23.51.03 Join krabador [0] (~krabador@unaffiliated/krabador) 23.58.09 # mg_: what a coincidence, I also came here yesterday asking the same thing :) 23.58.29 # pamaury: so do you think it' better to start from your branch or try to start from scratch off the current master? 23.58.53 # yuriks: probably better to start from scratch