| 00:02:38 | | Quit DataGhost (Ping timeout: 264 seconds) |
| 00:05:57 | linuxstb | RadicalR: Do you have any links to the Zune hacking you mentioned in -community? |
| 00:05:57 | | Quit p3tur (Remote host closed the connection) |
| 00:06:11 | RadicalR | Just a tick. |
| 00:06:21 | RadicalR | http://www.zuneboards.com/?p=vB50442 |
| 00:06:26 | RadicalR | Here's the annoucement |
| 00:06:31 | | Quit bertrik (Quit: De groeten) |
| 00:06:37 | RadicalR | They have links to the dev tools |
| 00:06:50 | RadicalR | If you're looking for more on "how they did it", I haven't seen that yet. |
| 00:07:01 | | Quit emrecelikten (Quit: Leaving.) |
| 00:07:04 | B4gder | but the dev tools seemed to mention windows things |
| 00:07:12 | B4gder | don't they? |
| 00:07:34 | B4gder | it seems to mostly be a way to put apps on it |
| 00:09:24 | RadicalR | Yes, by bypassing XNA. Basically, they can run the apps directly on the Zune's firmware |
| 00:09:27 | linuxstb | I've only looked very briefly, but it seems to be a way to develop apps that run within the Zune's firmware. So it makes sense it needs windows tools. |
| 00:09:30 | RadicalR | without being restricted. |
| 00:09:53 | linuxstb | So the question is whether this can be used to bootstrap a new OS... |
| 00:09:53 | B4gder | ah yes, it is basically a way to avoid XNA which is a toolsuite |
| 00:10:14 | RadicalR | linuxstb, at this point, I doubt that. |
| 00:10:31 | B4gder | "The first true hack available for the Zune, this makes it possible to, for the first time, run applications directly on top of the Zune firmware" |
| 00:10:31 | RadicalR | The main OS still needs to be loaded |
| 00:10:56 | B4gder | RadicalR: but the question is what an application can do |
| 00:10:56 | RadicalR | Say if you compiled rockbox as an application, that would probably work. |
| 00:11:09 | RadicalR | keeping in mind the different drivers |
| 00:11:10 | RadicalR | and such. |
| 00:11:25 | RadicalR | But as an OS? Not at this moment. |
| 00:11:58 | linuxstb | RadicalR: As B4gder said, it depends what that application can do. If it has _full_ access to the hardware, it can overwrite the original firmware and take over full control. |
| 00:12:15 | linuxstb | i.e. bootstrap a new OS |
| 00:12:22 | RadicalR | Hmm. Valid point. |
| 00:12:25 | B4gder | yes, a bootloader app |
| 00:13:00 | RadicalR | It would be funny if someone got rockbox working on the Zune. |
| 00:13:18 | B4gder | zune's aren't even sold in Europe afaik |
| 00:13:23 | RadicalR | Not yet. |
| 00:13:39 | RadicalR | However, rumors are going around that with the advent of the new Windows phone |
| 00:13:45 | RadicalR | that Zune may go worldwide. |
| 00:14:01 | linuxstb | Haven't there been rumors of that ever since the Zune launched? |
| 00:14:18 | RadicalR | I think MS actually demoed the phone recently. Let me check. |
| 00:14:22 | Llorean | Well, Win7P and the Zune both restrict apps to XNA (and I believe Java on the phone?) |
| 00:14:35 | B4gder | c# |
| 00:14:47 | Llorean | XNA is basically some C# libraries. |
| 00:14:55 | RadicalR | http://www.engadget.com/2010/04/12/microsoft-kin-one-and-kin-two-announced-windows-phone-roots-wit/ |
| 00:15:04 | Llorean | It would make sense, to an extent, that the Zune would end up being to the phone what the iPod Touch is to the iPhone |
| 00:15:57 | RadicalR | Agreed. |
| 00:15:58 | B4gder | "A Microsoft spokesperson said a European launch might not occur until 2009" |
| 00:16:03 | B4gder | hahaha |
| 00:16:06 | RadicalR | I think that's a typo. |
| 00:16:12 | * | Llorean is having a hard time figuring out what the actual exploit is. |
| 00:16:28 | B4gder | Llorean: right, I've not found it either |
| 00:16:39 | funman | +1 |
| 00:16:40 | RadicalR | My guess is this - it exploits XNA 3.1 |
| 00:16:51 | RadicalR | Because it fails to work on XNA 4.0 |
| 00:16:51 | B4gder | I mean with details |
| 00:17:29 | RadicalR | Well, I have noticed that the packages released so far has been executables. |
| 00:17:40 | RadicalR | Meaning the exploit is probably packed in with them. |
| 00:17:57 | RadicalR | Let me take a look around and see if there are any details. |
| 00:18:32 | | Quit funman (Quit: free(random());) |
| 00:19:17 | * | Llorean thought the XNA 4.0 preview currently still only allowed targeting the Win7Phone |
| 00:19:18 | RadicalR | Hm. They do have a channel, if you want to try asking them directly. |
| 00:19:35 | RadicalR | Llorean, I don't know. |
| 00:20:20 | RadicalR | It's on freenode, channel #zbdf |
| 00:20:45 | RadicalR | The guy who released this "hack" - name is itsnotabigtruck |
| 00:22:02 | B4gder | "FlashzuneplayerThe first one to give us a bit of information on when the Zune would be released in Europe was Jason Reindorp when he said Microsoft was not yet ready to officially announce when it would launch the service in Europe but it could possibly be out before the end of the year." (said in 2007) |
| 00:22:27 | RadicalR | Ugh. Then I honestly don't know. |
| 00:22:29 | RadicalR | :/ |
| 00:22:36 | B4gder | so yes, it seems it is believed roughly always |
| 00:22:52 | B4gder | and yet it has not happened yet |
| 00:23:04 | * | RadicalR shrugs. |
| 00:23:11 | RadicalR | I suppose you could always import them. |
| 00:23:21 | RadicalR | Or get someone in US mail you one. |
| 00:23:41 | B4gder | right, because there's a lack of targets here... :-) |
| 00:24:15 | RadicalR | Right. |
| 00:30:26 | * | linuxstb is talking in #zbdf |
| 00:31:05 | Llorean | It sounds like for the standard (non-HD) zune, Rockbox might not be too far fetched. |
| 00:31:55 | | Quit petur (Quit: Zzzzzz) |
| 00:34:36 | | Quit liar (Quit: Verlassend) |
| 00:35:23 | | Quit crwl (Ping timeout: 258 seconds) |
| 00:37:29 | | Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) |
| 00:44:03 | soap | I was under the impression the hack allowed the running of apps _on top of_ the Zune OS? |
| 00:44:28 | linuxstb | soap: Yes. But it sounds like that might allow a bootloader-app to be written to load Rockbox. |
| 00:44:32 | soap | a bypass of the Zune devkit, not a window into the hardware itself. |
| 00:44:38 | soap | ahh |
| 00:44:48 | Llorean | At least for the Zune Classic |
| 00:44:52 | | Quit stripwax (Read error: Connection reset by peer) |
| 00:45:03 | Llorean | Since it's CE 5.0 based which is fairly well known by now. |
| 00:46:25 | linuxstb | But I guess unlike jhMikeS (or maybe Torne) take an interest, nothing will happen.... |
| 00:46:37 | Torne | unlikely :) |
| 00:46:50 | | Quit TillW (Quit: This now concludes our broadcast day.) |
| 00:47:05 | | Quit ender` (Quit: I love deadlines. I especially like the whooshing sound they make as they go flying by. -- Douglas Adams) |
| 00:47:21 | linuxstb | Torne: Do you see any problems with bootstrapping Rockbox this way? (IIRC, you know a little about WinCE...) |
| 00:47:53 | Torne | i don't know how easy/difficult it is to get into supervisor mode on modern CE |
| 00:48:12 | Torne | it used to be trivial, but i think that was only versions before the one on the zune/beast/etc |
| 00:48:42 | Torne | you might find you need *another* exploit in the kernel or a driver to get svc access.. |
| 00:49:58 | Llorean | I don't know any details, but I know my phone (which is a much more recent WinMo, thought still 5.0 based) can be rebooted into Linux using the "haret" bootstrap they mentioned |
| 00:50:11 | Llorean | So it might be a good place to start looking. |
| 00:51:51 | Torne | yeah, i could bewrong. haret would be the way |
| 00:52:42 | Llorean | Maybe we should just mail jhMikeS a Zune and see what happens. :-P |
| 00:53:43 | | Quit shai (Read error: Connection reset by peer) |
| 00:53:56 | | Quit niekie (Read error: Operation timed out) |
| 00:53:58 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 00:54:26 | | Quit Battousai (Read error: Operation timed out) |
| 00:54:41 | | Quit chaos (Read error: Operation timed out) |
| 00:55:10 | | Join chaos [0] (~chaos@gentoo/user/ch4os) |
| 00:55:51 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 00:56:16 | | Join Barahir [0] (~jonathan@gssn-5f756f6b.pool.mediaWays.net) |
| 00:58:19 | | Join CGL [0] (~CGL@190.207.167.104) |
| 00:59:40 | | Quit wodz (Quit: Leaving) |
| 01:00 |
| 01:03:46 | | Quit efyx (Remote host closed the connection) |
| 01:05:35 | | Quit anewuser (Ping timeout: 240 seconds) |
| 01:09:43 | *** | Saving seen data "./dancer.seen" |
| 01:10:30 | | Quit halmi (Quit: halmi) |
| 01:12:01 | | Quit phanboy4 (Read error: Connection reset by peer) |
| 01:22:32 | | Join TillW [0] (~Till@CPE0022b077a841-CM00186851cd14.cpe.net.cable.rogers.com) |
| 02:00 |
| 02:00:00 | | Quit adnyxo (Quit: Leaving) |
| 02:01:20 | | Quit mirak (Quit: Ex-Chat) |
| 02:18:55 | | Quit tchan (Quit: WeeChat 0.3.1.1) |
| 02:23:34 | | Join RichiH [0] (~richih@freenode/staff/richih) |
| 02:23:41 | RichiH | hi |
| 02:24:04 | RichiH | is there any guesstimate if rockbox will ever run on a philips gogear vibe? |
| 02:25:03 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 02:25:25 | | Join killan_ [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 02:27:56 | krazykit | RichiH, whenever the interested owners do the hard work of porting |
| 02:28:13 | | Quit esperegu (Remote host closed the connection) |
| 02:29:01 | | Quit killan (Ping timeout: 264 seconds) |
| 02:31:59 | | Join vonStemmington [0] (~dersieger@97.104.89.30) |
| 02:32:24 | vonStemmington | Hey guys, I just had a question I'm sure you get a lot |
| 02:32:31 | vonStemmington | But since I couldn't really find an answer, I was hoping to get it here |
| 02:34:25 | vonStemmington | What exactly is the reason for there being no planned support for the 6G iPods? |
| 02:34:53 | vonStemmington | I figure it has to do with Apple being douchebags and locking the hardware down even more than the 5G iPods, but I wanted to just come by and ask |
| 02:35:29 | Llorean | There's never "planned support" |
| 02:35:44 | Llorean | There's just "volunteers show up with enough interest to figure out how to get it working, then do all the necessary and hard work to make it so" |
| 02:37:45 | vonStemmington | I realise that, what with Rockbox being a free, open source project, but since the first five generations of the iPod were supported, I assume there was some roadblock that was encountered with the latest generation |
| 02:38:30 | vonStemmington | And with the iPod having a 160GB hard drive, I'd figure there would be people with the interest in making it work.. meaning the problem must lie with the difficulty in making it so |
| 02:38:35 | krazykit | yes, a roadblock that has been discussed so many times it would be difficult to NOT find it with even the most cursory of searches |
| 02:38:59 | Llorean | vonStemmington: Well, you asked about "planned support" |
| 02:39:04 | Llorean | So I thought it would be best to clarify. |
| 02:41:01 | | Quit S_a_i_n_t (Ping timeout: 246 seconds) |
| 02:41:27 | vonStemmington | Llorean: I gotcha. That's why I extended what I meant afterwards. |
| 02:42:11 | | Join saratogalab [0] (~9803c20d@gateway/web/freenode/x-ixakdcuxnuwlejxg) |
| 02:42:43 | Llorean | Well, I think my answer covered it anyway - the caliber of those attempting the task has so far not been up to the difficulty of the task. It's more or less impossible to say how hard it is until someone actually gets it going, of course. |
| 02:42:45 | vonStemmington | krazykit: Really? Because I've been looking for a while and haven't been able to find anything really specific.. Just people asking about whether or not Rockbox works with the iPod Classic and responses saying that it's not supported and might never be |
| 02:43:14 | vonStemmington | Right, right. Just like any breakthrough, really.. It seems impossible until it gets going, and then snowballs from there. |
| 02:43:33 | Llorean | vonStemmington: But krazykit is right |
| 02:43:54 | Llorean | If you type ipod classic into the search box on the site, the *very* first link you get takes you to something from the mailing list in which is posted an article link that sums it up |
| 02:44:07 | vonStemmington | Oh jeez. |
| 02:44:11 | vonStemmington | Well, hold on, let me try that |
| 02:46:15 | vonStemmington | Alright found it. That's more or less what I expected to be the reason, but thanks |
| 02:46:39 | Llorean | Next time, a good tip for searching is to put the search terms in the search box. ;) |
| 02:46:47 | vonStemmington | I see in a July '09 update, some code was managed to be run on the Classic and nano 2G, so maybe there's hope some day.. |
| 02:47:29 | vonStemmington | Yeah yeah yeah :p I had tried that but I guess I was searching for "iPod 6G" rather than "iPod classic".. and I didn't notice the first link before either :P I guess I suck at this whole 'searching archives' thing |
| 02:50:33 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 02:52:51 | saratogalab | i'd like to remind people that we have a "status" link on the front page |
| 02:52:58 | saratogalab | and theres an entry there for the Ipod Classic |
| 02:53:13 | saratogalab | if you're not happy with the wiki's info, please add more! |
| 02:53:32 | vonStemmington | Fair enough! |
| 02:54:01 | saratogalab | hmm though the wiki says "classic 1G" |
| 02:54:17 | saratogalab | so perhaps its vague about the later classic models, though as far as I know they're all very similar \ |
| 02:55:51 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 02:58:51 | saratogalab | the linux4nano people have created a 63 page report explaining the Nano2G port: http://l4n.clustur.com/data/jiss33/Report/Linux4NanoReport.pdf |
| 03:00 |
| 03:00:21 | | Quit vonStemmington (Read error: Connection reset by peer) |
| 03:05:01 | | Quit rvvs89 (Read error: Connection reset by peer) |
| 03:07:33 | | Join vonStemmington [0] (~dersieger@97.104.89.30) |
| 03:07:48 | vonStemmington | Whoops, had a NickServ identification problem |
| 03:09:47 | *** | Saving seen data "./dancer.seen" |
| 03:10:35 | | Nick ollebe__ is now known as ollebe (~olle@root.rot.sgsnet.se) |
| 03:10:43 | | Quit ollebe (Quit: Leaving) |
| 03:11:01 | | Join Rob2223 [0] (~Miranda@p4FDCBCE6.dip.t-dialin.net) |
| 03:13:24 | | Quit Kitar|st (Ping timeout: 276 seconds) |
| 03:14:03 | | Quit Rob2222 (Ping timeout: 265 seconds) |
| 03:17:08 | | Join Kitar|st [0] (Kitar_st@BSN-182-38-88.dial-up.dsl.siol.net) |
| 03:24:54 | | Join Rob2222 [0] (~Miranda@p4FDCBCE6.dip.t-dialin.net) |
| 03:27:06 | | Quit Rob2223 (Ping timeout: 265 seconds) |
| 03:30:36 | | Quit adnyxo (Ping timeout: 260 seconds) |
| 03:41:44 | | Quit TillW (Quit: this concludes our broadcast day) |
| 03:48:24 | | Quit vonStemmington () |
| 03:55:32 | | Join bzed_ [0] (~bzed@devel.recluse.de) |
| 03:57:21 | | Quit bzed (Ping timeout: 248 seconds) |
| 03:58:04 | | Nick bzed_ is now known as bzed (~bzed@devel.recluse.de) |
| 04:00 |
| 04:04:25 | | Quit TheSeven (Ping timeout: 246 seconds) |
| 04:05:01 | | Join dys` [0] (~andreas@krlh-5f7361c6.pool.mediaWays.net) |
| 04:07:43 | | Quit dys (Ping timeout: 276 seconds) |
| 04:09:30 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:17:45 | | Join Rob2223 [0] (~Miranda@p4FDCBCA9.dip.t-dialin.net) |
| 04:19:46 | | Quit panni_ (Read error: Connection reset by peer) |
| 04:21:22 | | Quit Rob2222 (Ping timeout: 265 seconds) |
| 04:33:30 | | Quit Gump (Ping timeout: 260 seconds) |
| 04:33:39 | | Join TillW [0] (~Till@h92-net09.simres.netcampus.ca) |
| 04:47:06 | | Quit Barahir (Ping timeout: 246 seconds) |
| 04:48:56 | | Join Barahir [0] (~jonathan@gssn-5f7563c1.pool.mediaWays.net) |
| 04:50:23 | | Join Rondom [0] (~quassel@dslb-084-057-176-219.pools.arcor-ip.net) |
| 04:51:10 | | Quit Rondom_ (Read error: Operation timed out) |
| 04:58:07 | saratogalab | is test codec still broken on the clipv2? |
| 05:00 |
| 05:03:08 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 05:06:35 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 05:09:48 | *** | Saving seen data "./dancer.seen" |
| 05:13:17 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 05:13:25 | | Join plauclair [0] (~p-l_aucla@dsl2-029.express.oricom.ca) |
| 05:14:53 | plauclair | I was wondering if one day rockbox would be used all by itself (no dual boot) and replace the device firmware when it comes to dealing with usb |
| 05:16:26 | krazykit | on what device? rockbox handles usb on most of the stable targets |
| 05:16:41 | plauclair | I have a Sansa Fuze right now |
| 05:17:35 | plauclair | for example when I plug it, the Sansa screen comes up and when I unplug the usb it reloads the original firmware's database |
| 05:17:51 | krazykit | well, if someone writes the USB support it will |
| 05:18:39 | plauclair | I see, is that pretty complex stuff ? |
| 05:18:53 | krazykit | it is. |
| 05:22:11 | plauclair | I guess I'll have to pass on trying it :( |
| 05:25:02 | saratogalab | the problem with USB is that its not that important compared to most features, and not that many people know anything about it |
| 05:26:24 | | Quit Strife89 (Quit: Bed.) |
| 05:34:15 | | Join ollebe [0] (~olle@root.rot.sgsnet.se) |
| 05:40:06 | | Quit CaptainKewl (Remote host closed the connection) |
| 05:42:11 | | Join Gump [0] (~josh@adsl-68-88-123-124.dsl.lgvwtx.swbell.net) |
| 05:44:05 | plauclair | agreed, but I think it makes the whole rockbox experience feel more polished |
| 05:44:18 | | Quit Horscht (Quit: Verlassend) |
| 05:46:57 | plauclair | but considering it's an open project, it's clear that it's hard to implement |
| 05:48:04 | plauclair | it would be amazing if Rockbox was some kind of platform à la Android that manufacturers would base their firmware implementations on |
| 05:48:14 | | Join krazykit` [0] (~kkit@adsl-76-240-195-209.dsl.ipltin.sbcglobal.net) |
| 05:51:12 | | Quit krazykit (Ping timeout: 240 seconds) |
| 05:53:11 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 06:00 |
| 06:03:40 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 06:07:21 | ollebe | saratogalab: excellent document about linux4nano. |
| 06:07:57 | | Quit mikroflops_ (Ping timeout: 276 seconds) |
| 06:11:59 | | Quit xiainx (Quit: Good Bye!) |
| 06:14:46 | | Join rvvs89 [0] (ivo@bright-snat.ucc.asn.au) |
| 06:17:46 | | Part plauclair |
| 06:37:36 | | Quit anewuser (Ping timeout: 276 seconds) |
| 06:39:46 | | Nick Beta2K__ is now known as Beta2K (~Beta2K@d24-36-126-101.home1.cgocable.net) |
| 06:43:51 | | Join anewuser [0] (anewuser@201.209.93.62) |
| 06:43:53 | | Quit anewuser (Changing host) |
| 06:43:53 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 06:46:00 | | Quit CGL (Quit: Saliendo) |
| 06:46:03 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 06:48:24 | | Quit saratogalab (Quit: Page closed) |
| 06:49:40 | Blue_Dude | S_a_i_n_t: I think I've come up with a partial solution to your problem at FS #11208. A problem I noticed was that sometimes when setting the hotkey on a context menu item, the yes/no screen would pop up briefly then vanish as though a button had been pressed. |
| 06:50:08 | | Join matsl [0] (~matsl@94.136.75.10) |
| 06:51:25 | | Quit n17ikh (Read error: Connection reset by peer) |
| 06:51:25 | Blue_Dude | Well, for the yes/no screen, anything other than the select key means to cancel the action. The act of releasing the hotkey combo keys was enough to register as a "keypress" and dismiss the yes/no screen. |
| 06:51:59 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 06:52:51 | Blue_Dude | I redefined the hotkey combo such that it would only be recognized as such when the appropriate keys are released. This prevents and leftover |
| 06:53:44 | Blue_Dude | "keypresses" from messing up the yes/no screen. This may have been the quick flash of something you couldn't quite read. It should work now, and yes, I tried it out in the sim and there appear to be no conflicts. |
| 06:55:38 | Blue_Dude | This probably has nothing to do with problems related to setting anything other than the default, unless the problems you saw were coincidental to this bug. |
| 06:56:03 | Blue_Dude | Anyway, try out the patch and leave feedback. Thanks. |
| 06:56:11 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 07:00 |
| 07:06:12 | | Quit skx` () |
| 07:08:23 | | Part Gump ("Leaving") |
| 07:08:41 | | Quit rvvs89 (Changing host) |
| 07:08:41 | | Join rvvs89 [0] (ivo@pdpc/supporter/base/rvvs89) |
| 07:09:51 | *** | Saving seen data "./dancer.seen" |
| 07:17:22 | pixelma | Blue_Dude (for the logs): BUTTON_REL in a precondition sounds... weird |
| 07:26:42 | | Quit ansuz (Remote host closed the connection) |
| 07:54:48 | | Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) |
| 07:56:29 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 07:59:39 | ollebe | fsck. i accidentally built in the svn root, and then maked clean. now my changes are gone. |
| 08:00 |
| 08:13:36 | | Nick dys` is now known as dys (~andreas@krlh-5f7361c6.pool.mediaWays.net) |
| 08:13:36 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:24:05 | | Join EK2 [0] (~d4c7af38@giant.haxx.se) |
| 08:25:15 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 08:26:19 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 08:28:04 | | Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) |
| 08:29:08 | | Quit merbanan (Ping timeout: 260 seconds) |
| 08:29:15 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 08:38:23 | | Join flydutch [0] (~flydutch@host24-146-dynamic.15-87-r.retail.telecomitalia.it) |
| 08:40:19 | | Quit phanboy4 (Quit: Leaving) |
| 08:42:23 | | Quit EK2 (Quit: CGI:IRC) |
| 08:47:08 | | Quit pixelma (Disconnected by services) |
| 08:47:10 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 08:47:32 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 08:47:46 | | Quit amiconn (Disconnected by services) |
| 08:47:48 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 08:48:10 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 08:52:40 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 08:59:24 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:00 |
| 09:09:55 | *** | Saving seen data "./dancer.seen" |
| 09:11:25 | | Join DerPapst [0] (~Alexander@p5797CAE0.dip.t-dialin.net) |
| 09:21:18 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 09:24:57 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 09:25:03 | | Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) |
| 09:26:29 | | Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) |
| 09:27:37 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 09:30:16 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 09:30:16 | | Quit tmzt_ (Read error: Connection reset by peer) |
| 09:33:00 | pixelma | JdGordon: if you still want me to flyspray the %pv bug, I can do that now |
| 09:33:29 | JdGordon | that one has been fixed, (or will be when I hear back from s_aint |
| 09:33:38 | JdGordon | the other ones you bring up every so often though... |
| 09:33:41 | | Quit mt (Ping timeout: 258 seconds) |
| 09:34:40 | | Quit MethoS- (Remote host closed the connection) |
| 09:35:16 | pixelma | what? |
| 09:35:38 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 09:36:55 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 09:40:04 | | Quit n17ikh (Remote host closed the connection) |
| 09:43:01 | | Join Coyote [0] (~5c67ab8e@giant.haxx.se) |
| 09:43:23 | Coyote | hi! |
| 09:45:24 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 09:46:42 | pixelma | JdGordon: sorry, I can't remember which bugs I bring up every now and then, if I remember I'll flyspray them |
| 09:48:56 | | Join mitk [0] (~mitk@195.117.162.130) |
| 09:50:08 | | Quit DerPapst (Quit: Leaving.) |
| 09:54:30 | | Join tmzt_ [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) |
| 09:55:22 | | Quit Zagor (Remote host closed the connection) |
| 09:55:29 | Coyote | can someone have a look to FS #11139 and tell me if I'm the only one to encounter this? |
| 09:59:43 | | Quit avn (Ping timeout: 264 seconds) |
| 10:00 |
| 10:00:18 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 10:01:34 | | Join avn [0] (~avn@88.119.164.243) |
| 10:04:29 | | Join mt-phone [0] (~mtee@41.91.19.193) |
| 10:17:57 | | Join halmi [0] (~halmi@e195-234.eduroam.tuwien.ac.at) |
| 10:18:32 | | Quit halmi (Client Quit) |
| 10:26:04 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 10:35:11 | | Join DerPapst [0] (~Alexander@188.107.192.248) |
| 10:35:20 | | Quit avn (Ping timeout: 248 seconds) |
| 10:37:27 | | Join avn [0] (~avn@88.119.164.243) |
| 10:41:03 | | Quit mt (Read error: No route to host) |
| 10:41:06 | | Quit lpereira (Ping timeout: 264 seconds) |
| 10:41:39 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 10:42:22 | JdGordon | grr... is svn.rockbox.org down? |
| 10:42:49 | | Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) |
| 10:42:58 | Zagor | JdGordon: no |
| 10:43:10 | JdGordon | hmm, ok |
| 10:43:46 | CIA-5 | New commit by jdgordon (r25677): 2 quick fixes ... |
| 10:44:37 | * | JdGordon now has a nice demo wps with a red/orange/green volume bar using %pv bmp bars |
| 10:54:47 | | Quit Coyote (Quit: CGI:IRC) |
| 10:56:01 | | Join Coyote [0] (~5c67ab8e@giant.haxx.se) |
| 11:00 |
| 11:02:15 | | Quit esperegu (Read error: Operation timed out) |
| 11:05:42 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 11:09:58 | *** | Saving seen data "./dancer.seen" |
| 11:25:00 | | Join emrecelikten [0] (~anubis@88.236.98.34) |
| 11:31:00 | | Quit avn (Ping timeout: 265 seconds) |
| 11:32:22 | JdGordon | pixelma: that commit shuold fix the %pv issue, let me know if it doesnt |
| 11:32:27 | JdGordon | or adds more wierdness |
| 11:32:37 | | Join avn [0] (~avn@88.119.164.243) |
| 11:32:40 | Hadaka | is there a channel for mac80211? |
| 11:37:17 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 11:46:52 | pixelma | JdGordon: I'll do. I probably won't be able to test the next few hours though (only after work) |
| 11:47:12 | JdGordon | I'm heading out now anyway so no worries |
| 11:48:38 | JdGordon | does anyone want me to ship the USB tracer back to europe for the devcon? I don't know when I'll be able to try again with my stereo... |
| 11:51:42 | * | linuxstb thought the Clip+ had been relegated back to unusable? The front page still lists it as unstable. |
| 12:00 |
| 12:01:06 | | Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) |
| 12:02:46 | Zagor | linuxstb: it was, but the front page wasn't svn up:ed |
| 12:02:50 | Zagor | fixed now |
| 12:05:11 | | Quit jfc (Ping timeout: 276 seconds) |
| 12:06:13 | JdGordon | asssuming it is bassically free to add the bar to any tag, does it make sense to add it to the pitch and speed tags? 50% would be no adjustment... |
| 12:06:49 | JdGordon | also, playlist position? worth adding? |
| 12:07:05 | JdGordon | database rating and autoscore? |
| 12:07:53 | JdGordon | them and battery voltage look like the only ones which it could make sense |
| 12:08:50 | | Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) |
| 12:10:34 | JdGordon | S_a_i_n_t ^^ |
| 12:11:36 | | Quit killan_ (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 12:13:39 | | Quit MethoS- (Read error: Connection reset by peer) |
| 12:13:46 | JdGordon | hmm... pixelma would it be at all useful to add a new tag which would increment itself every X ms to make animations eaiser? %?xx5<a|b|c|d> would just loop over 1-4 every 5s? a/b/c/d would usually be %xdZZ's |
| 12:14:23 | JdGordon | instead of using long sublines for it |
| 12:17:59 | | Join mischasworld [0] (~quassel@193.174.158.110) |
| 12:19:35 | JdGordon | is %t5a;%t5b;%t5c;%t5d correct? |
| 12:31:32 | pixelma | I can't imagine how that should work at the moment (or where the difference would be - maybe if you need other conditionals inside the sublines?). Could you give an example how e.g. one of the long animation lines in iCatcher would look like then? I don't use animations in my own WPSs so maybe I'm not the right person to ask |
| 12:34:45 | | Join halmi [0] (~netbook@188.20.253.186) |
| 12:36:24 | | Join M3DLG [0] (~M3DLG@212.183.140.49) |
| 12:41:05 | | Join feisar [0] (jljhook@irkki.fi) |
| 12:41:33 | | Nick feisar is now known as Guest20471 (jljhook@irkki.fi) |
| 12:49:23 | | Quit M3DLG (Ping timeout: 276 seconds) |
| 12:49:56 | | Part rom1dep ("byebye") |
| 12:51:25 | | Join ucchan [0] (~ucchan@i121-113-174-118.s05.a014.ap.plala.or.jp) |
| 12:53:28 | | Join Lixun [0] (Lixun@nusnet-231-40.dynip.nus.edu.sg) |
| 12:53:59 | | Part Lixun |
| 12:54:16 | | Join Lixun [0] (Lixun@nusnet-231-40.dynip.nus.edu.sg) |
| 12:54:18 | | Part Lixun |
| 12:55:48 | | Join TheSeven [0] (TheSeven@rockbox/developer/TheSeven) |
| 12:56:53 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 12:58:03 | | Join Lynx_ [0] (~Lynx_@86.51.114.197) |
| 13:00 |
| 13:00:30 | ucchan | new text viewer plugin had been completed, I send the patch in tracker (FS #11209). |
| 13:00:30 | ucchan | If you have noticed, please comments to the task. |
| 13:01:04 | kugel | gevaerts, linuxstb, pixelma, saratoga, petur: One thing I would like to highlight once more because I have forgotten to mention it in the interview is that I really don't worry about the exams. I'm able to chose between two examination dates for each exam where the other way after GSoC ended |
| 13:02:06 | kugel | I could schedule up to all exams for the second date if needed so that I can focus on GSoC only after about mid-july |
| 13:02:23 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 13:03:28 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 13:04:39 | | Join killan [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 13:05:16 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 13:10:02 | *** | Saving seen data "./dancer.seen" |
| 13:11:22 | | Quit geertvdijk (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 13:18:04 | | Quit TheSeven (Disconnected by services) |
| 13:18:06 | | Join The_Seven [0] (TheSeven@rockbox/developer/TheSeven) |
| 13:21:00 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 13:26:30 | | Quit mischasworld (Ping timeout: 265 seconds) |
| 13:27:42 | | Join mischasworld [0] (~quassel@193.174.158.110) |
| 13:29:07 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 13:29:24 | | Quit ucchan (Ping timeout: 265 seconds) |
| 13:30:01 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
| 13:32:23 | | Quit matsl (Ping timeout: 252 seconds) |
| 13:33:40 | petur | kugel: imho, exams have priority, and I would spread as much as possible. Short gaps inbetween should not be a problem, the overal work amount counts, that's all |
| 13:39:19 | kugel | right, I just thought it's useful to know. I just want to make clear that exams are not going to be a problem as I'm flexible with their dates, I have absolutely no disadvantage if I delay them to the 2nd examination period. Actually, I have an advantage (unrelated to gsoc) because I have more preparation time for them as the first period is during the lecture period, and I often get to see the exam from the 1st period. So I would chose the 2nd per |
| 13:39:19 | kugel | iod for the hardest exams anyway |
| 13:47:11 | | Quit Coyote (Quit: CGI:IRC) |
| 13:48:20 | | Join Coyote [0] (~5c67ab8e@giant.haxx.se) |
| 14:00 |
| 14:00:51 | | Join paulk_ [0] (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
| 14:03:17 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 14:03:51 | paulk_ | Hello ! Does the 3.5.1 bootloader starts rockbox with USB support when it's shut down and then plugged by usb ? |
| 14:04:41 | | Quit mischasworld (Ping timeout: 265 seconds) |
| 14:04:42 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 14:07:32 | Torne | paulk_: on which player? |
| 14:07:42 | paulk_ | Torne: e250 |
| 14:08:16 | Torne | also there is no 3.5.1 bootloader, bootloaders are released independantly |
| 14:09:19 | paulk_ | ok |
| 14:13:23 | Torne | rockbox usb has been enabled on e200 for a long time, anyway, so it should do :) |
| 14:13:27 | Blue_Dude | pixelma: (For the logs) Don't knock it until you've tried it. |
| 14:13:34 | ved | by the way, is there any reason not to use charging batteries through rockbox? Like by BIG accident the OF would have better charging control? |
| 14:13:35 | paulk_ | yes, but when I plug my powered-off sansa to USB , does it starts rockbox or the original firmware ? |
| 14:14:00 | ved | on e200 it starts rockbox for me |
| 14:14:46 | Torne | paulk_: current bootloader versions boot rockbox, for all targets that have rockbox usb support, except ipods |
| 14:14:54 | paulk_ | Torne: okay |
| 14:14:58 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 14:15:13 | | Quit Zagor (Quit: Leaving) |
| 14:15:32 | Torne | (well, actually on ipod the bootloader always boots rockbox as well, even if there *isn't* rockbox usb support enabled on that build) |
| 14:17:58 | pixelma | Blue_Dude: did you? |
| 14:18:41 | Torne | talking of ipod bootloaders i need to compile some new ones |
| 14:20:40 | ved | Torne: If you know, is battery charging on e200 controlled almost totally by hardware? Like all the voltage/current characteristics, they do not depend on wether I use OF or rockbox for charging? |
| 14:20:56 | Blue_Dude | pixelma: I already noted that it works in the sim. I spent several hours on it, with a number of sim builds before I hit on an unconventional, but functional, approach. I just posted a note at FS #11208 more fully explaining the problem. |
| 14:22:08 | Torne | ved: charging is software controlled |
| 14:22:16 | Torne | well, sort of |
| 14:22:42 | Torne | the ascodec chip handles it, but the parameters for the charging are specified by software |
| 14:24:49 | Torne | i would expect the parameters we use are from the original firmware, but they may not be |
| 14:25:09 | Torne | e200 is a stable target and there shouldn't be any problems with it; there are no issues with charging mentioned on the port status page. |
| 14:25:17 | Torne | are you having a problem? |
| 14:25:32 | | Quit anewuser (Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.) |
| 14:26:31 | | Join xiainx [0] (~iain@modemcable195.238-202-24.mc.videotron.ca) |
| 14:26:32 | ved | no, I've just recently switched to 3.5.1 and started charging with rockbox, and I was just wondering, if charging with OF would be more healthy for the batteries. |
| 14:28:22 | Torne | generally on stable targets we do everything at *least* as well as the original firmware, unless there are documented problems ;) |
| 14:28:35 | ved | ok :) |
| 14:31:14 | | Quit mc2739 (Ping timeout: 246 seconds) |
| 14:33:11 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 14:40:40 | | Join Schmogel [0] (~Miranda@p3EE21A73.dip0.t-ipconnect.de) |
| 14:46:07 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 14:50:53 | | Quit parafin (Ping timeout: 276 seconds) |
| 14:52:22 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 14:52:56 | | Quit JohannesSM64 (Ping timeout: 245 seconds) |
| 15:00 |
| 15:01:42 | | Join parafin [0] (parafin@paraf.in) |
| 15:06:51 | | Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) |
| 15:10:06 | *** | Saving seen data "./dancer.seen" |
| 15:18:16 | | Quit shaggy-h () |
| 15:19:10 | | Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) |
| 15:20:26 | | Quit mitk (Quit: Leaving) |
| 15:22:17 | | Join CGL [0] (~CGL@190.207.167.104) |
| 15:23:48 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 15:27:30 | | Quit lpereira (Quit: Leaving.) |
| 15:32:46 | | Quit xiainx (Quit: Good Bye!) |
| 15:35:36 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 15:41:43 | | Quit paulk_ (Quit: Ciao) |
| 15:43:09 | pixelma | Blue_Dude: shouldn't the BUTTON_REL event be in the actual button combo part, not the pre-condition? I have a real hard time believing those thing can work with a release event in the pre-condition. |
| 15:44:03 | pixelma | and how are you supposed to hold the combo? Press Play, release it and immediately press Select? |
| 15:44:23 | Blue_Dude | pixelma: No, not really. That's because the "pre-condition"... isn't. That's a convenient way to think about it if you think in terms of button *depressions* but that's not how the button code works. |
| 15:44:40 | | Join Antibuddha [0] (~chatzilla@c-71-59-19-167.hsd1.ga.comcast.net) |
| 15:45:07 | Blue_Dude | You press both buttons and release them. The action just triggers on the release, not the depression. The user action is the same. |
| 15:45:23 | Antibuddha | you know what would be cool? if rockbox made a lossless codec that contained a bunch of lossless codecs, then selects one that would minimize best for specific files |
| 15:45:57 | Antibuddha | like if its mostly speech it would automatically select some speech compression codec |
| 15:46:05 | Torne | er.. you don't need anything in rockbox to do this |
| 15:46:09 | linuxstb | Antibuddha: That's just an encoding problem. Rockbox will just play whatever... |
| 15:46:10 | Torne | write a small shell script |
| 15:46:16 | Antibuddha | ok |
| 15:46:42 | Antibuddha | but the decoder should contain all the different formats |
| 15:46:45 | pixelma | Blue_Dude: sorry, that's against all I learned so far and I'm in high doubt (seeing your first try to reverse the combo isn't giving me much trust). |
| 15:47:00 | Torne | Antibuddha: no, why would you want to do that? that's stupid. |
| 15:47:05 | Antibuddha | o |
| 15:47:07 | | Quit emrecelikten (Quit: Leaving.) |
| 15:47:13 | Antibuddha | for simplificity sake |
| 15:47:16 | Blue_Dude | The button code reads button depressions, button repeats, and button releases. They are different events. The "pre-condition" isn't a pre-condition at all, it's just the previous button press, no matter how long ago that occurred. |
| 15:47:17 | Torne | No, that's not simpler |
| 15:47:26 | Torne | it's far, far more complicated :) |
| 15:47:44 | Antibuddha | how come? |
| 15:47:45 | Torne | It's simplest to just have the encoding script output files in the appropriate format with the appropriate file extension |
| 15:47:52 | Antibuddha | oh |
| 15:47:56 | Torne | then any old music player will use the right codec for each |
| 15:48:02 | kugel | Blue_Dude: but the pre-condition must be met for the action to fire |
| 15:48:08 | | Join ssorgatem [0] (~c193def2@gateway/web/freenode/x-mxwoiwcdcfqaligh) |
| 15:48:10 | Antibuddha | but what if you made a format that could have data on which decoder to use? |
| 15:48:13 | Blue_Dude | pixelma: Try it. Go look in action.c and enable debug code. See what actually goes on there. |
| 15:48:19 | Torne | Antibuddha: there are many such formats |
| 15:48:21 | linuxstb | Antibuddha: All formats have that... |
| 15:48:28 | Antibuddha | really? |
| 15:48:37 | Torne | There's still no reason to care :) |
| 15:48:51 | linuxstb | Antibuddha: How do you think a media player knows how to decode files? |
| 15:48:53 | Torne | it's much easier and simpler to use whatever the native container is for each codec |
| 15:48:59 | Torne | and the correct file extension for that container |
| 15:49:11 | Torne | what do you gain by having htem all in the same container? |
| 15:49:33 | Antibuddha | linuxstb: i mean a single encoder/decoder that contains all apple lossless, flac, and speech specific lossless, etc |
| 15:49:39 | Blue_Dude | kugel: Almost. That's what we usually think about, but the "pre-condition" is just the required *last button* press. It's just that usually we make that last button press a button depression, but other events work just as well. |
| 15:49:44 | pixelma | Blue_Dude: sure about the three different states but I still don't get what you say about "pre-condition" is not a "pre-condition" |
| 15:49:45 | Antibuddha | then it decides which one would minimize space best, and tell the decoder which one it used |
| 15:50:01 | Torne | Antibuddha: yes. why can't it tell the decoder by outputting a .spx or .flac or whatever? |
| 15:50:08 | Torne | that's a perfectly good way to communicate this information |
| 15:50:21 | Antibuddha | because not all players will want to have multiple decoders |
| 15:50:27 | kugel | right, it's the required last button press. so it's required, hence it's a pre condition |
| 15:50:33 | Antibuddha | if it was made mandatory for it to have one super decoder it will |
| 15:50:41 | Blue_Dude | pixelma: The "pre-condition" is the required last button action. It's not necessarily a button depression. |
| 15:50:47 | Torne | Antibuddha: Er, please point to a music player that is used by more than two people that only has one codec? |
| 15:51:02 | Antibuddha | Torne: apple doesnt like to support flac |
| 15:51:14 | kugel | Blue_Dude: but if you have |BUTTON_REL in the pre-condition that it is a de-pression |
| 15:51:15 | linuxstb | Antibuddha: And they would support such a "super-format" ? |
| 15:51:20 | Torne | apple also won't support your hypthetical new format either |
| 15:51:20 | Antibuddha | but we could force them to by using a convenient super encoder/decoder |
| 15:51:27 | Antibuddha | if enough people use it |
| 15:51:30 | linuxstb | Err, no... |
| 15:51:31 | Torne | you realise that what you describe is *exactly* what almost every music player already implements |
| 15:51:31 | kugel | s/that/then/ |
| 15:51:35 | pixelma | Blue_Dude: but that's what you usually do if you hold a button combo though, no? |
| 15:51:45 | Blue_Dude | kugel: yes, but depressing the key wasn't the very *last* action. |
| 15:51:49 | Torne | you look at the file information to decide which internal decoder to use |
| 15:51:57 | Torne | rockbox works this way :) |
| 15:52:03 | pixelma | you hold both keys toegther, usually one fore the other |
| 15:52:09 | Blue_Dude | pixelma: Yes, but we can't have a button release event hanging going into a yes/no screen. |
| 15:52:10 | Torne | we have one big metadata parser blob compiled into the main binary, which knows how to read many file formats' headers |
| 15:52:13 | Antibuddha | but the encoder should decide for you which format to use |
| 15:52:14 | linuxstb | Antibuddha: But anyway, this is straying away from #rockbox talk. We're not in the business of inventing new audio formats, but we do support as many existing formats as we can. |
| 15:52:21 | kugel | Blue_Dude: it's almost impossible to require a release of a button and require it to be pressed in the next tick again |
| 15:52:22 | Antibuddha | ok |
| 15:52:51 | pixelma | Blue_Dude: I'm sorry, I still don't understand |
| 15:52:57 | Torne | Antibuddha: for reference, wav, avi, mp4, mov, ogg, mkv, are all existing container formats which work exactly as you describe :) |
| 15:53:09 | Torne | they can contain any format (in theory) and the header tells you which actual decoder to use. |
| 15:53:20 | Blue_Dude | kugel, pixelma: read FS #11208. |
| 15:53:28 | pixelma | I did |
| 15:53:34 | Antibuddha | what im describing is a encoder that decides which lossless format will minimize space best, and an encoder that contains dozens of lossless algorithms |
| 15:53:50 | Antibuddha | a decoder that contains* |
| 15:53:57 | Blue_Dude | pixelma: Then try it out for yourself and walk through the button logic. It *does* work. |
| 15:54:04 | kugel | Blue_Dude: I did too |
| 15:54:12 | Bagder | Antibuddha: you can already do that by simply encoding with them all and pick the smallest |
| 15:54:27 | kugel | anyway, i think heavily relying on release timing is maybe not a good idea |
| 15:54:28 | Antibuddha | should be done auto, im discussing im community now |
| 15:54:31 | | Part Antibuddha |
| 15:54:43 | Bagder | the auto part would be a script, yes |
| 15:55:28 | Blue_Dude | kugel: You don't have to time it. You can hold down two buttons and release in any order. A release event is generated, followed by another some time later. The exact timing isn't important. |
| 15:56:07 | pixelma | IMO your line there is not much different to having BUTTON_NONE there |
| 15:56:22 | Blue_Dude | kugel: What is important is that no keys are held down before entering the yes/no screen. |
| 15:56:43 | amiconn | pixelma, Blue_Dude: BUTTON_REL in a precondition is clearly wrong |
| 15:57:05 | Blue_Dude | amiconn: Just try it. |
| 15:57:15 | Blue_Dude | If anyone has a better suggestion I'm all ears. |
| 15:58:23 | Blue_Dude | It's bass-ackwards, but a release event *is* a legal button press, and a legal *last* button press. |
| 15:58:35 | amiconn | Blue_Dude: That has nothing to do with trying; A release cannot be a precondition |
| 15:58:54 | Blue_Dude | And yet it works. What can I say? |
| 15:59:18 | pixelma | I bet it works the same as BUTTON_NONE there |
| 15:59:25 | amiconn | It may work if you're lucky, but it's wrong logic |
| 15:59:26 | Blue_Dude | I read the button codes right out of action.c. That's how it perceives it. |
| 16:00 |
| 16:00:17 | Blue_Dude | pixelma: OK, try BUTTON_NONE. That seems like it may work but I haven't tested it. |
| 16:01:18 | Blue_Dude | But BUTTON_NONE really would depend on timing. You'd have to release both buttons at the same tick before you'd go from a combo to BUTTON_NONE in the same action. |
| 16:02:14 | amiconn | Blue_Dude: Why do you trigger a combo on release? That won't work reliably of course |
| 16:02:23 | | Quit kugel (Ping timeout: 276 seconds) |
| 16:02:34 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 16:02:39 | Blue_Dude | amiconn: read FS #11208. I explained in some detail there the problem I was trying to avoid. |
| 16:03:31 | pixelma | ah, I think there's something... with that weird BUTTON_REL you probably stop the "signal chain" (I hope that's the right term) even if already holding one button. And then because you already hold the combo it might work - maybe even slightly better than with BUTTON_NONE where you need to press the buttons exactly at the same time |
| 16:03:33 | Blue_Dude | amiconn: the button code doesn't care whether a key is depressed, held, or released. It's all the same. |
| 16:04:09 | kugel | Blue_Dude: how about you fix the yesno screen to clear the button state? |
| 16:04:09 | Blue_Dude | pixelma: Almost. With BUTTON_NONE, you'd have to release the buttons at the same time. |
| 16:04:14 | pixelma | Blue_Dude: surely there was a reason those three states got intruduced |
| 16:04:33 | amiconn | Blue_Dude: That means you need to fix the real problem. The real problem is that the yesno screen interprets leftovers from the previous context |
| 16:04:43 | Blue_Dude | pixelma: What I meant was, you can trigger on any of those three events and it's OK. |
| 16:04:56 | pixelma | only if you have the release in the button combo event |
| 16:05:19 | pixelma | if something else is hit on the same button's release event that's a different story |
| 16:05:37 | Blue_Dude | amiconn: I looked at that first. But the problem isn't in the yes/no screen, it's in action.c. But you'd have to program action.c to ignore key releases and you can't do that. |
| 16:06:08 | amiconn | Iirc there even *is* context-change code already |
| 16:06:19 | amiconn | It's probably just not used, or not used properly |
| 16:07:56 | kugel | Blue_Dude: button_clear_queue()? |
| 16:08:05 | | Quit mt-phone (Ping timeout: 248 seconds) |
| 16:08:06 | Blue_Dude | amiconn: yes, but consider the sequence: press the combo buttons, the event fires, context switches, one keypress release occurs slightly behind the other, then action.c reads that release as an ACTION_UNKNOWN, and yes/no dismisses itself. |
| 16:08:24 | kugel | hacking action.c won't help since it will be wrong on the next tick again, you'd really need to reset it at the button driver level |
| 16:08:32 | amiconn | As I said - the problem is in the yesno screen |
| 16:09:36 | Blue_Dude | Amiconn: Maybe. But then we'd need a "no" key instead of no being "anything" but "yes". "Anything" is defined in action.c and it's very broad. |
| 16:10:08 | * | kugel feels ignored |
| 16:10:28 | Blue_Dude | kugel: I tried button_clear_queue. But still the keypress release will fire afterwards. |
| 16:11:26 | amiconn | DON'T clear the queue unless there are *very* special reasons! |
| 16:11:39 | amiconn | It would be a huge annoyance if you do |
| 16:11:43 | Blue_Dude | And it doesn't work anyway so it's moot. |
| 16:11:52 | kugel | amiconn: why? |
| 16:12:25 | amiconn | And the yesno screen should interpret anything but 'yes as 'no', 'anything' meaning any *valid* button |
| 16:12:37 | amiconn | ACTION_UNKNOWN is certainly not valid |
| 16:12:48 | Blue_Dude | amiconn: A key release to action.c *is* a valid button. |
| 16:13:01 | amiconn | kugel: Clearing the queue destroys the possibility to press button sequences ahead of the gui |
| 16:13:21 | amiconn | Blue_Dude: A release after context change is certainly not valid |
| 16:13:31 | kugel | amiconn: ACTION_UNKNOWN is exactly 'anything but yes', it gets fired if it couldn't find a matching combo |
| 16:13:50 | kugel | amiconn: acceptable in the yesno screen |
| 16:13:58 | | Quit wodz (Quit: Leaving) |
| 16:14:12 | Blue_Dude | As I said, we'd need a "no" key to avoid this problem. |
| 16:14:18 | amiconn | Clearing the queue is not acceptable. Sometimes I'm pressing 3 or 4 buttons ahead of the gui |
| 16:14:31 | kugel | the yesno screen is different |
| 16:14:44 | Blue_Dude | Even ACTION_STD_CANCEL would work. |
| 16:14:52 | kugel | it something you need to pay attention to, you can't really be ahead of a yesno screen |
| 16:14:57 | pixelma | sounds a bit weird that a release event can hit without the check that the key was presed before (as I understand happens if context changes) |
| 16:15:01 | amiconn | Lihmm |
| 16:15:05 | amiconn | -Li |
| 16:15:49 | kugel | I'm also doing that, but that's not something I want for the particular yesno screen (it often led me to accidental decisions there) |
| 16:17:20 | Blue_Dude | Or... We could be unconventional in an unusual situation and fire an event on key release. Which is what I did. |
| 16:18:04 | kugel | Blue_Dude: accidental decissions in the yesno screen isn't only a problem on the target you're dealing with |
| 16:18:12 | pixelma | it sounds highly illogical though (more like a hack) |
| 16:19:35 | Blue_Dude | Unconventional. Not a hack though, or an exploit. Unconventional though. |
| 16:20:26 | Blue_Dude | kugel: You're going to run into problems in the yes/no screen anytime you enter one with a key already pressed. |
| 16:20:42 | Blue_Dude | The combo just exposed it. |
| 16:21:02 | kugel | that's what I mean, hence the yesno screen should be fixed |
| 16:21:46 | Blue_Dude | kugel: So either action.c has to ignore a key release event after a context switch, or you need a "no" key. |
| 16:21:58 | | Join mt-phone [0] (~mtee@41.91.181.135) |
| 16:22:13 | kugel | I think there needs to be another way |
| 16:22:34 | Blue_Dude | But if you "fix" action.c I fear unintentional consequences that might be hard to track down. |
| 16:23:18 | kugel | I could also imagine that it doesn't even start calling get_action() for half a second or so to leave enough time to release buttons safely |
| 16:24:15 | Blue_Dude | That would work. Just wait HZ/2 before getting a button? |
| 16:25:22 | Llorean | I don't really like "dead" periods where you can't press a button. |
| 16:25:37 | Llorean | It puts an artificial throttle on people who do know what they're doing and just want to click through, since sometimes keypresses might vanish? |
| 16:25:48 | | Join watto [0] (~watto@193.203.81.165) |
| 16:26:19 | Blue_Dude | Well... I'm not sure if the release event would be cached anyway and read whenever the get_action is called. Which means a dead space, followed with a button_queue_clear. |
| 16:26:35 | Blue_Dude | Which is two no-no's in one! |
| 16:27:29 | Blue_Dude | On the other, other hand, yes/no screens are meant only for actions that require some deliberate choice, so forcing the queue clear might be desirable. |
| 16:28:46 | | Quit ssorgatem (Ping timeout: 248 seconds) |
| 16:30:19 | | Quit kugel (Ping timeout: 258 seconds) |
| 16:31:40 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 16:31:52 | kugel | Llorean: acceptable in the yesno screen, IMO. on desktop OSes there are also often situations where the ok button of a dialog is greyed out for a period of time in order to prevent missing important information |
| 16:32:19 | pixelma | that's not a reason to like this behaviour ;) |
| 16:32:33 | Llorean | kugel: But Yes/No is something you may see often and rapidly, for example while trying to remove/delete several files. |
| 16:32:49 | kugel | I see it very rarely |
| 16:33:20 | Blue_Dude | How long do you really need to release a key? Half a second seems like a long time to me. |
| 16:33:23 | Llorean | Also, anything that silently eats a keypress is bad as a general rule. |
| 16:33:31 | kugel | but deleting files is a perfect example where accidental choices should be avoided at all costs |
| 16:33:41 | Llorean | If you press something and there's no feedback whether something happened or not, it's not good, especially if blind. |
| 16:33:47 | Blue_Dude | ^^^ agree with kugel here. |
| 16:33:59 | Llorean | kugel: Isn't the default option "no" anyway? |
| 16:34:08 | Llorean | The accidental choice is going to be *not* to delete the file. |
| 16:34:33 | kugel | it's not the default one, it entirely depends on the button state when you enter |
| 16:34:48 | Llorean | But if you eat a keypress that was intentional, that *will* cause accidental choices. |
| 16:34:56 | Llorean | You're creating accidents in the name of avoiding them. |
| 16:35:14 | kugel | it's not an accident |
| 16:35:27 | Blue_Dude | Is there really a problem with entering a decision screen with a clean slate? Even if it take a fractional second to achieve it? |
| 16:35:35 | Llorean | It's not an accident when someone expects the cursor to be in one place and it's somewhere else because you ignored their button press? |
| 16:35:35 | kugel | we can make it visible that for a period a button press has no effect |
| 16:35:50 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.146) |
| 16:35:59 | Llorean | Blue_Dude: Half a second is a considerable amount of time. |
| 16:36:09 | Llorean | Anything over about 100ms is a visible lag in response. |
| 16:36:34 | Llorean | Well, I mean, anything over one frame can be visible to some people |
| 16:36:41 | Blue_Dude | Llorean: I agree. But you don't really want to "cache" a yes decision do you? |
| 16:36:44 | kugel | it would take more than 100ms to even realize a yesno screen appeared |
| 16:36:47 | Llorean | But over all, you have about 1/10 of a second or so before things can feel 'unresponsive' |
| 16:37:05 | Llorean | kugel: Assuming you don't know it's coming, maybe... |
| 16:37:16 | Llorean | kugel: You're basically ignoring that you only get surprised by it once. |
| 16:37:19 | kugel | it won't be unresponsive if we make it clearly visible |
| 16:37:36 | Llorean | Blue_Dude: Clearing the queue is very different from introducing a delay of half a second once the screen is entered. |
| 16:37:58 | Llorean | kugel: No, but it will still be frustrating to anyone who's used to current behaviour and isn't in the habit of randomly and blindly pressing buttons. |
| 16:38:09 | | Quit mc2739 (Ping timeout: 276 seconds) |
| 16:38:42 | kugel | that means you never pressed a key accidentally? |
| 16:38:51 | Blue_Dude | Llorean: Again, I agree that 1/2 is too long. We only need a fraction of that to make sure a key is released. What is the expected reaction time of an experienced user to a new screen? 100 ms? 200ms? That's perceived lag. |
| 16:39:05 | Llorean | kugel: I've pressed a significant percentage more intentional keys than accidental ones. |
| 16:39:41 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 16:39:41 | Blue_Dude | Make it 1/5 of a second before it registers a decision. That should please even hardcore Rockbox file deleters. |
| 16:39:46 | Llorean | Blue_Dude: Why is _rel mapped to something on the yes/no screen? |
| 16:40:01 | Llorean | And why do you even need a delay, if you have to clear the queue anyway? |
| 16:40:10 | Blue_Dude | Llorean: Only accidentally. We've been discussing it for a while. |
| 16:40:46 | Llorean | 1/5 second (200ms) is still pretty long. |
| 16:40:53 | Llorean | Are people really having trouble with it as it exists currently? |
| 16:40:57 | kugel | 200ms is nothing |
| 16:41:01 | pixelma | Llorean: as I understood, everything is mapped in the yesno screen (one yes, everything else no) |
| 16:41:02 | Llorean | What yes-no screen is this? |
| 16:41:28 | Llorean | pixelma: Maybe _rel actions should simply not be mapped on it... |
| 16:41:32 | Llorean | That seems like it'd solve the problem |
| 16:41:50 | Blue_Dude | Llorean: we need time to release all keys after a yes/no screen pops up. Sometimes a key is still being held down for a fraction of a second after the yes/no screen is presented, and releasing that key means "no" and the yes/no screen dismisses. |
| 16:42:06 | Llorean | Blue_Dude: I've *never* had that happen to me. |
| 16:42:18 | Llorean | Which is why I asked if people are actually having this problem, or if it's theoretical at this point? |
| 16:42:33 | Blue_Dude | Llorean: well, there's a first time for everything. It doesn't happen often, but it does happen. |
| 16:42:52 | Llorean | Are people are actually having this problem, or if it's theoretical at this point? |
| 16:43:10 | Blue_Dude | Llorean: there are plenty of things to fix that aren't theoretical. I'm not spending time chasing ghosts. |
| 16:43:21 | pixelma | it's a problem with the hotkey key combo on Ipods |
| 16:43:22 | Blue_Dude | Not theoretical. A problem. |
| 16:43:31 | Llorean | So who did it happen to? |
| 16:43:33 | Llorean | Under what conditions? |
| 16:43:35 | Llorean | Which player? |
| 16:43:38 | kugel | Llorean: I've had this problem several times at least |
| 16:43:42 | | Part LinusN |
| 16:43:56 | Llorean | And again, why can't release actions just be ignored on that screen? |
| 16:44:11 | Blue_Dude | S_a_i_n_t saw it. I saw it and thought it was a sim problem. |
| 16:44:18 | Llorean | Also, if all other actions are "no" shouldn't release actions cancel the deletion of a file or change of a value, basically meaning it's fairly "safe" to cancel? |
| 16:44:28 | pixelma | which could have been discovered earlier as the playlist shortcut key combo was actually the same but no-one knew about it |
| 16:44:38 | Torne | (while we're at it, scrollwheel actions on touch-scroll targets should also do nothing on yesno screens. Ther eis a FS# for this) :) |
| 16:44:50 | Blue_Dude | Llorean: yes, it's safe, but it means that unless your timing is perfect, you can't ever select "yes". |
| 16:44:59 | Llorean | I don't understand why the UI needs a delay to solve a problem with an action that shouldn't have an effect in the screen. |
| 16:45:11 | Llorean | Blue_Dude: Why do you need perfect timing to select yes? |
| 16:45:26 | Blue_Dude | pixelma: Probably the playlist shortcut wouldn't have resulted in a yes/no screen, so maybe not. |
| 16:45:45 | Llorean | And nobody's yet answered why "release" can't be ignored, skipping to later questions of mine... |
| 16:46:01 | Llorean | What's the deal with it? It seems like a much more friendly solution to the problem since it wouldn't introduce UI lags and such |
| 16:46:20 | Blue_Dude | Llorean: because releasing a key in the yes/no screen means no. And unless all keys are released instantaneously, it's going to read it as a no. |
| 16:46:35 | kugel | Llorean: we haven't had this idea before so someone needs to come up with a patch so we can evaluate it |
| 16:46:36 | Llorean | Blue_Dude: Yes, which is why I'm asking why we can't make "release" do *nothing* instead |
| 16:46:58 | Torne | I can't find the FS# for the change to make yesno ignore the scrollwheel |
| 16:47:00 | Llorean | Blue_Dude: Obviously you can't release a key without pressing a key, so the press would mean "no" if it's a new press, and if there's not a new press, then it's a release from a pre-screen press and can safely be ignored |
| 16:47:01 | Torne | it has a patch, though |
| 16:47:06 | Blue_Dude | Llorean: if you can think of a clean way to mod get_action to ignore key releases in that context, that would be great. |
| 16:47:06 | JdGordon | pixelma: I think icatcher is a good example of where to not use the suggested new tag... conditionals inside conditionals will not make those lines any easier |
| 16:47:21 | Llorean | Blue_Dude: Why don't you accept the releases, but do nothing on them? |
| 16:48:06 | kugel | Blue_Dude: could { ACTION_NONE, BUTTON_REL, BUTTON_NONE } in the yesno keymaps work? |
| 16:48:08 | Blue_Dude | Llorean: the button code is returned by get_action, not the yes/no code. You don't *want* get_action to ignore key releases. |
| 16:48:55 | Llorean | Blue_Dude: Can't the yes/no code decide what to do based on button pressed? Surely somewhere there's logic that says "if select is pressed, do "yes", otherwise do "no"". Can't other cases be added into this? |
| 16:49:01 | Llorean | I find it hard to believe that this code is immutable. |
| 16:49:15 | Blue_Dude | kugel: it might, but "BUTTON_REL" isn't a valid keypress in itself. It's a modifier. So you'd need to OR it with every valid keypress. |
| 16:49:19 | kugel | I assume ACTION_NONE doesn't result in a no decision, but I don't know whether BUTTON_REL alone works for all combos possible with BUTTON_REL |
| 16:49:35 | JdGordon | amiconn: with something that isnt really time critical at all, how many bits of current_Tick would be needed to give some sort of reasonable timing? like could I get away with just the bottom 16bits or so? |
| 16:49:55 | JdGordon | only need to store it to be able to determine if X ticks has passed |
| 16:50:33 | kugel | Blue_Dude: BUTTON_NONE is a special case too, so we could either make BUTTON_NONE|BUTTON_REL, or BUTTON_REL or even a BUTTON_ANY|BUTTON_REL mask out release actions |
| 16:50:43 | Blue_Dude | Llorean: Adding cases is what kugel is trying to come up with. |
| 16:51:06 | Blue_Dude | BUTTON_ANY? Is that valid? |
| 16:51:13 | kugel | not yet ;) |
| 16:51:19 | Blue_Dude | Oh, OK. :) |
| 16:52:27 | kugel | JdGordon: the bottom 16 bits should be fine |
| 16:52:41 | kugel | it will only wrap more often, but it's still equally accurate |
| 16:52:51 | JdGordon | nup :/ value.i is a short |
| 16:53:05 | JdGordon | unless I do naughty things with the void* union member |
| 16:53:24 | kugel | why is value.i not an int instead? |
| 16:53:42 | JdGordon | probably nonesense false economies |
| 16:53:46 | kugel | or a long even, it will always be smaller than a pointer so it wouldn't even make the union bigger |
| 16:54:01 | kugel | (smaller or the same) |
| 16:54:08 | JdGordon | struyct wps_token |
| 16:54:31 | | Quit mc2739 (Ping timeout: 264 seconds) |
| 16:58:24 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
| 16:58:25 | JdGordon | pixelma: I'm going to make %t<timeout> conditionable :D |
| 16:58:39 | kugel | JdGordon: nonsense false economics seems the appriopriate description :) |
| 16:59:08 | | Join Kitr88 [0] (~Kitar_st@BSN-182-6-63.dial-up.dsl.siol.net) |
| 16:59:16 | | Quit Kitar|st (Read error: Connection reset by peer) |
| 17:00 |
| 17:00:20 | | Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 17:02:19 | | Quit xiainx (Ping timeout: 264 seconds) |
| 17:03:34 | | Quit Kitr88 (Ping timeout: 252 seconds) |
| 17:05:37 | | Quit robin0800 (Remote host closed the connection) |
| 17:05:58 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 17:09:03 | | Join Kitar|st [0] (Kitar_st@89.142.227.194) |
| 17:09:30 | | Quit Coyote (Quit: CGI:IRC) |
| 17:10:10 | *** | Saving seen data "./dancer.seen" |
| 17:10:14 | | Quit Bagder (Quit: It is time to say moo) |
| 17:16:38 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 17:19:58 | JdGordon | http://www.rockbox.org/tracker/task/11210 |
| 17:23:51 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:29:12 | | Join xiainx [0] (xiainx@wpa106069.Wireless.McGill.CA) |
| 17:37:26 | | Quit petur (Quit: *plop*) |
| 17:38:05 | | Quit antil33t (Read error: Connection reset by peer) |
| 17:38:12 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 17:43:41 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 17:45:03 | S_a_i_n_t | JdGordon: nice work with FS #11210 |
| 17:45:25 | S_a_i_n_t | I'll do some pissing around with it when I can. |
| 17:54:35 | | Quit mt (Read error: Connection reset by peer) |
| 17:55:10 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 17:58:20 | | Quit Rondom (Ping timeout: 276 seconds) |
| 18:00 |
| 18:04:17 | pixelma | JdGordon: before the tokenizer you could put %t inside conditionals ;) |
| 18:05:42 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 18:07:09 | pixelma | if the suggested tag doesn't help with the long conditional lines as in iCatcher, then I still don't understand what makes it better than %t in every subline. It would only improve readability very slightly with the disadvantage that all sublines will have the same timeout |
| 18:07:13 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 18:07:25 | pixelma | maybe I miss some use case though |
| 18:09:37 | | Join lpereira [0] (~lucien@79.92.12.142) |
| 18:10:46 | pixelma | and you sure can put images in sublines... I even use it in my WPS (though rarely see it which is why I forgot about it :) ) |
| 18:11:01 | | Quit mikroflops (Ping timeout: 246 seconds) |
| 18:12:07 | | Quit S_a_i_n_t () |
| 18:16:55 | | Quit adnyxo (Ping timeout: 276 seconds) |
| 18:17:25 | pixelma | that's all what the long line in iCatcher is for too |
| 18:26:17 | | Quit xiainx (Ping timeout: 276 seconds) |
| 18:29:35 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 18:30:26 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 18:31:54 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 18:32:58 | | Quit liar (Ping timeout: 258 seconds) |
| 18:38:46 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.82) |
| 18:39:28 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 18:40:12 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 18:41:12 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 18:41:21 | | Quit halmi (Quit: halmi) |
| 18:41:29 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 18:41:51 | | Join mikroflo1s_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 18:43:14 | | Quit mikroflops_ (Ping timeout: 240 seconds) |
| 18:43:34 | | Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 18:43:35 | | Quit DataGhost (Changing host) |
| 18:43:35 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
| 18:45:39 | | Quit mikroflops (Ping timeout: 246 seconds) |
| 18:45:51 | CIA-5 | New commit by b0hoon (r25678): Packard Bell Vibe: imageviewer - add button to quit immediately, like in r24904. |
| 18:49:41 | * | pixelma wishes B0hoon was around |
| 18:50:29 | | Quit CaptainKewl (Remote host closed the connection) |
| 18:50:41 | pixelma | then I could tab complete his nick correctly too |
| 18:51:31 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 18:51:33 | | Quit shaggy-h (Remote host closed the connection) |
| 18:52:21 | | Join ssorgatem [0] (~ssorgatem@83.60.250.4) |
| 18:54:19 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 18:54:36 | | Join kugel_ [0] (~kugel@e178125151.adsl.alicedsl.de) |
| 18:54:52 | | Quit kugel (Disconnected by services) |
| 18:54:56 | | Nick kugel_ is now known as kugel (~kugel@e178125151.adsl.alicedsl.de) |
| 18:55:00 | | Quit kugel (Changing host) |
| 18:55:00 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 18:55:26 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 18:56:21 | | Quit stripwax (Client Quit) |
| 18:58:42 | | Quit mikroflo1s_ (Ping timeout: 264 seconds) |
| 19:00 |
| 19:01:06 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 19:02:09 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 19:02:47 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 19:03:07 | CIA-5 | New commit by b0hoon (r25679): Packard Bell Vibe: manual - add a few plugin keymaps. |
| 19:05:57 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 19:06:47 | | Quit mikroflops (Ping timeout: 260 seconds) |
| 19:08:19 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 19:09:25 | | Join b0hoon [0] (~quassel@xdsl-7253.bielsko.dialog.net.pl) |
| 19:09:40 | S_a_i_n_t | there 'ya go pixelma |
| 19:10:12 | *** | Saving seen data "./dancer.seen" |
| 19:10:26 | b0hoon | someone called me? ;) |
| 19:10:44 | S_a_i_n_t | I believe pixelma was looking for you... |
| 19:12:07 | | Quit mikroflops_ (Ping timeout: 240 seconds) |
| 19:12:36 | b0hoon | yes but pixelma is away now |
| 19:12:47 | b0hoon | pixelma: ping |
| 19:13:01 | S_a_i_n_t | Can anyone tell me why sometimes the database is committed immediately after its initialised, and sometimes you need to reboot the player? |
| 19:13:23 | S_a_i_n_t | I haven't figured out the connection between the two. |
| 19:14:27 | | Quit xiainx (Ping timeout: 252 seconds) |
| 19:14:57 | S_a_i_n_t | And, unrelated to the previous question...why do only half of the screens in the dubug section use the .sbs? |
| 19:16:03 | | Quit chamunks (Remote host closed the connection) |
| 19:16:51 | | Quit toffe82 (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 19:19:43 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 19:21:00 | kugel | S_a_i_n_t: the debug menus were never supposed to be GUI sugar |
| 19:21:08 | | Quit DerPapst (Quit: Leaving.) |
| 19:21:18 | kugel | some were converted to the simplelist api which automagically includes theming though |
| 19:21:58 | topik | funman: is the svn bootloader for clip+ broken? |
| 19:22:03 | kugel | re: database, the database has some backup buffer to grow without reboot. if that backup buffer is not enough you'll need to reboot |
| 19:23:39 | | Quit mikroflops (Ping timeout: 264 seconds) |
| 19:24:24 | S_a_i_n_t | kugel: Aha, TBH, I thought it was kinda odd that any of them used the .sbs/backdrop at all. For the reason you said, it's a debug menu, not anything fancy-tech-eyecandy looking. I just couldn't find any reason why screen X includes the .sbs/screen Y includes the backdrop, but not the .sbs/screen Z includes neither. |
| 19:24:33 | S_a_i_n_t | It seemed weird to me, that's all.' |
| 19:25:34 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
| 19:25:40 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 19:25:41 | Blue_Dude | Someone help me out here: does some pitchscreen info get used even in hwcodec targets? |
| 19:26:04 | Blue_Dude | Rate only maybe? |
| 19:26:40 | ssorgatem | funman: hi |
| 19:27:17 | | Join Boldfilter [0] (~Boldfilte@adsl-82-106-223.jax.bellsouth.net) |
| 19:27:28 | * | domonoky thinks only the combined pitch/speed settings are possible on hwcodec. |
| 19:28:44 | amiconn | domonoky thinks right - and the Player is excluded (the trick only works on MASF) |
| 19:29:09 | | Quit liar (Quit: Verlassend) |
| 19:29:39 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 19:30:14 | | Join liar_ [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 19:30:40 | | Quit liar (Client Quit) |
| 19:30:47 | | Quit liar_ (Read error: Connection reset by peer) |
| 19:31:09 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 19:32:39 | Blue_Dude | OK. I was going back to update the manual to document pitch and speed information in bookmarks and found that sometimes other targets use pitchscreen. So far only swcodec targets save pitchscreen info in bookmarks though. |
| 19:35:40 | | Quit esperegu (Remote host closed the connection) |
| 19:36:35 | funman | topik: i don't know, why ? do you mean the bootloader built from svn? |
| 19:37:20 | funman | ssorgatem: hi, i haven't done anything (yet) you could try on fuzev2, do you still have the last patch I gave you ? (which was supposed to test left key) |
| 19:38:11 | topik | i do funman. i removed rockbox from my clip+ after it went unusable but i rather have unusable rockbox than OF |
| 19:38:37 | topik | with the bootloader i compiled myself i couldn't get it to reach the rockbox main menu |
| 19:38:46 | funman | get the prebuilt bootloader |
| 19:39:06 | topik | i did, but that lead to my question |
| 19:39:21 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 19:39:27 | ssorgatem | funman: yes, I have it |
| 19:39:50 | ssorgatem | funman: and left button doesn't work, still |
| 19:39:53 | funman | topik: it could be broken but since we have a known to work binary bootloader (and corresponding svn revision) i won't look at why it's broken |
| 19:40:13 | funman | ssorgatem: can you paste the patch again? So I can add what could make it work |
| 19:40:17 | topik | fair enough |
| 19:40:19 | ssorgatem | funman: ok |
| 19:41:50 | | Quit Boldfilter (Quit: Boldfilter) |
| 19:42:43 | ssorgatem | funman: http://pastebin.com/KGRxbh4T |
| 19:47:37 | Blue_Dude | There's a possibility that rate information for hwcodec targets can be stored in bookmarks, if anyone wants to pursue it. I know nothing about how pitchscreen works on them though. |
| 19:47:56 | Blue_Dude | Manuals are updated for swcodec. |
| 19:49:03 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 19:49:22 | funman | ssorgatem: http://pastebin.com/nDrjjY1h |
| 19:50:15 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 19:51:11 | * | ollebe has started writing the first driver speicific to E10 :) |
| 19:52:13 | funman | ollebe: nice, what are you writing? |
| 19:52:23 | CIA-5 | New commit by Blue_Dude (r25680): Manual update to document pitchscreen info saved in bookmarks on swcodec targets |
| 19:52:38 | ollebe | control code for the Cirrus Logic ADC |
| 19:54:20 | Blue_Dude | OK, next project: software mixer. I can't give it up. |
| 19:54:41 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 19:55:58 | Blue_Dude | I'm writing a section of pcmbuf that will switch out the data fed to the DMA on the fly, according to whether it's supposed to have more than one source. If one source, no change. If more than one source, it starts mixing with *really* low latency and feeds the result to the DMA. |
| 19:56:02 | Blue_Dude | It's a bit tricky. |
| 19:56:56 | Blue_Dude | If two sources are being fed, and one source is paused, then switch back to the other source exclusively. |
| 19:57:14 | | Quit petur (Quit: Leaving) |
| 19:57:20 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 19:58:04 | Blue_Dude | I don't know yet whether it can switch fast enough to be imperceptible, i.e. no clicks in audio. If not, then the whole thing might have to be redone. |
| 19:59:39 | | Join francis_23409890 [0] (~francis@cpc1-stev6-2-0-cust287.9-2.cable.virginmedia.com) |
| 20:00 |
| 20:00:01 | ollebe | blue_dude: nice, what are the applications for SW mixing going to be though? |
| 20:00:27 | Blue_Dude | Voice, pcmbuf_beep, keyclicks. Game audio :). |
| 20:00:35 | ssorgatem | funman: |
| 20:00:36 | ssorgatem | dualboot.S: Assembler messages: |
| 20:00:38 | ssorgatem | dualboot.S:241: Error: undefined symbol x500 used as an immediate value |
| 20:01:26 | ssorgatem | funman: and then make exits with Error 1 |
| 20:02:32 | Blue_Dude | ollebe: the functionality is already there, but there are limitations. Can't pause while continuing voice playback is a big one. |
| 20:05:02 | | Quit francis_23409890 (Quit: Leaving) |
| 20:05:37 | S_a_i_n_t | I've been wondering about http://forums.rockbox.org/index.php?topic=24508.msg165405#msg165405, does a statement saying "you can do what you want with it commercial or non-commercial" equate to GPL compliance? |
| 20:06:15 | ssorgatem | S_a_i_n_t: yes... provided you releasi it under the GPL |
| 20:06:20 | | Quit amiconn (Remote host closed the connection) |
| 20:06:21 | | Quit pixelma (Remote host closed the connection) |
| 20:06:53 | S_a_i_n_t | Aha...you mean release it "initially" undure GPL, right? |
| 20:07:02 | S_a_i_n_t | *under |
| 20:07:22 | S_a_i_n_t | Not just "here's this image, you can do what you want with it commercial or non-commercial" |
| 20:08:10 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
| 20:08:17 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 20:08:25 | ssorgatem | S_a_i_n_t: no, not initially |
| 20:08:43 | ssorgatem | S_a_i_n_t: well, I suppose the fsm is just under public domain |
| 20:09:26 | S_a_i_n_t | Hmmm, sweet. I just knew I had seen it somewhere before. I just couldn;t find anything regarding licensing about it though. |
| 20:09:41 | | Quit bmbl (Quit: Bye!) |
| 20:10:14 | ssorgatem | S_a_i_n_t: so it's GPL-compatible, that means, includeable in rockbox |
| 20:10:32 | funman | ssorgatem: hmm the 'x' is a typo, it should have been "#500" |
| 20:10:44 | ssorgatem | funman: Ok |
| 20:11:21 | | Join DerPapst [0] (~Alexander@p5797C2AF.dip.t-dialin.net) |
| 20:11:46 | Blue_Dude | S_a_i_n_t: give FS #11208 a try and see if it solves your hotkey problem. It might, or it might just peel back another layer. Let me know. |
| 20:12:47 | S_a_i_n_t | Sweet, I can build it from here...but I can't try it on device until later on in the day. I will however, let you know. ;) |
| 20:13:02 | ssorgatem | funman: updating firmware |
| 20:13:44 | ssorgatem | funman: left button doesn't work |
| 20:14:51 | ssorgatem | funman: it seems to behave just like the previous patch |
| 20:16:00 | | Join thinkpadx61 [0] (~thinkpadx@198.225.34.95.customer.cdi.no) |
| 20:16:18 | funman | http://pastebin.com/ab0b5AEj |
| 20:16:53 | funman | I commented out a line (with a @) : can you try this patch, and if it doesn't work, try to uncomment the line which starts with bic and comment the one which starts with orr ? |
| 20:18:11 | ssorgatem | ok |
| 20:18:55 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 20:19:02 | | Join halmi [0] (~netbook@188.20.253.186) |
| 20:23:12 | ollebe | i think it's time to merge my e10 port into SVN. |
| 20:23:30 | ollebe | let's say i flysprayed a patch for it, would it be committed to SVN? |
| 20:23:43 | ssorgatem | funman: we're out of luck |
| 20:23:49 | ssorgatem | funman: neither works |
| 20:25:01 | ssorgatem | funman: also, a probably unrelated issue, is that i can't turn off the fuze from rockbox if the usb cable is plugged in |
| 20:25:11 | funman | it works in rockbox, so we can find what's missing. perhaps it's not in button-fuzev2.c |
| 20:25:26 | funman | ssorgatem: it's normal, because the fuze can't charge while it's off |
| 20:26:00 | ssorgatem | funman: but, is it charging while in rockbox? |
| 20:26:23 | bertrik | ollebe, we can't say in advance if stuff will be committed, but if it's a new target and the patch does not affect other targets too much, it should go in quite easily |
| 20:26:25 | funman | yes |
| 20:26:38 | ssorgatem | funman: or is poweroff limited by hardware when connected? |
| 20:27:10 | funman | rockbox just doesn't let it power down while charging (you can keep pressing and cause a hardware power-off though) |
| 20:27:33 | ollebe | bertrik: i'll wait a day or so until i have some more code... |
| 20:28:47 | bertrik | ollebe, a new target doesn't have to be perfect immediately, but it should at least compile without warnings (at least that's what I think), so yes please put up a patch |
| 20:29:04 | ollebe | it doesn't compile. |
| 20:29:10 | ssorgatem | funman: interesting: if I power on with the usb cable attached, rockbox isn't able to get to the menu, it keps showing the screen with the banner and the version number |
| 20:35:48 | | Quit antil33t (Read error: Connection reset by peer) |
| 20:35:55 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 20:37:20 | | Quit The_Seven (Ping timeout: 276 seconds) |
| 20:45:24 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 20:45:43 | pixelma | b0hoon: just wanted to say - if your Prev and Next button more or less saves as left and right, you might have an easier time to calle it \ButtonLeft or \ButtonRight internally (you can make it show "Prev" or "Next" though), this could save you a bit of work on the keymaps |
| 20:46:00 | pixelma | s/saves/serves |
| 20:49:09 | | Quit TillW (Quit: This now concludes our broadcast day.) |
| 20:50:11 | | Quit lpereira (Quit: Leaving.) |
| 20:50:52 | b0hoon | pixelma: yes, i've noticed it but unfortunately at the end.. and now i would like to end it like this, but of course if it is not good enough, i can change it? |
| 20:54:15 | | Join TillW [0] (~Till@h92-net09.simres.netcampus.ca) |
| 20:55:09 | funman | ssorgatem: http://pastebin.com/c6sGfK6i (i'll have another one after that) |
| 20:55:37 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 20:56:10 | pixelma | a pity. If it saves some \opt and \nopt I'd actually prefer this, the button tables are hard to read sometimes anyways but I really don't want to hold you back or discourage you :) |
| 20:56:37 | pixelma | ^ b0hoon |
| 20:57:59 | * | pixelma wonders about the weird build error in the last round |
| 20:58:04 | | Part watto |
| 20:58:42 | b0hoon | pixelma: it's not really a big problem but only a temporary, i think it will be good to end it like this and then i'll reformat it, ok? |
| 20:59:09 | pixelma | go ahead :) |
| 21:00 |
| 21:01:01 | ssorgatem | funman: with that last patch, rockbox doesn't get to the "flicker" |
| 21:01:57 | ssorgatem | funman: and left button doesn't work |
| 21:02:33 | b0hoon | pixelma: i just don't want to do a bigger mess with it now. :S |
| 21:02:34 | ssorgatem | funman: now it happens what i described you it happened before with the usb cable plugged, but wihout thw cable |
| 21:03:37 | funman | hm i don't understand what happens |
| 21:03:48 | funman | kugel might know ? I'm just copying bits from button-fuzev2.c |
| 21:04:23 | kugel | no idea |
| 21:04:51 | kugel | the button read routine doesn't really have conditionals could be for a different model |
| 21:05:01 | kugel | the OF one I mean |
| 21:06:19 | funman | ssorgatem: http://pastebin.com/tD2w60bi |
| 21:07:40 | | Nick hd is now known as jd (~jd@Wikipedia/HellDragon) |
| 21:08:44 | ssorgatem | funman: updating firmware |
| 21:09:09 | ssorgatem | rockbox can't load |
| 21:09:22 | funman | hm ? |
| 21:10:05 | ssorgatem | it gets stuck at the screen with the rockbox banner |
| 21:10:10 | ssorgatem | and the version number |
| 21:10:13 | *** | Saving seen data "./dancer.seen" |
| 21:10:15 | funman | weird |
| 21:10:27 | funman | i have made a typo anyway |
| 21:10:29 | ssorgatem | it happened before when -I booted with the usb plugged |
| 21:10:43 | ssorgatem | now it happens without usb cable |
| 21:10:46 | pixelma | b0hoon: I would hope that it is a smaller mess in the end but I can understand that you just want to finish this work now. It would be nice if it won't be forgotten afterwards though :) |
| 21:11:01 | ssorgatem | and left key isn't willing to cooperate |
| 21:11:05 | funman | damn me, the typo was there in the first patch |
| 21:11:48 | b0hoon | pixelma: of course, and i've changed my mind i will do it as the first thing :D |
| 21:12:12 | pixelma | :D |
| 21:12:40 | funman | ssorgatem: http://pastebin.com/q3S9RUps (equivalent to the first patch with the typo fixed) |
| 21:13:02 | ssorgatem | ok |
| 21:15:45 | | Join ssorgatem_ [0] (~ssorgatem@32.Red-88-25-167.staticIP.rima-tde.net) |
| 21:16:05 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
| 21:17:34 | ssorgatem_ | funman: IT WORKS! |
| 21:17:45 | ssorgatem_ | the firts patch with the typo solved |
| 21:17:56 | funman | hm then everything is good |
| 21:18:08 | gevaerts | kugel: doesn't sdl audio still use sdl threads internally? Maybe that's messing things up? |
| 21:18:29 | ssorgatem_ | and rockbox loads ok |
| 21:18:37 | ssorgatem_ | regardless of usb cable plugged or not |
| 21:19:03 | kugel | gevaerts: pth completely isolated, sdl doesn't even see that there are other threads |
| 21:19:09 | gevaerts | ah, right |
| 21:19:20 | gevaerts | well, it should anyway |
| 21:19:30 | kugel | which is btw the reason I need to SDL_PollEvent instead of SDL_WaitEvent for button reading |
| 21:19:48 | | Quit ssorgatem (Ping timeout: 276 seconds) |
| 21:20:15 | funman | ssorgatem_: http://pastebin.com/h2M7gF8h < much simpler diff, I added the check for center button just in case |
| 21:20:23 | kugel | on my mini2440 the sim killed immediately, not even the −−help text shows up |
| 21:22:23 | kugel | unfortunately I don't have enough space yet to install a native toolchain |
| 21:22:34 | | Join fml [0] (~chatzilla@port-83-236-234-85.static.qsc.de) |
| 21:23:33 | gevaerts | it wouldn't be very fast anyway :) |
| 21:24:01 | funman | kugel: what do you think of removing Fuzev2 USB check from mkamsboot? |
| 21:24:12 | kugel | not much |
| 21:24:18 | fml | I wonder whether there is a good solution to the problem experienced by S_a_i_n_t, blue_dude and co., i.e. a remaining button release after entering the yesno screen. I think it's a general problem, ie. not only yesno. |
| 21:24:32 | | Join wodz [0] (~wodz@chello087206240004.chello.pl) |
| 21:24:33 | kugel | I'd rather not do it |
| 21:24:53 | fml | Would the solution proposed by amiconn always work? (Eat all outstanding release event upon context change) |
| 21:25:17 | funman | kugel: perhaps it would be possible to fix the detection instead but i'm not sure how |
| 21:25:43 | kugel | it's not like we have the responsiblity to make it boot on each individual device (and in fact, ssorgatem_'s fuzev2 seems to be the only problemtic one), not in it's current unusable state anyway |
| 21:25:46 | S_a_i_n_t | fml: Who knows dude....it apparently needs some rather complex "bugger-assing-around" with the keymaps. |
| 21:26:09 | fml | The problem is easily reproducible e.g. on the e200 sim. Just press the button which is to be pressed to enter the yesno screen long enough. |
| 21:26:10 | funman | kugel: it's not a responsibility, but rather a goal ;) |
| 21:27:08 | kugel | the left button detection isn't 100% reliable too it seems, so I think there should be at least 1 safe way to boot the OF |
| 21:27:15 | fml | S_a_i_n_t: no, it would require no changes in keymaps. One change in one place (where context changes) −− and work for all. |
| 21:27:19 | funman | kugel: is it ? |
| 21:28:03 | gevaerts | kugel: one buglet: your patch uses sleep() in two places, but it uses it as if sleep has a HZ resolution. On unix, sleep() is in seconds. You probably want usleep() |
| 21:28:16 | gevaerts | not that this fixes anything |
| 21:28:35 | kugel | gevaerts: what patch? |
| 21:28:40 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 21:28:53 | gevaerts | kugel: sorry, branch |
| 21:28:58 | kugel | sleep() is the rockbox' sleep() |
| 21:29:11 | kugel | kernel.c defines it, and that's compiled in |
| 21:29:24 | gevaerts | well, libc is also compiled in... |
| 21:29:32 | * | gevaerts doesn't know who wins |
| 21:30:39 | kugel | yes, but only missing symbols are taken from libraries |
| 21:30:39 | gevaerts | I'll check |
| 21:30:39 | kugel | the fact that button reading works fine proves it :) |
| 21:30:39 | ssorgatem_ | funman: it works |
| 21:30:39 | gevaerts | yes, probably |
| 21:30:49 | fml | Hrm... The code in action.c is not trrivial... |
| 21:31:52 | funman | ssorgatem_: cool, so we just need to remove or fix the USB check |
| 21:31:52 | fml | I wonder if the comment in action.c:211 is an explaining comment or a TODO mark. |
| 21:31:52 | | Nick ssorgatem_ is now known as ssorgatem (~ssorgatem@32.Red-88-25-167.staticIP.rima-tde.net) |
| 21:33:28 | kugel | gevaerts: the sims work for years with sleep() now btw, I don't see how my branch should change that :P |
| 21:36:05 | kugel | gevaerts: you said crashes within __pth_schedule, right? |
| 21:36:26 | gevaerts | kugel: it used to. Now it hangs somewhere in libc with a corrupted stack |
| 21:36:35 | gevaerts | I'm trying to step through the thing now |
| 21:37:28 | kugel | yea, corrupted stack was the main source the prblems I had |
| 21:38:50 | kugel | the tack is malloc'd, except for the implicit main thread |
| 21:38:54 | kugel | stack* |
| 21:39:19 | ssorgatem | so, in the end, why didn't my left button work? I'm curious about it :). The last patch isn't precisely huge. It seems like only removing a condition from an if statement... but I'm not even sure about in what language it's written 8) |
| 21:39:43 | funman | ssorgatem: it always worked |
| 21:40:16 | funman | the patch just removes the USB check (that's written in C preprocessor by the way, the code itself is assembly) |
| 21:40:25 | funman | it removes it, for the Fuzev2 case only |
| 21:40:39 | funman | ideally we would figure how to make USB detection work |
| 21:40:54 | funman | it will be needed for Clip+ as well |
| 21:42:39 | ssorgatem | is there any way I could help? |
| 21:43:18 | funman | without coding, testing when we have something to test |
| 21:43:35 | ssorgatem | ok |
| 21:47:34 | | Join CaptainKewl [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 21:47:47 | gevaerts | kugel: it seems that right now pth_init() never returns |
| 21:48:13 | CIA-5 | New commit by alle (r25681): Fix typo in comment |
| 21:48:51 | | Quit xiainx (Ping timeout: 248 seconds) |
| 21:49:44 | CIA-5 | New commit by alle (r25682): Fix typo in comment in the other file as well |
| 21:50:37 | kugel | gevaerts: that's very strange |
| 21:50:42 | | Quit jordan` (Read error: No route to host) |
| 21:50:58 | kugel | have you tried static linking? |
| 21:51:29 | gevaerts | on my phone pth is linked statically, yes. I haven't traced there, but the symptoms are the same |
| 21:51:36 | gevaerts | I'll try soon |
| 21:51:39 | kugel | hm, otoh the test app succeeds, that all makes no sense |
| 21:52:42 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 21:52:56 | kugel | we only have x86 assembly in codecs, right? |
| 21:53:09 | gevaerts | ? |
| 21:53:44 | | Join saratoga [0] (~9803c20d@gateway/web/freenode/x-baxicqtqtloaaxba) |
| 21:53:48 | | Quit saratoga (Changing host) |
| 21:53:48 | | Join saratoga [0] (~9803c20d@rockbox/developer/saratoga) |
| 21:53:59 | saratoga | afaik APE is the only place using x86 ASM |
| 21:54:00 | | Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) |
| 21:54:10 | kugel | I'm not sure if our build system is intelligent enough to see that it's not an x86 sim; but the fact that it compiles probably means it is |
| 21:54:14 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 21:56:39 | wodz | Do the threads[] array contain all informations about running processes in rockbox? |
| 21:57:17 | wodz | I mean if I force brake in debugger |
| 21:57:44 | kugel | yes, cores[] contains the current thread |
| 21:59:06 | wodz | is cores[].running pointer to thread function? |
| 21:59:27 | thinkpadx61 | i would like the "The" in artist name (The Beatles, The Kinks etc) to be ignored in database view ... is this a feature in Rockbox? |
| 21:59:29 | kugel | no, a pointer to the threads[] entry |
| 21:59:29 | ollebe | is there a good way to quickly make a compiling keymap c file? |
| 22:00 |
| 22:00:09 | kugel | thread[].context.start has the function |
| 22:00:27 | wodz | ollebe: if You change file simply run make and only changed portion will be recompiled |
| 22:00:38 | kugel | so, cores[0].running->context.start gives you the thread entry point |
| 22:01:01 | ollebe | wodz: i know that but it's no answer to my question... |
| 22:01:43 | ollebe | i'wodz: i'm trying to write a keymap c file but it's tedious and boring |
| 22:01:46 | fml | Do we have some problems in the build system? |
| 22:02:03 | | Quit xiainx (Ping timeout: 276 seconds) |
| 22:02:20 | S_a_i_n_t | thinkpadx61: No, that would require some editing. |
| 22:02:30 | S_a_i_n_t | I'm looking for the wiki link for you now. |
| 22:03:23 | funman | ollebe: copy the keymap from another model |
| 22:03:42 | wodz | kugel: Is there a way to say what is blocking some thread? (so it has status = 2) |
| 22:03:45 | ollebe | funman: done that, but is there a model similar to E10? |
| 22:04:06 | ollebe | i have to make approx 1K changes... |
| 22:04:08 | funman | no idea, you can check the keys of each target in their button-target.h files |
| 22:04:13 | kugel | wodz: yes, I believe so |
| 22:04:26 | kugel | there sould be a blocker member in the thread_entry struct |
| 22:05:42 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 22:05:46 | S_a_i_n_t | thinkpadx61: http://www.rockbox.org/wiki/DataBase |
| 22:06:02 | wodz | bqp member? |
| 22:06:03 | saratoga | ollebe: the plus shaped buttons resemble the gigabeat players, although its missing some buttons |
| 22:06:04 | S_a_i_n_t | specifically, the tagnavi info. |
| 22:06:29 | ollebe | saratoga: ok thanks |
| 22:06:31 | kugel | wodz: I don't know what you mean by status=2 |
| 22:07:24 | kugel | wodz: that or the blocker member itself |
| 22:07:24 | wodz | http://pastebin.com/pX02CzAd |
| 22:08:16 | kugel | wodz: have you looked at thread.h? it lists all members with some comments as well |
| 22:08:42 | wodz | kugel: sure but I am a bit lost in all this |
| 22:08:53 | kugel | I think bqb is only used for mutex/semaphores |
| 22:10:17 | kugel | wodz: is your target hwcodec? |
| 22:10:24 | wodz | no |
| 22:10:39 | wodz | the paste was from sim in gdb |
| 22:11:01 | kugel | you don't have the blocker member, something is wrong there. HAVE_PRIORITY_SCHEDULING should be defined for your target |
| 22:11:24 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 22:13:12 | pixelma | S_a_i_n_t, thinkpadx61: you can't make the database ignore "the" by editing the tagnavi file (you can catch all artists starting with "the" in an own group maybe but nothing more). This is currently not a feature in Rockbox and due to the fact that it only works for English it's not the way that's wanted. The goal is to implement search tags and let the database sort after those "behind the scene" but it hasn't been implemented that |
| 22:13:47 | pixelma | or yet |
| 22:14:14 | S_a_i_n_t | I thought you could put it in a catchall for "the" titles, then strip the first 4 chars? |
| 22:14:50 | wodz | kugel: greping for HAVE_PRIORITY_SCHEDULING gives only two hits in config.h |
| 22:15:20 | kugel | yes, one is for all SWCODEC targets (and !BOOTLOADER), the other is for imx.31 bootloader |
| 22:15:30 | | Part fml |
| 22:15:59 | pixelma | S_a_i_n_t: as I understand it would still sort including the "The", just not display it |
| 22:16:19 | S_a_i_n_t | Well, it's a start... |
| 22:16:34 | wodz | kugel: You are right. |
| 22:16:48 | wodz | so in sim I will not see this |
| 22:17:18 | kugel | you're in the sim? |
| 22:17:35 | kugel | i thought you're on target |
| 22:18:05 | kugel | the sim can't really be used for problems with threads, it's quite a different scheme |
| 22:19:21 | pixelma | S_a_i_n_t: for going into the wrong direction? You'll find "Beatles" "Who" etc. between I don't know TaSomething and Uriah Heap or so |
| 22:19:35 | gevaerts | kugel: I don't really understand the point of your 64u<<10 notation for stack sizes |
| 22:20:13 | kugel | habbit :) |
| 22:20:33 | gevaerts | it's hard to read :( |
| 22:20:36 | S_a_i_n_t | pixelma: All he asked for was for "The" to be ignored...so, that fits his request. |
| 22:20:50 | gevaerts | kugel: you have 15 seconds, how much is 64u<<10? |
| 22:20:51 | kugel | wodz: you could try checking out from kugel-rb.git/shortlog/refs/heads/gnu-pth-sim">http://repo.or.cz/w/kugel-rb.git/shortlog/refs/heads/gnu-pth-sim it does threading a little bit more rockbox like |
| 22:20:58 | kugel | 64k |
| 22:21:06 | pixelma | S_a_i_n_t: it's not ignored just not displayed |
| 22:21:53 | S_a_i_n_t | So, it sorts before the chars are stripped? I thought it was the other way around...my apologies. |
| 22:22:40 | pixelma | I think so and that's what I said 6 minutes ago ;) |
| 22:24:30 | saratoga | technically 65536 |
| 22:24:42 | thinkpadx61 | S_a_i_n_t: ty |
| 22:24:42 | saratoga | am i the only one that memorized the powers of 2? |
| 22:24:50 | S_a_i_n_t | I'm on an EEE atm, I'd need to scroll to see 6 minutes ago :P |
| 22:24:58 | kugel | saratoga: no, me too :) |
| 22:25:00 | gevaerts | kugel: if I comment out the call to gui_startup(), pth_init doesn't go wrong. Of course I get assorted segfaults later on when stuff tries to use the gui |
| 22:25:09 | saratoga | imo 1<<16 is more clear though |
| 22:25:32 | kugel | saratoga: I disagree, but I guess gevaerts wants 64*1024 |
| 22:25:33 | saratoga | hmm though i guess 64u<<10 does sort of make sense |
| 22:25:42 | gevaerts | kugel: I'd put 0x10000 :) |
| 22:25:53 | funman | saratoga: it's easy: 1, 10, 100, 1000, 10000 ;) |
| 22:26:02 | saratoga | ha |
| 22:26:22 | wodz | kugel: Generaly I try to feel how threading works in rb to debug performace problems on my target. Since I do not have the target of concern at hand now I started to look with sim |
| 22:26:38 | kugel | saratoga: I need the calculator for non-{10,20,30,...} powers of two :) |
| 22:28:41 | kugel | gevaerts: maybe it is a problem with the stack of the main thread? |
| 22:29:07 | kugel | but that one is handled by the OS |
| 22:30:12 | kugel | wodz: the sim tacks cooperative threading onto preemptive threading with some black mutex magic |
| 22:30:46 | kugel | I expect you don't see the performance penalty in a sim |
| 22:32:26 | | Quit mt (Ping timeout: 252 seconds) |
| 22:32:28 | wodz | On the target I have huge lag (like few seconds) between selecting item in main menu and displaying that entry. It is cpu speed dependend but I don't belive that 45MHz coldfire is that slow. When I select some item in menu (for example Files), status bar with battery status, hold etc. is displayed immediately but the content of menu after long delay |
| 22:33:08 | wodz | The item chosen doesn't matter |
| 22:33:16 | wodz | It is the same for all |
| 22:35:55 | kugel | is it the same for the settings menu? |
| 22:35:56 | | Quit mt-phone (Ping timeout: 246 seconds) |
| 22:36:10 | wodz | Yes |
| 22:37:23 | wodz | The behaviour is consistent - it always lags after selecting something (or comming back from something) |
| 22:38:59 | wodz | I thought it originates from some blocking loop but If I force brake in debugger (BDM/gdb) I almost always brake in sleep_core function |
| 22:39:25 | | Nick ssorgatem is now known as ssorgatem_ (~ssorgatem@32.Red-88-25-167.staticIP.rima-tde.net) |
| 22:39:25 | wodz | so the core has nothing to do from threading point of view |
| 22:40:19 | | Join ssorgatem__ [0] (~ssorgatem@83.55.232.64) |
| 22:40:57 | | Join mirak_ [0] (~mirak@85-171-108-160.rev.numericable.fr) |
| 22:41:59 | | Quit mirak_ (Max SendQ exceeded) |
| 22:42:25 | | Nick ssorgatem__ is now known as ssorgatem (~ssorgatem@83.55.232.64) |
| 22:44:01 | kugel | wodz: sleep_core? |
| 22:44:41 | | Quit ssorgatem_ (Ping timeout: 265 seconds) |
| 22:44:53 | wodz | core_sleep() :-) |
| 22:45:00 | | Quit xiainx (Ping timeout: 246 seconds) |
| 22:45:08 | pixelma | JdGordon: the WPS with | from the conditional right behind %pv still fails for me on r25682 in an Ondio sim |
| 22:45:18 | wodz | thread.c:841 |
| 22:45:49 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 22:45:53 | | Quit Zarggg (Quit: Zarggg) |
| 22:46:04 | kugel | wodz: I assume it sits there when it has nothing to do |
| 22:46:41 | wodz | kugel: Me too, but it definitely has something to do - to display that bloody menu |
| 22:46:43 | kugel | maybe not, I'm not really a cf guy (but amiconn is) |
| 22:47:07 | | Quit S_a_i_n_t (Quit: 0/) |
| 22:47:35 | wodz | kugel: stop #0x2000 basicaly means: sleep the core until any interrupt occure |
| 22:47:59 | wodz | and interrupts are serviced - current_tick is changing |
| 22:48:27 | | Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) |
| 22:48:41 | pixelma | JdGordon: in case you want to try, the line is: %?pv<mute|%pv|line|+%pv> |
| 22:50:13 | | Join Zarggg [0] (~zarggg@2001:0:4137:9e74:0:fbec:beb1:ba3d) |
| 22:50:42 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 22:51:08 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 22:56:43 | | Quit ender` (Quit: Remember: A secretary isn't permanent until she's been screwed on the desk...) |
| 22:57:00 | | Quit saratoga (Quit: Page closed) |
| 22:58:00 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 23:00 |
| 23:01:31 | | Join pyro_ [0] (~quassel@77-23-96-13-dynip.superkabel.de) |
| 23:02:54 | | Quit pyro_ (Remote host closed the connection) |
| 23:06:08 | | Quit xiainx (Ping timeout: 276 seconds) |
| 23:07:55 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 23:09:40 | | Quit petur (Quit: Zzzzzz) |
| 23:10:14 | *** | Saving seen data "./dancer.seen" |
| 23:15:15 | gevaerts | kugel: I'm going to give up for today. This could be some sdl/pth incompatibility, which (if true) might be worked around by building sdl for pth threading, but my first attempt at that failed elsewhere. |
| 23:17:22 | gevaerts | building sdl works fine, but I think pth might be initialised too late right now |
| 23:19:25 | | Join mt [0] (~mtee@41.91.113.165) |
| 23:19:50 | | Quit funman (Quit: free(random());) |
| 23:21:31 | | Join xiainx [0] (xiainx@wpa058039.Wireless.McGill.CA) |
| 23:23:50 | | Join Surlent777 [0] (~Surlent@24.121.163.181) |
| 23:24:54 | Surlent777 | Anyone know if any real work was ever started on supporting the Sansa View? Last I checked it was no. Either way, is there a non-programming way to help with this? |
| 23:25:27 | B4gder | Surlent777: no, there's reverse engineering and development that's needed |
| 23:25:46 | gevaerts | That depends on whether you consider reverse engineering to be programming |
| 23:25:54 | Surlent777 | I probably do |
| 23:26:20 | gevaerts | in that case, probably not |
| 23:26:35 | Surlent777 | had to ask |
| 23:26:52 | Surlent777 | MSC mode just infuriates me on this device, and Linux kind of lacks MTP support in most areas |
| 23:28:56 | CIA-5 | New commit by b0hoon (r25683): Packard Bell Vibe: Manual - change the names of the buttons internally (ButtonPrev -> ButtonLeft, ButtonNext -> ButtonRight), remove unnecessary ... |
| 23:32:19 | | Quit xiainx (Ping timeout: 248 seconds) |
| 23:34:20 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 23:36:29 | | Quit killan (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 23:42:10 | | Part Surlent777 |
| 23:44:25 | kugel | gevaerts: any idea why it would work fine in qemu or on a x86 pc then? |
| 23:44:38 | gevaerts | no |
| 23:44:53 | kugel | the goal is to not use sdl at all anyway, so that issue might disappear :p |
| 23:45:06 | gevaerts | exactly :) |
| 23:48:51 | | Quit evilnick_B (Quit: Page closed) |
| 23:49:00 | | Quit kugel (Remote host closed the connection) |
| 23:53:01 | | Quit DataGhost (Ping timeout: 264 seconds) |
icon identifies that the person is a core developer (has commit access).