| 00:00:01 | [Saint] | TheSeven: debian |
| 00:00:16 | | Quit [Franklin] (Ping timeout: 245 seconds) |
| 00:00:49 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | I hated myself for that backdrop |
| 00:02:35 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | and yes, I'm using a backdrop for rockdroid |
| 00:03:43 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | speaking of scrollbars: are they themeable? |
| 00:07:14 | [Saint] | Not trivially. |
| 00:07:21 | ZincAlloy | 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 | ZincAlloy | sounds like a nightmare |
| 00:08:19 | [Saint] | It is. |
| 00:08:48 | ZincAlloy | 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 | ZincAlloy | 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] | <shiftplusone> 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 | ZincAlloy | 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 | ZincAlloy | 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 | foolsh | [Franklin]: It will happen if you keep programming, I dream about math |
| 00:21:42 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | they should. |
| 00:24:01 | ZincAlloy | but |
| 00:24:07 | [Saint] | ...yours dont? |
| 00:24:07 | [Franklin] | yep |
| 00:24:12 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | oh, I don't see it as criticism |
| 00:27:00 | ZincAlloy | it's interesting input |
| 00:27:08 | [Saint] | *phew* |
| 00:27:13 | [Saint] | :)) |
| 00:27:40 | ZincAlloy | but the issue doesn't bother me at all |
| 00:27:52 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | I don't really click the tiny cover art to go back to the wps intuitively |
| 00:29:34 | ZincAlloy | that should be plenty. |
| 00:29:52 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | yeah |
| 00:31:23 | ZincAlloy | when people are having issues with it you could still change it |
| 00:31:39 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | oh yeah. round jpgs. far out |
| 00:34:40 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | but I guess the ones with huge screens should have plenty of ram |
| 00:36:16 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | right |
| 00:37:38 | [Saint] | But, on a 240x320 target, its insane. |
| 00:38:10 | ZincAlloy | 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 | ZincAlloy | my bitmaps for the wps are only 3.2mb |
| 00:39:29 | ZincAlloy | another 2.8 for the menu backdrop |
| 00:39:43 | [Saint] | all mine are 900kB |
| 00:39:50 | [Saint] | (total) |
| 00:40:01 | ZincAlloy | you're too efficient |
| 00:40:12 | [Saint] | Never had anyone say that before. ;) |
| 00:40:16 | ZincAlloy | :D |
| 00:41:21 | ZincAlloy | or maybe not. being that efficient is more work |
| 00:42:09 | ZincAlloy | 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 | ZincAlloy | I've changed the UI viewport and added a stop function to the play/pause button as per your suggestions |
| 00:51:02 | ZincAlloy | 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 | foolsh | Dude, cheese cake |
| 01:00 |
| 01:00:56 | | Quit xorly (Ping timeout: 272 seconds) |
| 01:01:11 | ZincAlloy | 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 | ZincAlloy | 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 <obscure app> when <host> already offers <functionality>. |
| 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | it might be interesting for sandisk |
| 01:20:19 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | foolsh | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | foolsh | 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 | foolsh | 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 | ZincAlloy | it's just an idea at this point. adding a dumb mode is another great idea |
| 01:31:09 | foolsh | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | the only feature is less options |
| 01:35:51 | [Franklin] | exactly |
| 01:35:55 | [Franklin] | "simple" mode or something |
| 01:36:09 | ZincAlloy | 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 | ZincAlloy | "rockbox for dummies" |
| 01:38:11 | [Franklin] | "Light mode" |
| 01:38:12 | foolsh | but calling it "Enhanced mode" would really pull in them in |
| 01:38:18 | [Franklin] | LOL |
| 01:38:26 | ZincAlloy | 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 | foolsh | IU mode |
| 01:39:22 | [Franklin] | Enhanced then |
| 01:39:33 | [Franklin] | Rockbox XS |
| 01:39:37 | ZincAlloy | Rockbox Advanced |
| 01:39:40 | [Franklin] | Xtra-stupid |
| 01:39:50 | [Franklin] | And say it stands for Xtra-simple |
| 01:40:08 | ZincAlloy | Rockbox 2.0 |
| 01:40:11 | foolsh | 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 | ZincAlloy | oh, right, we're on 3.13 |
| 01:41:03 | ZincAlloy | 2.0 just has a nice ring. it sounds so advanced |
| 01:41:04 | [Franklin] | Rockbox 2000 |
| 01:41:13 | ZincAlloy | 2000 is so 14 years ago |
| 01:41:14 | [Franklin] | THE Rockbox 2000 :) |
| 01:41:22 | [Franklin] | THE Rockbox 3000 then :) |
| 01:41:49 | foolsh | Rockbox The Experience |
| 01:42:07 | foolsh | lol that was aweful |
| 01:42:08 | ZincAlloy | LOL |
| 01:42:21 | ZincAlloy | Popbox |
| 01:42:44 | [Franklin] | I'm leaning towards Rockbox XS |
| 01:42:47 | [Franklin] | It needs an X |
| 01:42:54 | ZincAlloy | XS sounds way too small |
| 01:43:02 | [Franklin] | XL |
| 01:43:03 | ZincAlloy | make it Rockbox 3XL |
| 01:43:07 | foolsh | lol |
| 01:43:13 | [Franklin] | No... just X |
| 01:43:20 | ZincAlloy | XBox |
| 01:43:23 | [Franklin] | X for Xtremely simple |
| 01:43:24 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | ZincAlloy | 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 | foolsh | [Franklin]: Loves those exxes doesn't he? |
| 01:45:57 | ZincAlloy | we need a completly unrelated name that expresses the characteristics of this simplified rockbox |
| 01:46:13 | foolsh | RXBX |
| 01:46:48 | [Franklin] | RBX |
| 01:46:51 | [Franklin] | Duh! |
| 01:47:24 | foolsh | 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 | foolsh | keep waiting |
| 01:48:38 | foolsh | How long has it been since 3.13? |
| 01:48:41 | [Franklin] | years |
| 01:48:49 | foolsh | right |
| 01:49:09 | * | [Franklin] thinks its long overdue |
| 01:49:14 | [Franklin] | so 4.0 it is |
| 01:49:49 | foolsh | 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 |
| 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 | drvink | 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 | drvink | 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 | drvink | so whatever needs to be done to it to get it accepted i am willing to do |
| 02:26:40 | drvink | 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 | drvink | gotcha |
| 02:28:46 | drvink | is the define ALLOW_USB_SPINDOWN? |
| 02:29:09 | [Saint] | possibly. |
| 02:29:47 | drvink | 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 | drvink | 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 | ploco | g#956 |
| 02:50:43 | fs-bluebot | Gerrit review #956 at http://gerrit.rockbox.org/r/956 : increase memorysize for Android build. by Chiwen Chang |
| 02:52:38 | | Quit bcobco () |
| 02:53:15 | ploco | I think ask 11MB on 240x320 target is ok. |
| 03:00 |
| 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 | drvink | [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 | ploco | it's from RCC. with a smaller base. initially the base was 16mb |
| 03:27:18 | ploco | but I change it to any pattern, such as only increase size for targets more then 720p |
| 03:28:52 | ploco | 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 | ploco | *but I can change .... |
| 03:57:24 | | Join steffengy [0] (~quassel@p5088FDAA.dip0.t-ipconnect.de) |
| 03:58:35 | JdGordon | 8 + width/100? |
| 03:58:54 | JdGordon | why not just bump all to 32mb? |
| 03:59:17 | JdGordon | where is the ram required? |
| 04:00 |
| 04:00:27 | | Quit steffengy1 (Ping timeout: 246 seconds) |
| 04:07:18 | ploco | 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 | ploco | 8 for < 540p, 16 for 720p, 32 for 1080+. how about this? |
| 04:09:10 | [Saint] | that seems fairly reasonable. |
| 04:09:11 | JdGordon | wait, this is the audiobuffer right? why can't that be allocated dynamically? |
| 04:09:27 | JdGordon | 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 | ploco | theme is sharing the same buffer. allocate right before audio part |
| 04:10:48 | JdGordon | 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 | ploco | updated. this code looks soooo ugly :P |
| 04:18:45 | [Saint] | yikes |
| 04:19:01 | ploco | 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 | ploco | this buffer size issue actually remind me of g#681 |
| 04:22:11 | fs-bluebot | Gerrit review #681 at http://gerrit.rockbox.org/r/681 : buflib: Add malloc-based backend for application builds. by Thomas Martitz |
| 04:23:13 | ploco | 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 | CyberYoda | 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 | ploco | 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 |
| 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 | CyberYoda | [Saint]: Thanks |
| 05:07:36 | [Saint] | Let me know if reality doesn't meet expectation. |
| 05:08:07 | CyberYoda | [Saint]: I was able to make the correction. |
| 05:08:21 | [Saint] | Excellent. Also, welcome. |
| 05:09:39 | CyberYoda | Thanks. I'm working on an podcast program to interface with RockBox devices. |
| 05:09:58 | CyberYoda | I just found a mistake in the TagcacheDBFormat wiki. |
| 05:10:22 | CyberYoda | 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 | Diaz_ | hi all |
| 05:13:49 | CyberYoda | Hi Mr. Diaz_ |
| 05:13:53 | Diaz_ | is asf_read_packet demux? |
| 05:14:35 | Diaz_ | since I would like to merge libwma to ffmpeg libavcodec |
| 05:14:43 | Diaz_ | for fix point wma decoder |
| 05:15:19 | | Quit TheSeven (Ping timeout: 272 seconds) |
| 05:15:49 | Diaz_ | 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 |
| 06:00:52 | | Quit KotH (Ping timeout: 240 seconds) |
| 06:01:52 | | Join KotH [0] (~attila@lou-outside.kinali.ch) |
| 07:00 |
| 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:00 |
| 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:00 |
| 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 | wodz | pamaury: ping |
| 09:31:15 | pamaury | wodz: pong |
| 09:32:32 | wodz | 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 | wodz | and bulk ep handling in irq of course |
| 09:43:16 | | Quit rela (Read error: Connection reset by peer) |
| 09:48:57 | pamaury | wodz: you need at least a few endpoint descriptors to describe the EP yes |
| 09:49:18 | pamaury | and of course some code to some something with the data |
| 09:49:58 | pamaury | let me give an example |
| 09:50:24 | wodz | pamaury: What is truly amazing is that OF doesn't do any cache coherency for ep0 |
| 09:50:56 | pamaury | with dma ? that sounds wrong ^^ |
| 09:51:53 | wodz | yep |
| 09:52:36 | wodz | for bulk ep OF discards d cache lines separately for every chunk |
| 09:52:44 | wodz | not the whole buffer at once |
| 09:57:13 | pamaury | wodz: something along these lines http://pastebin.com/v7n0X6H2 |
| 09:59:01 | | Quit xorly (Ping timeout: 245 seconds) |
| 10:00 |
| 10:00:06 | wodz | pamaury: where do I set ep number? I want ep1 and ep2 (in and out respectively) |
| 10:00:50 | wodz | also shouldn't .wMaxPacketSize be 512? |
| 10:01:01 | pamaury | wodz: in this code the usb_drv_request_endpoint is responsible for endpoint allocation |
| 10:01:09 | pamaury | wMaxPacketSize depend on link speed |
| 10:01:44 | wodz | ah, now I see |
| 10:01:56 | pamaury | for full speed it can be 8, 16, 32 or 64 and high speed 512 |
| 10:02:59 | wodz | pamaury: There is no usb_drv_request_endpoint() in hwstub |
| 10:03:30 | pamaury | no, you need to implement it, because it needs to configure the endpoint |
| 10:04:06 | wodz | pamaury: I'd go for simple hardcoded allocation. I will configure endpoints in some init() |
| 10:04:17 | pamaury | yeah |
| 10:04:41 | pamaury | don't forgot to put epnum | 0x80 for IN endpoints in bEndpointAddress |
| 10:05:04 | wodz | great, thats what I was about to ask |
| 10:05:09 | pamaury | so ep1 has address 0x81 and ep2 has address 0x2 |
| 10:06:09 | wodz | So after this changes I should be able to do simple read/write to this endpoints with some libusb program, right |
| 10:07:27 | pamaury | assuming there some code to handle read/write yes |
| 10:07:32 | wodz | sure |
| 10:07:58 | pamaury | 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:00 |
| 11:03:04 | *** | Saving seen data "./dancer.seen" |
| 11:07:52 | wodz | [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 |
| 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 | wodz | pamaury: heh, hwstub driver for rk27xx doesn't do cache coherency as well |
| 12:18:15 | | Quit rela_ (Quit: Leaving) |
| 12:23:46 | pamaury | 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 | wodz | pamaury: what you mean by 'disabled caches completely'? |
| 12:25:36 | wodz | pamaury: disabling cache has severe effect on performance so I assume it actually works |
| 12:27:02 | wodz | right, hwstub disables cache in crt0.S |
| 12:27:39 | pamaury | I mean the OF, that would be surprising I admit |
| 12:28:03 | wodz | pamaury: no way, with cache turned off the OF will literally crawl |
| 12:28:29 | pamaury | maybe the hardware has some very poor kind of MMU which can tell whether memory is cached or not ? |
| 12:28:44 | pamaury | the code might just be completely buggy as well |
| 12:29:38 | wodz | 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 | wodz | this is basically to set i/o space as uncachable (and cache controller address space as well) |
| 12:32:45 | fs-bluebot | Build Server message: New build round started. Revision b7e3515, 253 builds, 28 clients. |
| 12:35:51 | pamaury | probably the OF is buggy and somehow relies on the bug to never actually trigger |
| 12:36:48 | wodz | this udc core drives me mad |
| 12:43:04 | fs-bluebot | Build Server message: Build 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 |
| 13:00:27 | ploco | saw a hidden touch action {"cancel", ACTION_STD_CANCEL }, in skin_parser.c |
| 13:01:07 | ploco | so can use "cancel" for get 1 level back |
| 13:02:23 | ploco | 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:00 |
| 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:00 |
| 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 |
| 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:00 |
| 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 | Diaz_ | hi all experts. |
| 17:31:08 | Diaz_ | ff_imdct_calc cause SIGSEGV error |
| 17:31:21 | Diaz_ | when I try to merge fixed point wma decoder from Rockbox to ffmpeg libavcodec, |
| 17:31:29 | Diaz_ | does any one have ideas? |
| 17:31:39 | Diaz_ | where I can check in advance? |
| 17:31:49 | Diaz_ | 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 | foolsh | 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 |
| 18:00:12 | foolsh | is not owned by it* |
| 18:01:03 | foolsh | it sounds like that is what is happening IMO |
| 18:03:53 | Diaz_ | ? |
| 18:04:00 | Diaz_ | IMO? |
| 18:04:19 | foolsh | (in my opinion ) |
| 18:04:58 | Diaz_ | it seems not easily to debug in imdct functions |
| 18:05:36 | | Quit petur (Quit: *plop*) |
| 18:07:22 | foolsh | 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 | foolsh | I think |
| 18:08:17 | * | foolsh doesn't use anything else |
| 18:08:20 | gevaerts | It's not a linux thing |
| 18:08:28 | gevaerts | It's a protected memory thing :) |
| 18:08:49 | foolsh | 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 | foolsh | gevaerts: g#954 sorry it's just a boring addition to the manual |
| 18:35:53 | fs-bluebot | Gerrit review #954 at http://gerrit.rockbox.org/r/954 : Rockbox 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 | foolsh | 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 | fs-bluebot | Gerrit review #656 at http://gerrit.rockbox.org/r/656 : WinCE SDL port using Toolchain CeGCC 0.55 & SDL 1.2 by Benjamin Brown |
| 18:48:01 | gevaerts | foolsh: is g#954 ready from your p.o.v.? |
| 18:48:03 | fs-bluebot | Gerrit review #954 at http://gerrit.rockbox.org/r/954 : Rockbox Manual - Gigabeat FX and Fuze+ Touchpad Config Appendix by Benjamin Brown |
| 18:48:19 | foolsh | gevaerts: yes |
| 18:48:24 | fs-bluebot | Build Server message: New 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 | fs-bluebot | Build Server message: Build round completed after 480 seconds. |
| 18:57:04 | foolsh | phew!!, that was exciting, right gevaerts? |
| 18:57:29 | gevaerts | Not very :) |
| 19:00 |
| 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 | foolsh | it was sort of a joke gevaerts ;-) |
| 19:10:46 | foolsh | not the patch the you helping part |
| 19:10:51 | gevaerts | foolsh: I noticed :) |
| 19:11:04 | gevaerts | None of the URLs you mention actually work! |
| 19:12:33 | foolsh | 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 | foolsh | 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 | foolsh | 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 | foolsh | gevaerts: g#957 |
| 19:28:48 | fs-bluebot | Gerrit review #957 at http://gerrit.rockbox.org/r/957 : Clean 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:00 |
| 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:00 |
| 21:03:18 | *** | Saving seen data "./dancer.seen" |
| 21:06:18 | | Join chrisb [0] (~chrisb@li482-205.members.linode.com) |
| 21:09:22 | foolsh | Has anyone witnessed spontaneous e200 or fuze+ player reboots while plugged into a usb charger |
| 21:13:35 | foolsh | Ok weird the battery was drained, but what was keeping it from charging in rockbox? |
| 21:18:53 | ikeboy_ | I have on fuze+ |
| 21:19:33 | ikeboy_ | Try just getting a few minutes charging to a computer in bootloader, then the rest should work |
| 21:21:40 | foolsh | 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 | foolsh | It charging on the PC usb now though |
| 21:26:03 | pamaury | that's a known bug |
| 21:26:21 | pamaury | the charging code is dumb, once it reaches 100%, it stops charging and the battery slowly drains |
| 21:26:42 | pamaury | 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:00 |
| 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:00 |
| 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) |
icon identifies that the person is a core developer (has commit access).