--- Log for 11.09.114 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 12 days and 11 hours ago 00.00.01 # <[Saint]> TheSeven: debian 00.00.16 Quit [Franklin] (Ping timeout: 245 seconds) 00.00.49 # I didn't use all that many graphics. I guess I should have made CabbieV2 as simple as that :D 00.01.01 # <[Saint]> Hmmmm. Odd. I did keep some local changes in my tree that shouldn't affect this _at all_, but I'll pull in the patch set in an absolutely clean tree and try again. 00.01.12 # <[Saint]> Its quite possible I ballsed something up merging. 00.01.29 Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 00.01.37 # <[Saint]> ZincAlloy: are you using a backdrop? It looks to me like you could very easily not. 00.01.45 # dozens of different icon states on a gradient backdrop are a porting nightmare 00.01.59 # <[Saint]> uuuuuuuugh. 00.02.00 # <[Saint]> yes. 00.02.08 # <[Saint]> I hated you for that backdrop for so long... 00.02.11 # <[Saint]> ;)) 00.02.21 # I hated myself for that backdrop 00.02.35 # but it did look nice.. 00.02.35 # <[Saint]> It looks great. But the issue you outlined. 00.02.38 # <[Saint]> Yes. Very yes. 00.03.05 # Except on Clip Zip. That screen makes everything look ugly. 00.03.33 # <[Saint]> Only other thing I would suggest is using a UI viewport so the menu text isn't hard up against the screen edge. 00.03.35 # and yes, I'm using a backdrop for rockdroid 00.03.43 # it makes everything so much more convenient 00.03.54 # <[Saint]> right, there's a metric shittonne of savings available if you get creative. 00.03.57 # I am using a UI viewport... 00.04.28 # <[Saint]> Huh...odd. Then why is the menu text hard up against the left edge? Looks kinda weird. 00.05.11 # you're right. I should move it a little so taht it line up with the clock 00.06.30 # <[Saint]> It makes a scrollbar a _lot_ easier to use if its enabled by the user as well. 00.06.45 # <[Saint]> touchscreen edge detection on some screens is kinda flakey. 00.07.00 # speaking of scrollbars: are they themeable? 00.07.14 # <[Saint]> Not trivially. 00.07.21 # bummer. 00.07.56 # <[Saint]> IIUC, to do that, you need to reimplement the lists with that weird slightly unfinished skinned lists stuff. 00.08.14 # <[Saint]> IIUC, gevaerts is the only one to ever successfully master that. 00.08.15 # sounds like a nightmare 00.08.19 # <[Saint]> It is. 00.08.48 # not gonna bother then. custom scroll bar would be nice, but I can live without one 00.09.03 Quit amayer (Quit: Leaving) 00.09.28 # <[Franklin]> just color change ought to be trivial 00.09.47 # it needs more than a color change 00.09.53 # <[Saint]> You'd think so, but, no. It isn't. 00.09.59 # <[Franklin]> really? 00.10.06 # <[Saint]> It uses the global foreground/background colors. 00.10.12 # <[Franklin]> just find the scrollbar code and change the... oh 00.10.15 # <[Franklin]> :) 00.10.24 # <[Saint]> Themeing, unless you've actually been there, is extrememly non-obvious. 00.10.43 # * [Franklin] doesn't want to even touch the theming language 00.11.15 # <[Franklin]> It looks like regex written by a drunk cat on a keyboard. 00.11.36 # <[Saint]> Yes. He's a good friend of mine. That amused me greatly. 00.11.53 # <[Saint]> That was said after I accidentally dropped a pastebuffer full of theme in #raspberrypi 00.11.58 # <[Franklin]> LOL 00.16.48 # <[Saint]> ZincAlloy: this may interest you, please excuse the lack of pastebin: 00.16.49 # <[Saint]> # /* Set and check for a PLAY_STATE variable to allow us to always display the 00.16.49 # <[Saint]> # * correct PAUSE/PLAY state icon when seeking. */ 00.16.50 # <[Saint]> %?mp<%xd(STOP)|%xd(PAUSE)%vs(PLAY_STATE,set,1)|%?Sr<%xd(PLAY,2)|%xd(PLAY,1)>%vs(PLAY_STATE,set,2)|%?vg(PLAY_STATE)<%xd(PAUSE)|%?Sr<%xd(PLAY,2)|%xd(PLAY,1)>>|%?vg(PLAY_STATE)<%xd(PAUSE)|%?Sr<%xd(PLAY,2)|%xd(PLAY,1)>>> 00.17.00 # <[Franklin]> gevaerts! 00.17.05 # <[Saint]> This fixes a very real problem with play state icons and seeking. 00.17.22 # <[Saint]> ZincAlloy: may I also suggest making "stop" long press on play/pause? 00.17.49 # that's a good idea! 00.17.56 # <[Saint]> ZincAlloy: if you're not sure what's going on in the code snippet, gimme a yell, but if I know you well enough that should be within your grasp. 00.18.16 # <[Saint]> Its saving a state variable to check what icon we _should_ display when seeking. 00.18.31 # <[Saint]> otherwise if you seek, you'll get no playback state icon. 00.18.36 # <[Saint]> which sucks a giant fuck. 00.19.31 # actually the play state doesn't bother me much. I did notice it, though. 00.19.49 # <[Saint]> It bothered the fuck out of me for _years_. 00.20.02 # <[Saint]> Until one day, I shit you not, I /dreamed/ that code snippet up. 00.20.08 # <[Franklin]> WHAT!?!? 00.20.12 # <[Saint]> Then I promptly awoke myself at 5am and started writing. 00.20.19 # <[Franklin]> LOL 00.20.29 # <[Saint]> code-dreaming, yo. I'm sure we've all done it. 00.20.43 # <[Franklin]> not herew 00.20.46 # <[Franklin]> *here* 00.21.37 # [Franklin]: It will happen if you keep programming, I dream about math 00.21.42 # isn't it just a workaround bug that needs fixing? or am I missing something? 00.21.52 # <[Franklin]> well it has... but nothing like that cat regex :) 00.21.53 # <[Saint]> getting offtopic, but I keep my phone right next to me so that if I wake up in the middle of the night with wild inspiration I can actually document it instead of just falling asleep again. 00.22.13 # <[Saint]> ZincAlloy: its technically behaving exactly as expected. 00.22.27 # <[Franklin]> how is this offtopic? it'll be of massive use to every theme "expert" after you 00.22.29 # <[Saint]> While you're seeking, it makes perfect sense for the play state icon not to show. 00.22.33 # <[Saint]> ...because you're seeking. 00.22.47 # <[Saint]> and not in playback/stopped/paused. 00.22.49 # it's true... 00.22.53 # <[Saint]> So we need to remember this state. 00.22.56 # * [Franklin] suggests that you have fastforward/rewind icons for play state 00.23.04 # <[Franklin]> *humbly* 00.23.05 # <[Saint]> We can only do this on touch targets, though. 00.23.24 # <[Saint]> [Franklin]: that just leads to an info double-up. 00.23.34 # <[Franklin]> a what? 00.23.42 # <[Saint]> the NEXT/PREV icons should change to FF?RW when long pressed. 00.23.49 # <[Saint]> *FF/RW 00.23.58 # <[Saint]> No need to show it twice. 00.23.59 # they should. 00.24.01 # but 00.24.07 # <[Saint]> ...yours dont? 00.24.07 # <[Franklin]> yep 00.24.12 # when you're pressing them you can't see them 00.24.27 # <[Saint]> right, but you know what you're doing. 00.24.34 # at least not the one you're pressing 00.24.38 # <[Saint]> and you've got the progressbar for a visual indicator. 00.24.54 # which you could use for scrolling as well 00.25.07 # <[Franklin]> so when you press, the play state is a FF/RW icon 00.25.29 # I guess everyone will expect long presses on prev/next to be used for ffwding/rewinding 00.25.41 # <[Saint]> its kinda a universal thing. 00.25.46 # yeah 00.25.47 # <[Saint]> with touch UIs, anyway. 00.26.05 Join Riviera [0] (Riviera@2a03:b0c0:1:d0::10:b001) 00.26.17 # it's exactly like players with buttons would behave 00.26.22 # <[Saint]> I hope this criticism comes across in the positive fashion that I intend it to. 00.26.38 # <[Saint]> I'm not so good with...people stuff. Y'know. 00.26.53 # oh, I don't see it as criticism 00.27.00 # it's interesting input 00.27.08 # <[Saint]> *phew* 00.27.13 # <[Saint]> :)) 00.27.40 # but the issue doesn't bother me at all 00.27.52 # quite unlike the cover art issue :D 00.28.03 Quit ender` (Quit: First things first, but not necessarily in that order.) 00.28.40 # I might have to make another version of the sbs with buttons on the bottom 00.29.05 # <[Saint]> Yeah, I think we should be doing something like buffer=(worst case fullscreen ARGB bitmap)*4 or so. 00.29.15 # I don't really click the tiny cover art to go back to the wps intuitively 00.29.34 # that should be plenty. 00.29.52 # unless you go crazy with fonts I guess 00.30.28 # <[Saint]> That would result in a much smaller buffer on the lowres targets, if I'm not mistaken. 00.30.39 # someone will hate you for that :D 00.30.40 # <[Saint]> 8MB of a 240x320 target seems a bit extreme. 00.30.48 # <[Saint]> *for a 00.30.51 # yeah 00.31.23 # when people are having issues with it you could still change it 00.31.39 # but that doesn't seem all that likely 00.32.20 # <[Saint]> In all honesty, I don't think anyone saw this coming. 00.32.38 # <[Saint]> When RaaAoA was born, 480x800 was a very extreme resolution. 00.32.49 # <[Saint]> Now its considered laughable small. 00.33.05 # yeah, things are changing rapidly 00.33.45 # <[Saint]> Wait til we get "RaaAoA doesn't work on my Moto360's round display" 00.33.45 # funny that you didn't run into this issue before 00.34.16 # <[Saint]> I've generally been fairly conservative with my themes. 00.34.17 # oh yeah. round jpgs. far out 00.34.40 # well.. this rockdroid is me being conservative and lazy at the same time 00.34.44 # <[Saint]> The themes where I have gone really extreme, the targets had ~60MB of buffer to play with. 00.35.15 # <[Saint]> But on a hosted target, we can't just suck up all the remaining RAM for buffer. 00.35.39 Quit bertrik (Remote host closed the connection) 00.35.43 # at least we shouldn't 00.35.49 # <[Saint]> Well, we could, but I suspect the host would kill it off frequently. 00.35.52 # <[Saint]> ;) 00.35.56 # but I guess the ones with huge screens should have plenty of ram 00.36.16 # no? 00.36.33 # <[Saint]> Indeed. 00.37.05 # <[Saint]> I'm hesitant to make such a sweeping change to the buffer allocation without making it resolution dependent, though. 00.37.20 # wow. I only used six bitmaps for rockdroid. Now that's efficient 00.37.29 # <[Saint]> Allocating ~32MB for a 1024x1280 target is perfectly reasonable. 00.37.35 # right 00.37.38 # <[Saint]> But, on a 240x320 target, its insane. 00.38.10 # resolution dependent buffers is exactly what is needed then 00.38.11 # <[Saint]> Targets at that resolution are likely to have less than 512MB available for the entire system. 00.38.52 # <[Saint]> And Android itself is going to want about two thirds of that. 00.39.01 # my bitmaps for the wps are only 3.2mb 00.39.29 # another 2.8 for the menu backdrop 00.39.43 # <[Saint]> all mine are 900kB 00.39.50 # <[Saint]> (total) 00.40.01 # you're too efficient 00.40.12 # <[Saint]> Never had anyone say that before. ;) 00.40.16 # :D 00.41.21 # or maybe not. being that efficient is more work 00.42.09 # anyway, backdrops plus large album art are to be expected 00.42.20 # <[Saint]> Indeed. 00.47.59 Join xorly [0] (~xorly@210.213.broadband13.iol.cz) 00.50.45 # I've changed the UI viewport and added a stop function to the play/pause button as per your suggestions 00.51.02 # thanks a lot for your help. I highly appreciate it 00.53.10 # <[Franklin]> one word: kickstarter 00.53.36 # <[Franklin]> start a campaign for a "bounty fund" for all the features that no one wants to write 00.53.48 # <[Franklin]> number one: those stupid icons 00.54.18 # <[Saint]> That would be a breach of kickstarter's protocols. 00.54.27 # <[Saint]> You need to display a functional prototype. 00.54.33 # <[Franklin]> we have that 00.54.37 # <[Franklin]> http://download.rockbox.org 00.54.40 # <[Franklin]> click any link 00.54.41 # <[Saint]> You can't have a functional prototype of a suggestion no one has given you. 00.54.55 # <[Franklin]> true... 00.54.58 # <[Saint]> you would be selling _nothing_. 00.55.16 # <[Franklin]> any other crowdfunding sites 00.55.19 # <[Saint]> That hasn't stopped people abusing KS in the past, though... 00.55.35 # <[Franklin]> indiegogo 00.55.54 # <[Saint]> I really don't think there's a market for this. 00.56.06 # <[Saint]> If people want to pay for additions, they go to the forum. 00.56.25 # <[Franklin]> there's no real escrow to make sure they pay 00.56.56 # <[Saint]> 99.99% of the populous is going to have no fucking idea what Rockbox is, let alone have suggestions for a feature to add (and pay for it) to the software they don't know about. 00.59.53 # Dude, cheese cake 01.00.56 Quit xorly (Ping timeout: 272 seconds) 01.01.11 # cheese cake would be an awesome kickstarter project 01.02.52 *** Saving seen data "./dancer.seen" 01.04.39 # <[Franklin]> [Saint]: indiegogo doesn't have any requirements that could disqualify rockbox 01.05.05 # <[Saint]> That still doesn't change the other glaring issue, it being a terrible idea. 01.05.12 # <[Saint]> Virtually no one knows we exist. 01.05.20 # <[Franklin]> we could get famous 01.05.28 # <[Saint]> So they're not going to have an opinion on adding features to the OS they don't know exists. 01.05.55 # would they "get" rockbox at all? 01.06.48 # <[Saint]> I sincerely doubt it. 01.07.12 # <[Franklin]> why not try? 01.07.13 # <[Saint]> Why use when already offers . 01.07.27 # <[Franklin]> we get 91% if we don't reach the goal 01.07.57 # <[Saint]> [Franklin]: Rockbox has _never_ been about widespread adoption or monotization, and I hope in my time, it never will be. 01.08.08 # <[Saint]> This would be turning it into something its not. 01.08.11 # <[Saint]> Something ugly. 01.08.22 # <[Saint]> *monetization 01.08.24 # <[Franklin]> yeah 01.08.49 # <[Franklin]> hmm... true 01.09.02 # <[Franklin]> just like linux :) 01.09.14 # <[Franklin]> though they do try 01.15.23 # a crowdfunded rockbox player could be nice, though 01.17.43 # <[Saint]> Its just not going to happen. 01.18.20 # <[Franklin]> There is beginning to be a void in the DAP market with apple leaving 01.18.26 # <[Saint]> No one is going to pay the amount we'd need to get the hardware off the ground when there are companies that have been doing this for a long time, are established, and can produce a higher quality build for less. 01.18.36 # <[Saint]> We couldn't even afford to get the SoCs we'd need. 01.18.51 # * [Franklin] wonders if SanDisk could fill that void 01.19.17 # <[Franklin]> the top-of-the-line DAP market 01.19.24 # a cooperation with sandisk would be great 01.19.31 # <[Franklin]> not the cheap, plasticky, DAP market 01.19.37 # <[Franklin]> they already dominate there 01.19.39 # <[Saint]> "Lyre" is a great idea, and it has philosophical merit, and good intentions. 01.19.40 # a lot of people buy their players to use them with rockbox already 01.19.50 # <[Franklin]> ZincAlloy, why not try it? 01.19.52 # <[Saint]> In practice, though, its going to fall on its ass _every_ time. 01.19.55 # <[Saint]> Due to cost. 01.20.06 # <[Franklin]> here comes kickstarter :) 01.20.08 # <[Saint]> We just couldn't afford to fab a decent quality player. 01.20.10 # it might be interesting for sandisk 01.20.19 # that would get them press 01.20.26 # * [Franklin] spams the sandisk live support 01.20.53 # <[Franklin]> yes, true 01.21.00 # <[Franklin]> we design, have them fab it 01.21.25 # deliver it with a dumbed down version of rockbox that won't overwhelm the average user 01.21.40 # <[Franklin]> Rockbox is fine the way it is 01.21.49 # <[Franklin]> no command prompt yet 01.21.50 # <[Saint]> No. No it is not. 01.21.51 # for you and me, yes 01.22.02 # <[Saint]> It is in no way ready for the consumer market. 01.22.05 # <[Franklin]> what's hard about it? 01.22.08 # <[Saint]> No way. No how. 01.22.17 # <[Franklin]> installation? no... manual! 01.22.20 # there are too many options 01.22.34 # * [Franklin] figured out what they meant his first time using Rockbox 01.22.42 # <[Saint]> Labyrinthine menus and options that Joe User won't know, understand, or comprehend. 01.23.00 # should be an easy fix 01.23.06 # <[Franklin]> then "if it ain't broke, don't mess with it" 01.23.21 # <[Franklin]> ZincAlloy, I think that would alienate a large portion of the devs 01.23.29 # Oh god no, just fork it and fuck off with the window-ized version of rockbox, I like it the way it is now 01.23.31 # <[Saint]> ZincAlloy: Every time we've tried to change the main menu ordering, it turns into a massive clusterfuck. 01.23.48 # <[Franklin]> "NO CONFIGURABLE SPINDOWN!?!?"... 01.23.49 # <[Saint]> I have never deeply regretted championing an idea in a FOSS community so badly. 01.23.55 # it would just be a branch 01.24.08 # <[Franklin]> and how to switch? 01.24.14 # <[Saint]> About two years ago I tried to get behind a serious push to reorder the main menu. 01.24.18 # <[Franklin]> "Dumbed-down mode"? 01.24.31 # <[Saint]> And, I repeat, I have never regretted a decision in a FOSS community so badly before, or since. 01.24.36 # <[Franklin]> [Saint], what did you want it to be? 01.24.45 # just install a non dumbed down build 01.25.00 # <[Franklin]> and then devs will have to maintain both branches?! 01.25.10 # <[Franklin]> as if one wasn't enough 01.25.50 # I wouldn't go that far. just get one stable release and then forget about it 01.26.06 # <[Franklin]> ah... yes 01.26.11 # <[Franklin]> "Simple mode" 01.26.30 # <[Saint]> Reordering the main menu was a classic example of too many chefs spiling the broth. Too many hammers, and not enough nails, Insert other metaphor about relationship breakdowns here. Etc. 01.26.35 # a simple mode would make sense 01.26.48 # <[Franklin]> Just cut out about 90% of the settings options and get rid of the "incomplete" plugins, etc 01.27.02 # <[Franklin]> so no doom for ipod6g to avoid people saying "it don't work!" 01.27.03 # <[Saint]> At least one other person before me tried to seriously push for a main menu re-shuffle and failed miserably, too. 01.27.12 # <[Franklin]> how so? 01.27.13 # <[Saint]> It just disseminates into madness. 01.27.14 # You just gotta have a vision and be the steve jobs of rockbox, [Saint] 01.27.19 # <[Saint]> A giant cluserfuck of disagree,ent. 01.28.39 # hmmm, A design contest could keep things better organized and those who want to work on it could do so Independent of whats "going on in the kitchen" 01.28.52 # <[Saint]> You can certainly see in some places of the menu someone _tried_ to order it based on what they thought was likely to be used more often. 01.28.57 # * [Franklin] smells forks 01.29.13 # <[Saint]> But then you can also see lots of "ahhh, fuck it" and just tagging on new items to the ends of lists because its easier to do. 01.30.20 # <[Saint]> While you are certainly free to fork Rockbox, its also a fucking terrible idea, like most forks are. WHen you take on a fork of a large project, you also take on the support and maintenance of it alone. 01.30.48 # * [Franklin] didn't say he would fork it 01.30.52 # But can't the theme engine do most of the necessary heavy lifting for something like this already? 01.30.53 # <[Saint]> All for a fucking shitty reason like UI changes? 01.31.04 # <[Saint]> foolsh: not really, no. 01.31.08 # it's just an idea at this point. adding a dumb mode is another great idea 01.31.09 # Hmm, 01.31.36 # <[Saint]> Its possible in theory. 01.31.38 # <[Franklin]> yeah, I don't see a reason the average Joe would want a dev build 01.31.44 # <[Saint]> Fucking nightmarish in practice. 01.31.52 # <[Franklin]> maybe for next release, just make a dumb mode 01.32.17 # just put together a nice .cfg that will make the player work intuitively for most people, get rid off many options and let joe average be happy with it 01.32.18 # <[Franklin]> and don't think about it for a year or so 01.32.34 # wouldn't be all that hard to do, would it? 01.33.20 # <[Franklin]> so, for next release? 01.33.26 # <[Franklin]> so they get 2048 :) 01.33.53 # <[Saint]> We already do that already, basically. Rockbox is configured entirely sensibly and regularly accessed features are readily available. 01.34.09 # yeah. everything it needs is already there. 01.34.10 # <[Saint]> Joe Average just can't seem to comprehend not touching things they don't understand. 01.34.24 # <[Saint]> But, this isn't /for/ Joe Average. 01.34.25 # <[Franklin]> but then they set spindown to max... and then complain about the battery dying in 4 hours 01.34.32 # a dumb mode would just leave things away 01.34.52 # <[Franklin]> just like windows does when you try to access C:\winblows 01.34.58 # it hasn't been for joe average so far 01.35.03 # <[Saint]> I can't argue against it being a reasonable idea, but at the end of the day, they're not the target market. 01.35.16 # but it wouldn't be so hard to make it work for joe average 01.35.39 # <[Franklin]> no new features 01.35.43 # <[Franklin]> just taking some away 01.35.47 # the only feature is less options 01.35.51 # <[Franklin]> exactly 01.35.55 # <[Franklin]> "simple" mode or something 01.36.09 # yeah. calling it dumb mode would be bad marketing 01.36.13 # <[Franklin]> LOL 01.36.21 # <[Saint]> you could scatter ifdefs around and make it a compile time option *really* easily. 01.36.28 # <[Franklin]> yep 01.36.29 # <[Saint]> and the main menu is already configurable. 01.36.41 # <[Franklin]> #ifdef STEWPID_MODE...#endif 01.36.46 # <[Franklin]> :) 01.36.48 # <[Saint]> making it a dynamic option on the device would be rather a bit more complicated. 01.37.07 # <[Franklin]> no... compile time so Joe doesn't freak out about those extra options 01.37.47 # <[Franklin]> So, we need to know what it will be called 01.37.52 # <[Franklin]> Here's my ideas: 01.37.54 # <[Franklin]> "Simple mode" 01.37.57 # <[Franklin]> "Easy mode" 01.38.00 # <[Franklin]> "EZ mode" 01.38.05 # "rockbox for dummies" 01.38.11 # <[Franklin]> "Light mode" 01.38.12 # but calling it "Enhanced mode" would really pull in them in 01.38.18 # <[Franklin]> LOL 01.38.26 # Rockbox 3G 01.38.57 # <[Franklin]> No, Rockbox Lite will cause them to want to "upgrade" to rockbox full 01.39.13 # <[Franklin]> So something that makes it sound better than normal rockbox 01.39.22 # IU mode 01.39.22 # <[Franklin]> Enhanced then 01.39.33 # <[Franklin]> Rockbox XS 01.39.37 # Rockbox Advanced 01.39.40 # <[Franklin]> Xtra-stupid 01.39.50 # <[Franklin]> And say it stands for Xtra-simple 01.40.08 # Rockbox 2.0 01.40.11 # Rockbox - Enhanced - Edition 01.40.20 # <[Franklin]> 2.0?.... no 01.40.20 # <[Saint]> Pretty much nothing is going to work I don't think. CHanging Rockbox for the sake of fucktard users is a mistake I would think. 01.40.26 # <[Franklin]> there is a 2.0 already 01.40.53 # oh, right, we're on 3.13 01.41.03 # 2.0 just has a nice ring. it sounds so advanced 01.41.04 # <[Franklin]> Rockbox 2000 01.41.13 # 2000 is so 14 years ago 01.41.14 # <[Franklin]> THE Rockbox 2000 :) 01.41.22 # <[Franklin]> THE Rockbox 3000 then :) 01.41.49 # Rockbox The Experience 01.42.07 # lol that was aweful 01.42.08 # LOL 01.42.21 # Popbox 01.42.44 # <[Franklin]> I'm leaning towards Rockbox XS 01.42.47 # <[Franklin]> It needs an X 01.42.54 # XS sounds way too small 01.43.02 # <[Franklin]> XL 01.43.03 # make it Rockbox 3XL 01.43.07 # lol 01.43.13 # <[Franklin]> No... just X 01.43.20 # XBox 01.43.23 # <[Franklin]> X for Xtremely simple 01.43.24 # no, wait.. 01.43.29 # <[Franklin]> Rockbox Xtreem 01.43.31 # <[Franklin]> Rockbox Xtreme 01.43.35 # <[Franklin]> YES!!! 01.43.41 # <[Saint]> *ahem* 01.43.43 # like in Xtremely simple to use 01.43.52 # <[Franklin]> [Saint], sorry :) 01.44.01 # <[Franklin]> spamming up the logs again :O 01.44.13 # hey, we're being productive here 01.44.47 # <[Franklin]> OK, so here's the list: "Rockbox 4.0X" "Rockbox 3000" "Rockbox Simple" 01.45.06 # Rockbox X doesn't sound hip enough 01.45.16 # <[Franklin]> 4X 01.45.20 # <[Franklin]> For release 4.0 01.45.32 # <[Franklin]> Maybe an X version each *.0 release 01.45.46 # [Franklin]: Loves those exxes doesn't he? 01.45.57 # we need a completly unrelated name that expresses the characteristics of this simplified rockbox 01.46.13 # RXBX 01.46.48 # <[Franklin]> RBX 01.46.51 # <[Franklin]> Duh! 01.47.24 # Anyway it not going to happen unless you do it yourselves 01.47.58 # <[Franklin]> I will when next release comes out 01.48.11 # keep waiting 01.48.38 # How long has it been since 3.13? 01.48.41 # <[Franklin]> years 01.48.49 # right 01.49.09 # * [Franklin] thinks its long overdue 01.49.14 # <[Franklin]> so 4.0 it is 01.49.49 # Its an arbitrary thing to be honest, you could just pick a revision and go for it 01.50.23 # <[Franklin]> and no feature freeze? 01.50.47 # <[Franklin]> Major Changes list is huge 01.50.50 # <[Franklin]> so yeah, it's time 01.51.02 # <[Franklin]> About 20 vs 4 for 3.12-3.13 01.51.19 # <[Franklin]> Though 3.0 was massive 01.51.37 # <[Franklin]> what, like 20 new plugins 01.52.55 # <[Franklin]> so it's time 01.54.12 Quit foolsh (Quit: foolsh) 01.54.48 # <[Franklin]> [Saint]? 01.57.30 Join Aldem [0] (~Aldem@unaffiliated/aldem) 02.00.57 Quit ZincAlloy (Quit: Leaving.) 02.05.14 Join drvink [0] (mdl@katsu.triplehelix.org) 02.06.52 Quit [Franklin] (Quit: Leaving) 02.10.23 # hi, a while ago i had mentioned adding an option to disable disk spindown while connected to usb to rockbox. i added it for the ipod 6g: http://gerrit.rockbox.org/955 02.13.51 Quit jhMikeS (Ping timeout: 240 seconds) 02.25.03 # <[Saint]> Its unlikely to be accepted anyway, but its doubly unlikely to be accepted if it targets a single device for seemingly no reason at all other than personal preference. 02.25.22 # <[Saint]> However, I'm unsure if getting it accepted is an actual end goal you're considering or not. 02.25.46 # i would like to get it accepted so that i don't have to maintain my own fork of rockbox just for one feature 02.25.56 # so whatever needs to be done to it to get it accepted i am willing to do 02.26.40 # i just don't have the means to test it on other configs 02.26.42 # <[Saint]> Then it would need to target all devices that do HAVE_SPINDOWN (or whatever the define is, can't recall offhand), and have a manual entry. 02.27.47 # <[Saint]> The manual entry should also make it clear that in some instances the device very well may be actively discharging despite possibly claiming otherwise. 02.28.33 # gotcha 02.28.46 # is the define ALLOW_USB_SPINDOWN? 02.29.09 # <[Saint]> possibly. 02.29.47 # there also appears to be a DISK_SPINDOWN, but it's only referenced in some plugins 02.30.43 # <[Saint]> I think, though someone else might need to chime in here, that you'd also need to make it dependent on whether or not we differ to the OF for USB or not. Or do we use the OF by default for USB on all the SanDisk players now? 02.31.03 # <[Saint]> *defer 02.31.56 # <[Saint]> I'm not too knowledgeable on the current state of the SanDisk devices. 02.32.43 # <[Saint]> Oh, actually, derp. 02.32.53 # <[Saint]> They're all flash players anyway aren't they, heh. 02.32.58 # yeah 02.33.41 # <[Saint]> There might still be some targets I'm unaware of that we do use the OF for USb. 02.34.21 # <[Saint]> I don't have the 1st gen iPod, can't find my iPod 2G, or a functional iPod Mini/Mini2G. 02.34.39 # <[Saint]> *disk based targets 02.48.10 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 02.50.39 # g#956 02.50.43 # 3Gerrit review #956 at http://gerrit.rockbox.org/r/956 : 3increase memorysize for Android build. by Chiwen Chang 02.52.38 Quit bcobco () 02.53.15 # I think ask 11MB on 240x320 target is ok. 03.00.01 Quit AlexP (Remote host closed the connection) 03.01.52 Join AlexP [0] (~alex@rockbox/staff/AlexP) 03.02.55 *** Saving seen data "./dancer.seen" 03.08.43 Quit DIY-Noob (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) 03.11.24 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 03.14.51 # [Saint]: should i just wait for the review to see what else i ought to do? 03.18.49 # <[Saint]> ploco: that seems like a really weird way of doing it if you ask me. 03.20.01 # <[Saint]> when I looked to see how you were coming up with the numbers for each allocation, to say I was surprised, would be an understatement. 03.22.30 # it's from RCC. with a smaller base. initially the base was 16mb 03.27.18 # but I change it to any pattern, such as only increase size for targets more then 720p 03.28.52 # 16mb for 720p, 32mb for 1080p and above ..8mb for the rest etc 03.29.28 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 03.33.29 # *but I can change .... 03.57.24 Join steffengy [0] (~quassel@p5088FDAA.dip0.t-ipconnect.de) 03.58.35 # 8 + width/100? 03.58.54 # why not just bump all to 32mb? 03.59.17 # where is the ram required? 04.00.27 Quit steffengy1 (Ping timeout: 246 seconds) 04.07.18 # JdGordon: [Saint] is worry about 240x320 target's ram availability. 04.08.07 # <[Saint]> its just..unnecessarily large for for the low resolution devices. 04.08.31 # 8 for < 540p, 16 for 720p, 32 for 1080+. how about this? 04.09.10 # <[Saint]> that seems fairly reasonable. 04.09.11 # wait, this is the audiobuffer right? why can't that be allocated dynamically? 04.09.27 # do an "8mb" build and autoallocate based on avilaable ram 04.09.58 # <[Saint]> there's no reason to have the audio buffer so large when disk acecss is essentially free. 04.10.13 # <[Saint]> and its audio/skin/everything buffer. 04.10.43 # theme is sharing the same buffer. allocate right before audio part 04.10.48 # audio should be completly splt out for android 04.10.50 # <[Saint]> audiobuf is just the leftovers after skin allocations, like native targets. 04.17.37 # updated. this code looks soooo ugly :P 04.18.45 # <[Saint]> yikes 04.19.01 # I knew you gonna say that 04.19.43 # <[Saint]> the prior example certainly /looked/ cleaner, but it was based on essentially arbitrary magic. 04.20.12 # <[Saint]> this at least makes reasonably sane decisions based on a metric that isn't pulled from the sky. 04.22.09 # this buffer size issue actually remind me of g#681 04.22.11 # 3Gerrit review #681 at http://gerrit.rockbox.org/r/681 : 3buflib: Add malloc-based backend for application builds. by Thomas Martitz 04.23.13 # to me, 681 is the better solution 04.27.26 # <[Saint]> indeed. 04.29.28 Quit [Saint] (Quit: Going down for system update) 04.41.02 Quit Pessimis- (Ping timeout: 245 seconds) 04.44.08 Join [Saint] [0] (~saint@rockbox/staff/saint) 04.49.03 Quit amiconn (Disconnected by services) 04.49.03 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.49.04 Quit pixelma (Disconnected by services) 04.49.04 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.49.06 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.49.08 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.54.22 Join CyberYoda [0] (~nothing@ool-457bb8f0.dyn.optonline.net) 04.55.07 Quit krabador (Quit: Take the time.) 04.55.45 Join Pessimis- [0] (Anon@gateway/shell/elitebnc/x-vymhgwfnwbxxgyyi) 04.55.50 # Hi, I found a mistake in the wiki. It says I need to be added to the WikiUsersGroup before I can update the page. Who does that? 04.57.20 # hmmm.. 681,682 need some modification when compile against latest source. 1 dircache.c is gone. 2. talk.c move_callback() called buflib_context_relocate() , which isn't available after the patch. 04.59.31 # <[Saint]> CyberYoda: I can. 05.00.34 Join chrisb [0] (~chrisb@li482-205.members.linode.com) 05.02.59 *** Saving seen data "./dancer.seen" 05.03.52 # <[Saint]> argh. whats going on... 05.05.57 # <[Saint]> CyberYoda: you _should_ have access now 05.06.04 # [Saint]: Thanks 05.07.36 # <[Saint]> Let me know if reality doesn't meet expectation. 05.08.07 # [Saint]: I was able to make the correction. 05.08.21 # <[Saint]> Excellent. Also, welcome. 05.09.39 # Thanks. I'm working on an podcast program to interface with RockBox devices. 05.09.58 # I just found a mistake in the TagcacheDBFormat wiki. 05.10.22 # Does anybody know if that DB is going to change in the next/future release? 05.13.20 Join Diaz_ [0] (0122605d@gateway/web/freenode/ip.1.34.96.93) 05.13.39 # hi all 05.13.49 # Hi Mr. Diaz_ 05.13.53 # is asf_read_packet demux? 05.14.35 # since I would like to merge libwma to ffmpeg libavcodec 05.14.43 # for fix point wma decoder 05.15.19 Quit TheSeven (Ping timeout: 272 seconds) 05.15.49 # any input? 05.16.09 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.22.12 Join Strife89 [0] (~Strife89@adsl-98-80-207-130.mcn.bellsouth.net) 05.24.27 Quit advcomp2019_ (Ping timeout: 245 seconds) 05.31.37 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 05.56.33 Quit ploco (Quit: Page closed) 06.00.52 Quit KotH (Ping timeout: 240 seconds) 06.01.52 Join KotH [0] (~attila@lou-outside.kinali.ch) 07.03.02 *** Saving seen data "./dancer.seen" 07.09.08 Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.200.73) 07.25.22 Quit soap (Ping timeout: 240 seconds) 07.27.25 Join mortalis [0] (~kvirc@213.33.220.118) 07.28.11 Join soap [0] (~soap@rockbox/staff/soap) 08.25.28 Join ender` [0] (krneki@foo.eternallybored.org) 08.32.50 Quit chrisb (Ping timeout: 255 seconds) 08.34.19 Join ygrek [0] (~user@108.59.6.97) 08.39.20 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.43.02 Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) 08.49.37 Quit ygrek (Ping timeout: 272 seconds) 09.03.03 *** Saving seen data "./dancer.seen" 09.03.54 Quit CyberYoda () 09.09.11 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.10.59 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.12.56 Join petur [0] (~petur@rockbox/developer/petur) 09.19.44 Join rela [0] (~x@pD9E56126.dip0.t-ipconnect.de) 09.19.49 Quit rela (Changing host) 09.19.49 Join rela [0] (~x@pdpc/supporter/active/rela) 09.22.21 Join ygrek [0] (~user@108.59.6.97) 09.22.44 Join xorly [0] (~xorly@210.213.broadband13.iol.cz) 09.23.33 # pamaury: ping 09.31.15 # wodz: pong 09.32.32 # pamaury: In case I would like to stress bulk ep in hwstub what I need to change? I guess some descriptors to indicated bulk in/out eps? 09.33.50 # and bulk ep handling in irq of course 09.43.16 Quit rela (Read error: Connection reset by peer) 09.48.57 # wodz: you need at least a few endpoint descriptors to describe the EP yes 09.49.18 # and of course some code to some something with the data 09.49.58 # let me give an example 09.50.24 # pamaury: What is truly amazing is that OF doesn't do any cache coherency for ep0 09.50.56 # with dma ? that sounds wrong ^^ 09.51.53 # yep 09.52.36 # for bulk ep OF discards d cache lines separately for every chunk 09.52.44 # not the whole buffer at once 09.57.13 # wodz: something along these lines http://pastebin.com/v7n0X6H2 09.59.01 Quit xorly (Ping timeout: 245 seconds) 10.00.06 # pamaury: where do I set ep number? I want ep1 and ep2 (in and out respectively) 10.00.50 # also shouldn't .wMaxPacketSize be 512? 10.01.01 # wodz: in this code the usb_drv_request_endpoint is responsible for endpoint allocation 10.01.09 # wMaxPacketSize depend on link speed 10.01.44 # ah, now I see 10.01.56 # for full speed it can be 8, 16, 32 or 64 and high speed 512 10.02.59 # pamaury: There is no usb_drv_request_endpoint() in hwstub 10.03.30 # no, you need to implement it, because it needs to configure the endpoint 10.04.06 # pamaury: I'd go for simple hardcoded allocation. I will configure endpoints in some init() 10.04.17 # yeah 10.04.41 # don't forgot to put epnum | 0x80 for IN endpoints in bEndpointAddress 10.05.04 # great, thats what I was about to ask 10.05.09 # so ep1 has address 0x81 and ep2 has address 0x2 10.06.09 # So after this changes I should be able to do simple read/write to this endpoints with some libusb program, right 10.07.27 # assuming there some code to handle read/write yes 10.07.32 # sure 10.07.58 # but yeah, the descriptors are enough to make the host happy 10.29.57 Quit [Saint] (Quit: Quit.) 10.30.22 Join [Saint] [0] (~saint@rockbox/staff/saint) 10.37.14 Join rela [0] (~x@pdpc/supporter/active/rela) 10.45.04 Quit alucryd (Quit: alucryd out) 10.49.36 Join alucryd [0] (quassel@archlinux/trusteduser/alucryd) 11.03.04 *** Saving seen data "./dancer.seen" 11.07.52 # [Saint]: have you tested new usb driver on n2g? 11.08.59 # <[Saint]> just firing off a round of builds now. 11.09.06 # <[Saint]> can test later this evening. 11.13.07 Join rela_ [0] (~x@pD9E56126.dip0.t-ipconnect.de) 11.13.14 Quit Aldem (Read error: Connection reset by peer) 11.13.32 Join Aldem2 [0] (~Aldem@69.55.247.247) 11.16.09 Quit rela (Ping timeout: 252 seconds) 11.44.33 Quit Diaz_ (Ping timeout: 246 seconds) 11.45.52 Join ZincAlloy [0] (~Adium@pD9EE97CF.dip0.t-ipconnect.de) 11.50.29 Quit [Saint] (Ping timeout: 246 seconds) 11.57.52 Quit ygrek (Ping timeout: 240 seconds) 12.00.28 Quit alucryd (Quit: Alucryd out.) 12.00.38 Join alucryd [0] (alucryd@celestia.archlinux.org) 12.02.39 Quit alucryd (Changing host) 12.02.39 Join alucryd [0] (alucryd@archlinux/trusteduser/alucryd) 12.05.37 Quit alucryd (Quit: Alucryd out.) 12.06.51 Join alucryd [0] (quassel@archlinux/trusteduser/alucryd) 12.14.53 # pamaury: heh, hwstub driver for rk27xx doesn't do cache coherency as well 12.18.15 Quit rela_ (Quit: Leaving) 12.23.46 # wodz: maybe the dma is cache coherent ? I think the cache is external to the cpu on this soc right ? Or maybe they disable caches completely ? 12.24.20 Join DIY-Noob [0] (b8a34d2d@gateway/web/cgi-irc/kiwiirc.com/ip.184.163.77.45) 12.24.59 # pamaury: what you mean by 'disabled caches completely'? 12.25.36 # pamaury: disabling cache has severe effect on performance so I assume it actually works 12.27.02 # right, hwstub disables cache in crt0.S 12.27.39 # I mean the OF, that would be surprising I admit 12.28.03 # pamaury: no way, with cache turned off the OF will literally crawl 12.28.29 # maybe the hardware has some very poor kind of MMU which can tell whether memory is cached or not ? 12.28.44 # the code might just be completely buggy as well 12.29.38 # no that I know of. You can specify regions which are *not* cached but the smallest chunk you can declare this way is 32MB so you cannot put part of dram as uncached 12.30.07 # this is basically to set i/o space as uncachable (and cache controller address space as well) 12.32.45 # Build Server message: 3New build round started. Revision b7e3515, 253 builds, 28 clients. 12.35.51 # probably the OF is buggy and somehow relies on the bug to never actually trigger 12.36.48 # this udc core drives me mad 12.43.04 # Build Server message: 3Build round completed after 587 seconds. 12.43.04 Quit fs-bluebot (Quit: connection lost?) 12.47.43 Join fs-bluebot [0] (~fs-bluebo@g231121111.adsl.alicedsl.de) 12.53.51 Join [Saint] [0] (~saint@rockbox/staff/saint) 12.58.57 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 13.00.27 # saw a hidden touch action {"cancel", ACTION_STD_CANCEL }, in skin_parser.c 13.01.07 # so can use "cancel" for get 1 level back 13.02.23 # eh.. i mean touch action "cancel" work just like the back key 13.03.05 *** Saving seen data "./dancer.seen" 13.05.55 Quit ploco (Quit: Page closed) 13.12.28 Join ygrek [0] (~user@108.59.6.97) 13.28.31 Quit jhMikeS (Ping timeout: 245 seconds) 13.29.48 Join rela [0] (~x@pD9E55386.dip0.t-ipconnect.de) 13.29.53 Quit rela (Changing host) 13.29.53 Join rela [0] (~x@pdpc/supporter/active/rela) 13.50.51 Quit rela (Read error: Connection reset by peer) 14.05.52 Quit Pessimis- (Remote host closed the connection) 14.11.56 Quit dys (Ping timeout: 260 seconds) 14.16.37 Join dys [0] (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) 14.18.16 Join foolsh [0] (~bbrown@c-67-174-138-234.hsd1.in.comcast.net) 14.20.51 Join Pessimis- [0] (Anon@gateway/shell/elitebnc/x-bhmshuqswadujkes) 15.03.06 *** Saving seen data "./dancer.seen" 15.07.06 Join chrisb [0] (~chrisb@li482-205.members.linode.com) 15.08.45 Join rela [0] (~x@pdpc/supporter/active/rela) 15.23.06 Quit wodz (Quit: Leaving) 15.34.02 Quit cmhobbs (Ping timeout: 255 seconds) 15.40.05 Quit mortalis (Ping timeout: 246 seconds) 15.42.22 Join rela_ [0] (~x@pD9E55386.dip0.t-ipconnect.de) 15.44.55 Quit rela (Ping timeout: 252 seconds) 15.45.02 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.46.30 Quit amayer (Client Quit) 15.47.43 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.49.51 Quit Strife89 (Ping timeout: 245 seconds) 15.49.52 Nick sobukus_ is now known as sobukus (~thomas@basal.nesselzelle.de) 15.50.04 Quit sobukus (Changing host) 15.50.04 Join sobukus [0] (~thomas@sourcemage/mage/sobukus) 15.53.48 Quit rela_ (Quit: Leaving) 15.54.05 Join rela [0] (~x@pdpc/supporter/active/rela) 15.57.42 Join rela_ [0] (~x@pD9E55386.dip0.t-ipconnect.de) 16.00.19 Quit rela (Ping timeout: 252 seconds) 16.20.44 Quit copper (Quit: ZNC - http://znc.in) 16.23.45 Join copper [0] (~copper@unaffiliated/copper) 16.34.48 Join edhelas [0] (~edhelas@2001:bf0:c001:30:863a:4bff:fe85:8a3c) 16.51.36 Join krabador [0] (~krabador_@unaffiliated/krabador) 16.51.58 Join ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net) 16.53.02 Quit ygrek (Remote host closed the connection) 16.53.07 Join ikeboy_ [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 16.53.23 Join ygrek [0] (~user@108.59.6.97) 16.56.23 Quit ikeboy (Ping timeout: 246 seconds) 17.03.10 *** Saving seen data "./dancer.seen" 17.15.21 Quit bughunter2 (Quit: Leaving.) 17.20.28 Quit ygrek (Ping timeout: 260 seconds) 17.22.27 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.30.52 Join Diaz_ [0] (7a74df5e@gateway/web/freenode/ip.122.116.223.94) 17.31.06 # hi all experts. 17.31.08 # ff_imdct_calc cause SIGSEGV error 17.31.21 # when I try to merge fixed point wma decoder from Rockbox to ffmpeg libavcodec, 17.31.29 # does any one have ideas? 17.31.39 # where I can check in advance? 17.31.49 # the OS is Linux, CPU is mips 17.33.22 Join rela__ [0] (~x@pD9E575E4.dip0.t-ipconnect.de) 17.36.32 Quit rela_ (Ping timeout: 264 seconds) 17.36.55 Quit edhelas (Quit: Quitte) 17.37.41 Quit mc2739 (Ping timeout: 245 seconds) 17.39.33 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 17.58.49 # * foolsh is not an expert by no means 17.59.56 # but in linux when a program tries to access memory that is not own of accessible to it, the os will kill it 18.00.12 # is not owned by it* 18.01.03 # it sounds like that is what is happening IMO 18.03.53 # ? 18.04.00 # IMO? 18.04.19 # (in my opinion ) 18.04.58 # it seems not easily to debug in imdct functions 18.05.36 Quit petur (Quit: *plop*) 18.07.22 # SIGSEGV means it's trying to access memory that is not owned or accessible to it and the os is killing it, its a linux thing 18.08.09 # I think 18.08.17 # * foolsh doesn't use anything else 18.08.20 # It's not a linux thing 18.08.28 # It's a protected memory thing :) 18.08.49 # Good to know 18.10.15 # * foolsh did give a disclaimer at the start, that he was no expert ;-) 18.10.35 Quit pamaury (Ping timeout: 246 seconds) 18.31.54 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 18.35.50 # gevaerts: g#954 sorry it's just a boring addition to the manual 18.35.53 # 3Gerrit review #954 at http://gerrit.rockbox.org/r/954 : 3Rockbox Manual - Gigabeat FX and Fuze+ Touchpad Config Appendix by Benjamin Brown 18.36.26 Quit krabador (Quit: Take the time.) 18.44.54 Quit Diaz_ (Ping timeout: 246 seconds) 18.46.30 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.47.44 # gevaerts: or if you want a really hard problem there is always g#656 I'll even ship you some hardware too if you like ;-) 18.47.47 # 3Gerrit review #656 at http://gerrit.rockbox.org/r/656 : 3WinCE SDL port using Toolchain CeGCC 0.55 & SDL 1.2 by Benjamin Brown 18.48.01 # foolsh: is g#954 ready from your p.o.v.? 18.48.03 # 3Gerrit review #954 at http://gerrit.rockbox.org/r/954 : 3Rockbox Manual - Gigabeat FX and Fuze+ Touchpad Config Appendix by Benjamin Brown 18.48.19 # gevaerts: yes 18.48.24 # Build Server message: 3New build round started. Revision 12f5c63, 253 builds, 30 clients. 18.49.23 Quit rela__ (Quit: Leaving) 18.49.41 Join rela [0] (~x@pdpc/supporter/active/rela) 18.56.25 # Build Server message: 3Build round completed after 480 seconds. 18.57.04 # phew!!, that was exciting, right gevaerts? 18.57.29 # Not very :) 19.03.14 *** Saving seen data "./dancer.seen" 19.10.19 # * foolsh blows the dust off #656 "I haven't messed with this in a long long while" 19.10.24 # it was sort of a joke gevaerts ;-) 19.10.46 # not the patch the you helping part 19.10.51 # foolsh: I noticed :) 19.11.04 # None of the URLs you mention actually work! 19.12.33 # Yeah, there was some financial trouble last winter for me, and I shut down for a long time, and they went stale 19.12.46 # I'll see what is what 19.14.48 Quit chrisb (Ping timeout: 260 seconds) 19.20.01 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 19.21.16 # That patch is long gone now, but if I remember right it was only patching the makefile to prefix=/usr/local/ like the rest of the rockbox toolchain 19.27.13 Join chrisb [0] (~chrisb@pool-71-175-253-213.phlapa.east.verizon.net) 19.28.45 # gevaerts: g#957 19.28.48 # 3Gerrit review #957 at http://gerrit.rockbox.org/r/957 : 3Clean up - Removes whitespaces from tools/rockboxdev.sh by Benjamin Brown 19.44.00 Join ygrek [0] (~user@108.59.6.97) 19.56.55 Quit fs-bluebot (Quit: connection lost?) 20.01.36 Join fs-bluebot [0] (~fs-bluebo@g231121111.adsl.alicedsl.de) 20.02.44 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.04.42 Quit AlexP (Remote host closed the connection) 20.06.21 Quit chrisb (Ping timeout: 240 seconds) 20.07.38 Join AlexP [0] (~alex@rockbox/staff/AlexP) 20.20.29 Join krabador [0] (~krabador_@unaffiliated/krabador) 20.34.51 Quit ygrek (Ping timeout: 245 seconds) 21.03.18 *** Saving seen data "./dancer.seen" 21.06.18 Join chrisb [0] (~chrisb@li482-205.members.linode.com) 21.09.22 # Has anyone witnessed spontaneous e200 or fuze+ player reboots while plugged into a usb charger 21.13.35 # Ok weird the battery was drained, but what was keeping it from charging in rockbox? 21.18.53 # I have on fuze+ 21.19.33 # Try just getting a few minutes charging to a computer in bootloader, then the rest should work 21.21.40 # Yeah, but I had it plugged into a usb charger and running in rockbox for a day, but it ran the battery out completely, wasn't charging at all, is there a setting I might have enabled that does this? 21.21.53 # It charging on the PC usb now though 21.26.03 # that's a known bug 21.26.21 # the charging code is dumb, once it reaches 100%, it stops charging and the battery slowly drains 21.26.42 # it's on my todo list, just not very high 21.37.27 Join markun_ [0] (~markun@rockbox/developer/markun) 21.37.41 Join K1773R_ [0] (~K1773R@unaffiliated/k1773r) 21.38.39 Join Cultist_ [0] (~CultOfThe@c-98-223-211-32.hsd1.il.comcast.net) 21.38.42 Join ygrek [0] (~user@108.59.6.97) 21.38.47 Join ikeboy__ [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 21.40.13 Quit K1773R (Ping timeout: 252 seconds) 21.40.13 Quit markun (Ping timeout: 252 seconds) 21.40.14 Quit Cultist (Ping timeout: 252 seconds) 21.40.14 Quit ikeboy_ (Ping timeout: 252 seconds) 21.40.14 Quit Cinos (Ping timeout: 252 seconds) 21.40.16 Nick K1773R_ is now known as K1773R (~K1773R@unaffiliated/k1773r) 21.42.17 Join Cinos [0] (Cinos@cinos.biz) 21.44.49 Quit ikeboy__ (Quit: Leaving) 21.44.51 Quit ygrek (Ping timeout: 240 seconds) 21.47.08 Quit Jack87 (Quit: Jack has left the building.) 21.52.25 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 21.53.44 Join ygrek [0] (~user@108.59.6.97) 22.04.07 Join xorly [0] (~xorly@210.213.broadband13.iol.cz) 22.04.24 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 22.14.26 Quit Provel (Ping timeout: 245 seconds) 22.15.08 Join Provel [0] (Provel@75-132-30-64.dhcp.stls.mo.charter.com) 22.24.15 Quit ygrek (Ping timeout: 260 seconds) 22.51.37 Quit pamaury (Ping timeout: 246 seconds) 23.03.22 *** Saving seen data "./dancer.seen" 23.06.39 Join ygrek [0] (~user@108.59.6.97) 23.14.56 Quit foolsh (Remote host closed the connection) 23.17.26 Join foolsh [0] (~bbrown@c-67-174-138-234.hsd1.in.comcast.net) 23.29.30 Quit amayer (Quit: Leaving) 23.38.07 Quit ygrek (Ping timeout: 276 seconds) 23.45.48 Quit bertrik (Remote host closed the connection)