| 00:00:25 | | Quit kushalone ("Leaving. I cannot promise to be back but most likely will.") |
| 00:01:02 | | Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) |
| 00:03:11 | bluebrother | maybe we can construct two (or three) letter shortcuts for the parts? As in Archos -> ar, Apple -> ap |
| 00:04:39 | rasher | What does ipodmini1g shorten to? |
| 00:04:48 | | Quit ender` (" error compiling committee.c: too many arguments to function") |
| 00:04:56 | rasher | or mini1g I guess |
| 00:05:20 | bluebrother | ap-min-2g, ap-vid-55, ap-vid-5g, sa-e2x-pp, co-m3, to-gig-f |
| 00:05:35 | rasher | Not sure if it should be appleipodmini1g applemini1g. |
| 00:05:36 | bluebrother | and so on. A bit cryptic, I need to admit. |
| 00:05:43 | * | rasher doesn't see why we need this |
| 00:06:22 | bluebrother | I'd add some separators between the parts. Of course we could start using CamelCase instead but simply putting it together feels kinda strange |
| 00:07:06 | * | rasher doesn't feel strongly about this - we've not used any separators so far |
| 00:07:08 | n1s | please no CamelCase |
| 00:07:16 | rasher | Yeah, I don't like that either |
| 00:07:47 | bluebrother | me neither, but not using separators feels ... well, strange. If we put in more information it'll get harder to read |
| 00:15:11 | | Quit n1s ("Lämnar") |
| 00:26:43 | amiconn | I wonder what advantage Cygwin 1.7 might have for a rockbox build environment |
| 00:27:08 | amiconn | It's currently in beta, and according to the website a lot has changed |
| 00:27:30 | amiconn | ....so much that Cygwin 1.5.x and 1.7 can even be installed in parallel |
| 00:30:23 | DerPapst | oha... |
| 00:31:40 | *** | Saving seen data "./dancer.seen" |
| 00:34:51 | | Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...") |
| 00:34:52 | | Quit mrkiko (Read error: 104 (Connection reset by peer)) |
| 00:38:40 | | Join pinguen [0] (n=ircuser6@128-193-148-65.oregonstate.edu) |
| 00:39:03 | amiconn | kkurbjun: Laaate answer.... what kind of corruption did you observe? |
| 00:39:43 | | Join mrkiko [0] (n=IRCExplo@host105-104-dynamic.54-82-r.retail.telecomitalia.it) |
| 00:50:51 | | Join cspotcode [0] (n=bradla@buster-blader-03.dynamic2.rpi.edu) |
| 00:51:41 | Unhelpful | do we have anybody who knows a fair amount about DCT? i was wondering just how large a computational cost switch jpeg decoder to using optimized 1D IDCTs would have. this would let us use an 8x16 IDCT, for example, when decoding subsampled chroma channels, so that a separate scaling step would not be needed. jpeg-7 already has a full set of 2NxN and Nx2N IDCTs, but i suspect this would be quite a bit too much code... |
| 00:52:32 | | Quit midijunkie (Read error: 104 (Connection reset by peer)) |
| 00:53:04 | | Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") |
| 00:53:22 | bertrik | I think saratoga knows a lot about various transforms |
| 00:53:29 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 00:53:42 | | Quit bluebrother ("zzz") |
| 00:54:00 | | Join _lifeless [0] (n=lifeless@188.16.89.146) |
| 00:54:19 | Unhelpful | right, i'll prod him about it later then. :) |
| 00:54:30 | | Join Reptile211 [0] (n=chatzill@host-216-66-248-9.static.linkline.com) |
| 00:54:58 | | Quit __lifeless (Remote closed the connection) |
| 00:55:48 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]") |
| 00:55:56 | | Quit _lifeless (Remote closed the connection) |
| 00:56:44 | | Quit Reptile211 (Read error: 104 (Connection reset by peer)) |
| 00:57:24 | | Join Reptile211 [0] (n=chatzill@host-216-66-248-9.static.linkline.com) |
| 01:00 |
| 01:03:08 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-e6532171d9b4a17d) |
| 01:03:56 | | Quit bertrik ("Leaving") |
| 01:06:16 | | Quit cspotcode ("Leaving.") |
| 01:07:29 | | Quit Reptile211 ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]") |
| 01:12:16 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 01:12:58 | | Join japc [0] (n=japc@bl9-134-90.dsl.telepac.pt) |
| 01:21:04 | rasher | Bagder, bluebrother: http://rasher.dk/rockbox/targetnames.php |
| 01:21:35 | | Quit pinguen (Read error: 110 (Connection timed out)) |
| 01:21:54 | rasher | Some of those only make sense for builds, and some even only for bootloader builds. |
| 01:22:21 | rasher | I'm not sure how to handle this best without ending up in a "multiple lists" situation |
| 01:32:34 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 01:32:51 | | Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-083b2c1187fb9bb5) |
| 01:33:42 | kkurbjun | amiconn, the scrolling lines would get offset each time it went down a line |
| 01:34:06 | kkurbjun | when I say line, I mean line of pixels |
| 01:34:37 | kkurbjun | it would be offset by some amount - the problem was just in the math for the rectangle update |
| 01:36:10 | JdGordon | kkurbjun: i've put a request for images in the forums to help the port out :) depending on my weekend ill try and finish the touchscreen stuff for the wps |
| 01:38:02 | kkurbjun | JdGordon: nice, hopefully someone can help out :) |
| 01:38:12 | JdGordon | hehe yeah |
| 01:38:28 | JdGordon | if you want to add any icons to the requested list, go for it :) |
| 01:38:46 | rasher | Is this for the mrobe500? |
| 01:38:53 | kkurbjun | yep |
| 01:38:53 | * | JdGordon requests the arty people in the channel check out http://forums.rockbox.org/index.php?topic=21359.0 |
| 01:39:05 | rasher | The sim still doesn't seem to work quite right (windows anyway) |
| 01:39:25 | kkurbjun | rasher, what's the problem? |
| 01:39:58 | rasher | The window looked like it isn't the right size, unless you fixed it in the last few weeks |
| 01:40:18 | kkurbjun | the image for the sim isn't sized right |
| 01:40:32 | kkurbjun | I scaled the screen down from 640x480 to 320x240 |
| 01:41:01 | kkurbjun | since for now at least it would make the port much more usable and presentable |
| 01:45:32 | rasher | Okay, looks "right" now |
| 01:49:49 | | Quit amiconn (Nick collision from services.) |
| 01:49:53 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 01:49:59 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 01:50:10 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 01:50:10 | | Quit pixelma (Nick collision from services.) |
| 01:50:12 | PaulJam__ | I'm just curious, could the software USB stuff (like FS #10116) also work on the H300 via the secondary USB 1.1 host port? |
| 01:50:30 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 01:51:27 | kkurbjun | PaulJam__: I believe it could, but it would take some work |
| 01:53:20 | | Join bubsy [0] (i=Bubsy@94.139.80.168) |
| 01:53:30 | | Join bs66_1 [0] (n=sysuser@79.138.193.133.bredband.tre.se) |
| 01:55:25 | | Quit DerPapst ("Leaving.") |
| 01:55:38 | | Part toffe82 |
| 01:56:10 | PaulJam__ | kkurbjun: thanks |
| 01:56:29 | | Nick JdGordon is now known as JdGordon|afk (n=jonno@rockbox/developer/JdGordon) |
| 01:57:49 | | Quit jordan`` (Read error: 60 (Operation timed out)) |
| 01:57:57 | | Quit japc (Read error: 60 (Operation timed out)) |
| 02:00 |
| 02:00:31 | | Join jordan` [0] (n=jordan@jem75-10-88-182-222-63.fbx.proxad.net) |
| 02:01:09 | | Quit Thundercloud (Remote closed the connection) |
| 02:12:46 | | Quit bs66_ (Read error: 110 (Connection timed out)) |
| 02:17:17 | | Quit mrkiko ("leaving") |
| 02:22:20 | | Quit BlakeJohnson86 (Remote closed the connection) |
| 02:26:55 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 02:27:21 | | Join hillshum [0] (n=hillshum@unaffiliated/hillshum) |
| 02:31:42 | *** | Saving seen data "./dancer.seen" |
| 02:35:19 | hillshum | What is the best way to describe the rockbox version of gcc? (version?) (compiler?) |
| 02:39:32 | Unhelpful | the "rockbox version" is just gcc built as a cross-compiler with a few patches that help it to produce better code for our targets. |
| 02:40:30 | hillshum | I know, I'm writing a wiki page on the different options for windows developers, what should I call it? |
| 02:41:09 | BigBambi | I don't really get the question |
| 02:41:15 | hillshum | Here is my early work http://www.rockbox.org/twiki/bin/view/Main/WindowsDevelopmentPlatforms |
| 02:41:23 | hillshum | What term should I use? |
| 02:41:23 | BigBambi | "The cross compiler" ? |
| 02:41:37 | hillshum | O yes. Thanks |
| 02:41:58 | BigBambi | Are you sure that those are emulation platforms? |
| 02:42:25 | saratoga | technically they're not emulators |
| 02:42:32 | saratoga | and anyway, we already have a wiki page for this |
| 02:42:42 | saratoga | http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling |
| 02:42:45 | BigBambi | saratoga: That's my point :) |
| 02:43:10 | BigBambi | And we don't have a "Rockbox compiler" |
| 02:46:53 | | Quit fyrestorm ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 02:47:12 | | Join fyrestorm [0] (n=user@cpe-24-90-85-21.nyc.res.rr.com) |
| 02:47:48 | BigBambi | hillshum: If you are going to edit the wiki, please take some care to e.g. leave spaces between words |
| 02:53:21 | | Quit moos ("Rockbox rules the DAP world") |
| 02:59:34 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 03:00 |
| 03:03:14 | | Quit DataGhost (Nick collision from services.) |
| 03:03:21 | | Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) |
| 03:09:07 | | Quit saratoga ("CGI:IRC (Ping timeout)") |
| 03:09:12 | * | hillshum finds confusion among new devs on windows |
| 03:09:52 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 03:11:26 | | Quit MT (SendQ exceeded) |
| 03:11:32 | | Quit PaulJam__ (".") |
| 03:12:19 | | Join cmwslw [0] (n=cmwslw@c-68-53-245-240.hsd1.tn.comcast.net) |
| 03:12:57 | | Join MT [0] (n=chatzill@41.233.152.167) |
| 03:13:15 | hillshum | BigBambi: some of those names don't have spaces |
| 03:14:09 | | Part cmwslw ("Ex-Chat") |
| 03:14:51 | | Join midijunkie [0] (n=Miranda@pD954707A.dip0.t-ipconnect.de) |
| 03:18:47 | | Quit midijunkie (Client Quit) |
| 03:21:33 | | Quit hillshum ("Leaving") |
| 03:42:24 | | Join Strife89 [0] (n=nds@204.116.244.200) |
| 03:52:14 | | Join joshwood [0] (n=794fd262@gateway/web/cgi-irc/labb.contactor.se/x-d6a4190495a1fc4f) |
| 03:54:13 | joshwood | is there anyone here who can pls help with the wmware image for compiling rockbox? I need to get internet access |
| 04:00 |
| 04:12:33 | | Quit joshwood ("CGI:IRC (EOF)") |
| 04:13:20 | | Join joshwood [0] (n=794fd262@gateway/web/cgi-irc/labb.contactor.se/x-adeddcf2403bb410) |
| 04:18:01 | | Quit joshwood (Client Quit) |
| 04:18:59 | | Join g54pcys [0] (n=chatzill@121.79.210.98) |
| 04:21:29 | g54pcys | hello? |
| 04:21:42 | Strife89 | Hello. |
| 04:29:48 | g54pcys | do you know anything about VMWare and the rockbox image? |
| 04:30:28 | scorche | g54pcys: assuming you are joshwood, that sounds like a VMware configuration issue |
| 04:30:51 | g54pcys | yeah I am |
| 04:31:12 | g54pcys | I can ping my VM from my host OS ok... |
| 04:31:17 | g54pcys | I setup a static ip |
| 04:31:37 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-86f3d3a314e9b122) |
| 04:31:44 | *** | Saving seen data "./dancer.seen" |
| 04:35:06 | g54pcys | is there much work to setting up the build environment from scratch in linux? I might wait a few days until the new ubuntu is released, it's a nice linux version for beginners like me :) |
| 04:35:47 | Strife89 | g54pcys: See the simple Linux Guide to compiling on the Wiki. |
| 04:35:59 | Strife89 | I wrote it as an Ubuntu user. |
| 04:37:48 | g54pcys | ah sweet, I missed that guide. Easy as, I'm fine with the command line etc and general linux stuff, but don't know everything off top of my head |
| 04:38:00 | g54pcys | thanks |
| 04:40:01 | | Quit g54pcys ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
| 04:42:12 | | Join Tekno_Cowboy [0] (n=Tekno_Co@13-183.hutchtel.net) |
| 04:45:03 | Tekno_Cowboy | Hello, might anyone here be able to give me a reason why my Ipod video 30gb might think it has a 109GB drive? |
| 04:46:56 | krazykit | filesystem corruption could be one cause |
| 04:49:16 | davidfg4 | I had that problem once |
| 04:49:32 | Tekno_Cowboy | how did you fix it davidfg4? |
| 04:49:39 | davidfg4 | Can't remember what I did, but a reformat would probably fix it |
| 04:51:16 | Tekno_Cowboy | Looks like I'm going to have some fun :D |
| 04:51:37 | Tekno_Cowboy | Thanks for the advice! |
| 04:55:31 | krazykit | you could try doing a fsck first (in windows, chkdisk or chkdsk or something, i'm not sure of the name) |
| 04:56:27 | Tekno_Cowboy | I was just searching for what to use in Fedora 10 |
| 04:56:38 | krazykit | fsck.vfat |
| 04:59:00 | Tekno_Cowboy | Thanks, now I just need to figure out which drive to run it on. |
| 04:59:53 | | Quit BXCracer (Remote closed the connection) |
| 05:00 |
| 05:00:09 | krazykit | poking around in dmesg might help with that |
| 05:01:14 | Strife89 | Back up first! |
| 05:02:30 | Tekno_Cowboy | Always good advice to back up. I only have 3 drives, so it was easy to figure out. |
| 05:03:50 | | Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) |
| 05:03:57 | | Quit froggyman ("CGI:IRC (Ping timeout)") |
| 05:05:14 | | Join beta_ [0] (i=1000@d36-124-26.home1.cgocable.net) |
| 05:05:26 | | Nick beta_ is now known as beta2k (i=1000@d36-124-26.home1.cgocable.net) |
| 05:09:16 | | Quit beta2k (Client Quit) |
| 05:09:47 | Tekno_Cowboy | well, fsck is trying to read non-existent sectors, looks like a reformat is needed |
| 05:16:35 | | Quit tvelocity (Remote closed the connection) |
| 05:20:29 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 05:20:48 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-e86cd1a606728840) |
| 05:30:37 | | Quit Carnif3X () |
| 05:40:23 | | Quit Strife89 ("Bed.") |
| 05:49:18 | | Join xavieran [0] (n=root@ppp121-45-176-33.lns11.adl2.internode.on.net) |
| 05:50:04 | xavieran | Hi guys, I've had to remove rockbox from my ipod mini 2g as it is faulty and I need to send it back to the manufacturer, but I'm having some issues. |
| 05:51:35 | xavieran | I get the folder with ! on it when I reboot the ipod after putting the mbr back (I had to do it manually using dd) and if I run ipodpatcher to try and write my firmware partition I get: Firmware partition doesn't contain Apple copyright, aborting. |
| 05:51:47 | xavieran | I' |
| 05:51:59 | xavieran | m running linux and have access to a windows computer. |
| 05:54:40 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 05:55:24 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-81a114e94e0889d5) |
| 05:57:00 | xavieran | Does itune work in wine? |
| 05:57:07 | xavieran | I might have to use that. |
| 05:57:25 | scorche | xavieran: have you seen the IpodManualRestore wiki page? |
| 06:00 |
| 06:00:03 | xavieran | scorche: yes, I followed the instructions but the ipod gives me the folder w/ ! |
| 06:00:35 | xavieran | I think I see my problem. I didn't unzip the .ipsw folder! |
| 06:02:00 | xavieran | Yes, I will just have to connect my wall charger :) Thanks |
| 06:03:18 | xavieran | How long does it typically take to restore? |
| 06:03:35 | scorche | however long it takes ;) |
| 06:04:34 | xavieran | Okay :) |
| 06:04:55 | | Join Riku [0] (n=Lss@cm146.delta91.maxonline.com.sg) |
| 06:05:03 | | Quit Lss (Read error: 104 (Connection reset by peer)) |
| 06:05:12 | xavieran | btw, I have to give you guys a really big congrats (and thanks) for making rockbox. |
| 06:05:28 | xavieran | I'm sure you've heard it all before, but I really like it :) |
| 06:07:16 | | Part xavieran |
| 06:11:31 | | Quit Seed ("cu, Andre") |
| 06:17:45 | | Part Keripo |
| 06:19:48 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 06:20:09 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-e585eacabba0605e) |
| 06:21:15 | | Quit MT (Connection reset by peer) |
| 06:21:43 | | Join MT [0] (n=chatzill@41.233.152.167) |
| 06:25:34 | | Quit kadoban (Remote closed the connection) |
| 06:31:47 | *** | Saving seen data "./dancer.seen" |
| 06:32:22 | | Join Tomers [0] (n=chatzill@bzq-84-108-58-176.cablep.bezeqint.net) |
| 06:38:24 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
| 06:39:51 | | Join jason_ [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 06:39:57 | | Nick jason_ is now known as CaptainKwel (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 06:40:26 | | Part Tekno_Cowboy ("Konversation terminated!") |
| 06:41:10 | | Join fyrestorm [0] (n=user@cpe-24-90-85-21.nyc.res.rr.com) |
| 06:45:28 | | Nick Riku is now known as Lss (n=Lss@cm146.delta91.maxonline.com.sg) |
| 06:58:36 | Unhelpful | *should* core JPEG reading support direct (ie, unscaled aside from reduced/enlarged decode) output? |
| 07:00 |
| 07:01:36 | linuxstb | What do you mean? Isn't that just "scaled" 1:1? |
| 07:03:45 | Unhelpful | linuxstb: yes, but the bmp reader has a separate code path for "unscaled" output without calling resize_on_load. this saves a few multiplies per output pixel, and also doesn't require that the bmp buffer be any larger than needed for the output, while the scaler requires an extra twelve rows in the output width for scratch space. |
| 07:04:30 | Unhelpful | if we're reading a file that is *exactly* the size we want, the jpeg reader could benefit from the same thing... it doesn't seem to me that that will happen terribly often, though. |
| 07:07:22 | Unhelpful | i suspect a jpeg reader in core will mean that people who use it for album art will likely copy their AA at whatever size they use on their PC, so that such a code path would be unused the vast majority of the time |
| 07:12:18 | | Join webguest08 [0] (n=185129de@gateway/web/cgi-irc/labb.contactor.se/x-4dd40a685c76eb8d) |
| 07:13:13 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 07:14:27 | Unhelpful | anyway, it's probably not a big deal to write, or a big deal to remove later if it's deemed too useless. just thought i'd put the question out in case anybody wants to weigh in on it while i'm doing other work on this... |
| 07:14:56 | | Join l403 [0] (n=l@85.132.159.239) |
| 07:17:44 | | Join jeffdameth [0] (n=jeff@dyndsl-095-033-115-252.ewe-ip-backbone.de) |
| 07:17:46 | | Quit webguest08 ("CGI:IRC (Ping timeout)") |
| 07:18:07 | | Quit jeffdameth1 (Read error: 60 (Operation timed out)) |
| 07:23:59 | | Quit CaptainKwel (Remote closed the connection) |
| 07:24:46 | soap | If a jpeg reader was in core, all my album art would be scaled to the smallest dimension of my player's screen - thus all could be displayed 1:1... |
| 07:24:47 | | Quit AndyI (Connection timed out) |
| 07:26:27 | Unhelpful | soap: if that's how you store the art on your player, yes, it could be loaded 1:1, assuming your WPS displays at that size. that's a vote in favor of output without the scaler backend, then? |
| 07:33:34 | soap | No, not a vote either way. I do not understand the issue enough (binsize, code complexity, likelyhood of use outside my example) to feel I should have a vote. |
| 07:34:35 | linuxstb | Unhelpful: Unless it's a lot of extra code, I think it's worth optimising the 1:1 case - I can imagine some people will want to use a PC-side scaler. We may also want to support jpeg for other things, like backdrops, where the size is always the same (more so than AA). |
| 07:34:44 | soap | Just bringing up an anecdote which applies. |
| 07:35:08 | linuxstb | Unhelpful: Although what is the downside of not optimising? Simply slightly slower loading? |
| 07:35:18 | * | linuxstb thinks perhaps he hasn't woken up yet... |
| 07:35:37 | soap | How does/will the jpeg scaling compare speed-wise to the current bmp scaling? Faster? |
| 07:35:59 | Unhelpful | linuxstb: more memory needed on load, since the scaler needs its buffers, and some per-pixel multiplies while the linear scaler puts pixels through its math and returns the very same pixels :) |
| 07:36:29 | soap | currently I scale my bitmaps, because I don't want to take the CPU hit on my non-gigabeats, but if jpeg was faster perhaps I wouldn't... |
| 07:37:04 | | Join claydoh [0] (n=quassel@66-252-49-210.dyn-adsl.midmaine.net) |
| 07:37:16 | linuxstb | soap: Does that make any practical difference? |
| 07:38:21 | | Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) |
| 07:38:28 | linuxstb | Unhelpful: How big are the scaler's buffers? Where are you planning to put them? |
| 07:38:52 | Unhelpful | soap: to hit the exact output size requested, it'll use the same scaler that bmp loads use now. *however*, it is possible with jpeg to decode each block partially and directly produce a scaled version of it. this allows scaling to any N/8, with better (because they're basically lowpass-filtered) and faster results than doing the same scale via the bitmap scaler. |
| 07:39:39 | Unhelpful | N/8 will not always get you to exactly the size you want, though, so we'll sometimes have to feed the output from the decode stage to the scaler anyway. |
| 07:41:28 | soap | I didn't follow the question, linuxstb. |
| 07:42:00 | linuxstb | soap: I mean do you notice the CPU usage - either by it introducing a delay, or reduced battery life? |
| 07:42:10 | Unhelpful | linuxstb: 36B * output width on color targets, 12B * output width on greyscale. the caller is expected to call the bmp loader with a buffer large enough to load the bitmap *and* provide space for the scaler's buffers, and i'll be treating jpeg pretty much the same way, the jpeg decoder's data (which can easily exceed reasonable on-stack sizes), as well as scaler buffers if the scaler is called, will come out of the load buffer. |
| 07:43:05 | Unhelpful | if we want to load jpeg backdrops in core, i would suggest stealing the plugin buffer as a load target, then copying the backdrop out into a screen-sized buffer (i'm assuming we *have* a static one already for the backdrop?). |
| 07:43:21 | linuxstb | So 36*320 for the current largest case - 11520 bytes. |
| 07:43:50 | soap | linuxstb: delay is noticeable on large bmps. |
| 07:44:24 | soap | haven't battery benched in a long time, but scaling in bulk from the pc is easy, so I do. |
| 07:44:27 | linuxstb | soap: What would you call "large" ? |
| 07:44:47 | soap | my 250 dpi scans. |
| 07:45:36 | * | linuxstb hopes that isn't a scan of 12" vinyl album covers... |
| 07:48:35 | Unhelpful | the album art loading just passes a big buffer (i believe whatever space is available) to read_bmp_file. there doesn't ever seem to be trouble getting the scaler buffers from this space. really, the jpeg reader is going to need a pretty big chunk of buffer *anyway*, there's a large-ish struct that data about the file needs to be stored in, and the scaler only handles one line at a time, while the jpeg decoder may need to decode as many |
| 07:48:35 | Unhelpful | as 16 lines (in the case of vertical chroma subsampling) |
| 07:51:28 | linuxstb | How far have you got with implementing this? |
| 07:54:53 | Unhelpful | in my editor? not very. in my head? a bit farther, i'm pretty sure i know *how* i'll do most of it. |
| 07:55:34 | | Join webguest67 [0] (n=185129de@gateway/web/cgi-irc/labb.contactor.se/x-75eb429320a22728) |
| 07:55:37 | | Quit webguest67 (Client Quit) |
| 07:55:40 | | Join webguest32 [0] (n=185129de@gateway/web/cgi-irc/labb.contactor.se/x-5ddeb5dc248fc4cf) |
| 07:56:00 | | Quit webguest32 (Client Quit) |
| 07:56:03 | | Join webguest57 [0] (n=185129de@gateway/web/cgi-irc/labb.contactor.se/x-47ed7da693851029) |
| 07:56:17 | | Quit webguest57 (Client Quit) |
| 07:59:47 | | Quit FlynDice (Remote closed the connection) |
| 08:00 |
| 08:02:52 | | Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) |
| 08:03:21 | | Join JayHaru [0] (n=jayharu@77.31.44.41) |
| 08:06:12 | Unhelpful | a pretty large part of the work is moving local data used by the decoder into a structure, because the scaler expects to read data in via a callback. the other big part is converting the decoder from fetching data directly from memory to reading it from the file as needed - the jpeg viewer plugin reads the entire file into memory before calling the decoder. |
| 08:22:24 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 08:26:00 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 08:31:48 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:31:51 | *** | Saving seen data "./dancer.seen" |
| 08:32:20 | | Quit linuxstb (Read error: 113 (No route to host)) |
| 08:34:20 | | Quit ntfn (Read error: 60 (Operation timed out)) |
| 08:35:11 | | Quit bmbl (Client Quit) |
| 08:38:12 | Unhelpful | how much buffering is done on file reads? in particular, is reading only a few bytes at a time going to have a huge overhead (beyond the function call overhead)? |
| 08:39:03 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 08:46:58 | | Join Rob2223 [0] (n=Miranda@p4FDCF76E.dip.t-dialin.net) |
| 08:48:30 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
| 08:50:25 | amiconn | Unhelpful: What I'm missing most in the jpeg viewer are two things: Scaling large jpegs (those where even 1/8 is larger than the screen) down to screen size, and a proper fit-to-screen scaling step for the smaller ones |
| 08:51:58 | amiconn | (i.e. scale in the loader to the lowest N/8 larger than the screen and then scale down exactly to screen size, instead of loading the highest N/8 smaller than the screen, which is sometimes rather tiny) |
| 08:52:01 | Unhelpful | amiconn: my first steps are getting the reader in core, using an interface similar to the one used by the bmp reader, and handling the bits needed to make it a scaler frontend. |
| 08:52:48 | amiconn | Jpeg in core is not for all targets though |
| 08:54:03 | Unhelpful | i understand that it can't be... for targets where it's not reasonable to put it in core, the existing loader can be used, or the "core" loader can be made available via pluginlib, as the scaler is already on mono targets. |
| 08:54:39 | | Quit parafin (Read error: 110 (Connection timed out)) |
| 09:00 |
| 09:00:44 | | Join flydutch [0] (n=flydutch@host188-162-dynamic.14-87-r.retail.telecomitalia.it) |
| 09:04:34 | | Quit bertrik (lindbohm.freenode.net irc.freenode.net) |
| 09:04:34 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 09:04:34 | | Quit yosafbridge (lindbohm.freenode.net irc.freenode.net) |
| 09:04:37 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:08:44 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 09:08:44 | NJoin | yosafbridge [0] (n=yosafbri@ludios.net) |
| 09:10:17 | NJoin | bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 09:11:05 | | Quit MT (SendQ exceeded) |
| 09:13:18 | | Join MT [0] (n=chatzill@41.233.152.167) |
| 09:21:07 | | Join fragilematter [0] (n=fragilem@92.82.97.255) |
| 09:22:24 | | Join stoffel [0] (n=sfr@p57B4EA96.dip.t-dialin.net) |
| 09:29:14 | amiconn | kkurbjun: If you'd restore the <= 0 checks like they were in r20674, you could also go back to do{...}while() loops |
| 09:29:35 | amiconn | Also, some pointer maths in the current driver are weird... |
| 09:30:13 | kkurbjun | yeah, I was wondering that, would it be faster to do a do while versus include a different check in the beginning |
| 09:30:21 | kkurbjun | what math are you referring to? |
| 09:31:01 | amiconn | E.g. dst=dst+width+(LCD_NATIVE_WIDTH-x-width)+LCD_FUDGE; can be shortened to dst += LCD_NATIVE_WIDTH - x + LCD_FUDGE; |
| 09:31:12 | amiconn | +width-width is just nothing... |
| 09:32:51 | kkurbjun | in the palette blit? |
| 09:32:59 | amiconn | yes |
| 09:33:35 | kkurbjun | yeah, I missed changing that - that code isn't currently used since we are building in landscape mode |
| 09:34:36 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 09:35:26 | | Quit Tomers (Read error: 113 (No route to host)) |
| 09:35:27 | amiconn | A do{...}while loop is a bit faster and smaller than a while{...} loop. The latter checks the loop condition one time more often. In machine code, the first check either needs to be separate, or there needs to be a branch to the condition check at the end of the loop. The latter does at least need the branch in addition to what a do{...}while loop needs, the former is a little faster but needs several extra instructions |
| 09:38:10 | amiconn | So in this case, you'd trade an extra if() (two instead of the one with combining width and height) for the smaller loops. |
| 09:38:25 | tmzt | which method does optimation usually use? |
| 09:38:52 | amiconn | Probably doesn't matter much on the m:robe remote though |
| 09:39:18 | kkurbjun | well, these are on the main lcd |
| 09:39:55 | kkurbjun | I'll change it to a do while with the check in the beginning changed |
| 09:40:09 | amiconn | AH, yes, I confused the lcds |
| 09:40:32 | kkurbjun | thanks for the feedback |
| 09:40:41 | amiconn | On a related matter, am I reading right that the remote lcd_update_rect() now takes x and width into account, but not yet y and height? |
| 09:41:14 | amiconn | (i.e. the update rectangle is always 16px high) |
| 09:41:55 | kkurbjun | correct, since it's vertically packed, there are only two effective Y heights, I just havn't written the code to do a half update only since in all of the cases that I use the remote LCD it has to do a full update anyway |
| 09:42:37 | kkurbjun | it would only need the half update if an 8 px high font is used which I think is becoming rarer |
| 09:43:04 | amiconn | I think an 8px font would be a good idea on the mrobe remote |
| 09:43:33 | amiconn | That will need basic multifont support of course - I guess 8px fonts are next to unreadable on the main lcd... |
| 09:43:48 | kkurbjun | I agree, but until multifont it's not really that practical on the m:robe especially if you are doing 640x480 builds |
| 09:43:57 | kkurbjun | yeah |
| 09:44:07 | kkurbjun | at 320x240 they aren't too bad |
| 09:44:38 | amiconn | Updating only half height will save half of the transfers, and since urat isn't very fast... what's the transfer speed? |
| 09:44:43 | amiconn | *uart |
| 09:45:43 | kkurbjun | 19200, but it's interupt driven and the hardware has a 32 byte fifo |
| 09:45:46 | | Quit bmbl ("Woah!") |
| 09:45:50 | kkurbjun | so not too much cpu time is spent on it |
| 09:46:36 | kkurbjun | right now it just sets up the interupt handler with a large buffer and that takes care of filling the fifo when it runs out |
| 09:47:02 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 09:47:30 | kkurbjun | the transmit handling leaves room for improvement, it's not a circular buffer and blocks if you have an existing transfer in queue, but since the transmits happen once every 10 ms it shouldn't be blocking |
| 09:47:54 | kkurbjun | 79 bytes plus some header information is the largest transfer per 10 ms |
| 09:49:02 | amiconn | If my calculation is correct, a full screen update takes ~90ms |
| 09:49:31 | kkurbjun | on the LCD, but the CPU doesn't spend nearly that amount of time |
| 09:49:36 | kkurbjun | remote LCD |
| 09:49:38 | amiconn | yeah |
| 09:50:07 | amiconn | It limits the speed of animated content though (like scrolling text) |
| 09:50:09 | kkurbjun | the pause states are necessary because if you send the LCD update command too often it doesn't work |
| 09:51:30 | amiconn | I guess if you set the remote scroll speed higher than 9, it'll get jumpy |
| 09:53:21 | kkurbjun | Yeah, probably at some point - I haven't tried anything but the default setting. |
| 09:56:00 | amiconn | Default is 9. |
| 09:56:59 | | Quit stoffel (Read error: 113 (No route to host)) |
| 09:57:41 | kkurbjun | I guess it is a bit choppy looking at it - I need to try the non-immediate update mode to see if I can reduce the pause states |
| 09:58:02 | | Join gregzx [0] (n=chatzill@dtg254.neoplus.adsl.tpnet.pl) |
| 09:58:42 | amiconn | I guess there's not much you can do about it. The half-height update would help only in case of 8px fonts (and smaller, but then not for all lines) |
| 09:58:43 | kkurbjun | There's a microcontroller in the remote - maybe that code can be improved :-D |
| 09:59:23 | amiconn | The scroll speed setting should probably be limited for slow displays like the mrobe remote |
| 10:00 |
| 10:00:42 | | Join bimbel [0] (n=Miranda@unaffiliated/bmbl) |
| 10:01:07 | kkurbjun | amiconn, I was looking at the hardware for the m:robe and there's a idct accelerator that I was thinking about messing with |
| 10:01:52 | | Join stoffel [0] (n=sfr@p57B4EA96.dip.t-dialin.net) |
| 10:02:35 | kkurbjun | but I'm not too sure on how the intermediate buffers would be used that it references.. does that sound familiar with anything you've worked on. There's an input pointer, an intermediate pointer, and an output pointer that it takes |
| 10:02:47 | kkurbjun | well, and a secondary output pointer |
| 10:03:13 | Unhelpful | amiconn: it also looks like the vertical and horizontal IDCTs as we currently use them are pretty easily separable. splitting them would let us do 8x8, 8x4, or 4x8 IDCT so that we can handle subsampled chroma when downscaling, without a chroma scaling step. we could do the same when not downscaling, if we add a 16-point IDCT - those shouldn't be hard to copy from the jpeg-7 sources, it looks like our existing IDCT are mostly borrowed fr |
| 10:03:14 | Unhelpful | om there. |
| 10:04:46 | | Quit bertrik (lindbohm.freenode.net irc.freenode.net) |
| 10:04:46 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 10:06:25 | kkurbjun | Unhelpful: I don't know how much this would effect your work, but the hardware IDCT function that the m:robe has access to only supports 8x8 blocks |
| 10:06:49 | kkurbjun | It would be nice ot be able to integrate it with any jpeg/mpeg code we have |
| 10:09:35 | Unhelpful | kkurbjun: we could certainly special-case the 8x8 case. whether it would pay off to use that, or a reduced or expanded software IDCT, when scaling would be a bit harder to say. |
| 10:10:06 | kkurbjun | according to the datasheet it can do the idct in 144 CPU cycles |
| 10:10:46 | | Quit bmbl (Read error: 110 (Connection timed out)) |
| 10:15:12 | amiconn | Unhelpful: Afaik there are 4 cases of chroma subsampling in jpeg - no subsampling (1x1), and 1x2, 2x1 and 2x2 pixels |
| 10:15:31 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 10:15:31 | NJoin | bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 10:16:27 | amiconn | That means if we want to handle all possible sizes without having to scale in the yuv blit, we'd need 16x16, 16x8, and 8x16 in addition to the existing 8x8 idct for the unscaled jpeg |
| 10:16:50 | amiconn | But there's actually a disadvantage in doing this - the decoded data becomes larger |
| 10:17:55 | amiconn | It's probably not an issue for a core jpeg loader that passes its output to the fractional scaler. For the jpeg viewer it is. |
| 10:19:51 | amiconn | kkurbjun: I know the fascination of new stuff vs. fixing/improving existing things... |
| 10:20:14 | * | amiconn really needs to do those mmc driver fixes/ improvements |
| 10:20:24 | Unhelpful | a core jpeg loader, if it will use the scaler, has to convert all image data to RGB before passing it, anyway. my plan was that we reserve enough space for one block worth of ints, which will hold the intermediate values between the two passes, and enough space for one row of blocks (or two if there is vertical subsampling). |
| 10:21:06 | kkurbjun | amiconn, fortunately, to my knowledge, only 3 people are using the M:robe 500 port :-D |
| 10:22:21 | Unhelpful | the IDCT would be split into separate vertical and horizontal IDCT functions - they have different ranges for output values anyway, so we can't use one and fiddle with step sizes unless we have a third function that will copy from a working space and scale the values down to their output ranges. |
| 10:23:04 | Unhelpful | we could *do* that, but i didn't think that writing that data back to a block of memory before reading it back in and scaling it down would be a good idea (for performance) |
| 10:24:37 | amiconn | kkurbjun: In case you're talking about the idct in libmpeg (mpegplayer) - armv5 and armv6 should allow for a faster idct on cpu anyway. Our current idct is optimized for armv4 and its slow multiplier |
| 10:25:23 | kkurbjun | amiconn, faster than the hardware idct implementation? |
| 10:25:26 | amiconn | Idct for armv5 and higher could work very similar to the coldfire version |
| 10:25:32 | amiconn | I don't know yet |
| 10:26:07 | kkurbjun | oh, I missed your meaning |
| 10:26:36 | kkurbjun | I thought you were saying that it would be faster on the CPU, not that there is room for improvement on v5/6 |
| 10:26:46 | kkurbjun | I see what you mean now though |
| 10:31:01 | Unhelpful | amiconn: an 8x8 IDCT is *quite* a few multiplies, isn't it? if i count correctly, the one in our jpeg decoder is doing 192 multiplies per block, and when you factor in the other math it needs to do, i'm guessing that we'd to better with that hardware IDCT... |
| 10:31:56 | *** | Saving seen data "./dancer.seen" |
| 10:32:12 | | Join gregzx_ [0] (n=chatzill@dro31.neoplus.adsl.tpnet.pl) |
| 10:32:53 | | Quit gregzx (Nick collision from services.) |
| 10:32:55 | | Nick gregzx_ is now known as gregzx (n=chatzill@dro31.neoplus.adsl.tpnet.pl) |
| 10:33:09 | | Quit l403 (Read error: 148 (No route to host)) |
| 10:34:04 | amiconn | Yeah, probably. This doesn't mean the idct shouldn't be optimised for armv5+. Not all armv5+ targets have hardware idct support... |
| 10:38:59 | | Join l403 [0] (n=l@85.132.159.239) |
| 10:43:06 | Unhelpful | hrm... i haven't taken a close look at the yuv2rgb part yet, but i *believe* a fixed-size, fixed-ratio version of the scaler could be done for quite cheap. all of the division, and much of the multiplication, would be by fixed values, and convenient ones at that. |
| 10:45:19 | | Join planetbeing [0] (n=planetbe@c-71-236-164-204.hsd1.or.comcast.net) |
| 10:54:48 | | Quit MT (SendQ exceeded) |
| 10:56:19 | | Join MT [0] (n=chatzill@41.233.152.167) |
| 11:00 |
| 11:03:06 | | Join evilnick [0] (n=evilnick@pool-173-52-140-21.nycmny.east.verizon.net) |
| 11:03:30 | | Quit kachna (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 11:03:30 | | Quit tchan (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | | Quit Ridayah (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | | Quit kubzior (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | | Quit synergist (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | | Quit evilnick1 (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | | Quit Foxx (lindbohm.freenode.net irc.freenode.net) |
| 11:03:30 | | Quit shadearg (lindbohm.freenode.net irc.freenode.net) |
| 11:03:56 | | Quit planetbeing (Connection reset by peer) |
| 11:04:04 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 11:04:04 | NJoin | kachna [0] (n=kachna@r4ax178.net.upc.cz) |
| 11:04:04 | NJoin | tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 11:04:04 | NJoin | Ridayah [0] (n=ridayah@173-19-228-175.client.mchsi.com) |
| 11:04:04 | NJoin | kubzior [0] (n=kubz@unaffiliated/kubz) |
| 11:04:04 | NJoin | synergist [0] (i=christop@cant.be-arsed.co.uk) |
| 11:04:04 | NJoin | evilnick1 [0] (n=evilnick@pool-173-52-140-21.nycmny.east.verizon.net) |
| 11:04:04 | NJoin | Foxx [0] (n=Foxx@141.157.246.7) |
| 11:04:04 | NJoin | shadearg [0] (i=arg@ipv4.panoptix.net) |
| 11:04:18 | | Join planetbeing [0] (n=planetbe@c-71-236-164-204.hsd1.or.comcast.net) |
| 11:04:25 | Llorean | What causes the inaccuracies in seeking in very large MP3 files? |
| 11:06:22 | | Quit Llorean ("Leaving.") |
| 11:08:50 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 11:09:07 | | Join Llorean [0] (n=DarkkOne@99.185.10.238) |
| 11:11:01 | | Quit stripwax (Client Quit) |
| 11:11:46 | Llorean | Seeking seems to be _very_ broken actually |
| 11:14:32 | Llorean | If I seek one second forward, it hops me to a time ~2:30 forward (in a 21 hour file). This isn't irregular, this is the inaccuracy that used to be there (you could get around it by just figuring out roughly how much the offset was that late in the file, and approximating an earlier point to seek to) but now it seems to be playing someplace from ~5.5 hours in the file, when the point I seeked to was ~17.5 hours into the file |
| 11:17:30 | amiconn | cbr or vbr? with or without xing header if the latter? |
| 11:18:28 | Llorean | VBR |
| 11:18:52 | amiconn | CBR seeking should be exact. |
| 11:19:00 | Llorean | How would I check? It's encoded fairly recently, so I would assume it's whichever is "better" unless there's no real standard for it. |
| 11:19:07 | amiconn | VBR amkes use of the xing header if present, which has 100 seek points |
| 11:19:10 | Llorean | Being off by 12 hours is hardly simply "inexact" |
| 11:19:42 | amiconn | So the error should not exceed 12 minutes (worst case) for your file |
| 11:20:09 | Llorean | the progress bar doesn't update to the proper time either. it says I'm at approximately 17.5 hours into the file, when it's playing audio from 5.5 hours in. if I stop playback and resume, though, it's fine. |
| 11:20:12 | amiconn | Without xing header, the error can be huge if bitrate is very unbalanced across the file |
| 11:20:16 | Llorean | "fine" being, the progress bar updates to the 5.5 hour mark |
| 11:20:34 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 11:21:23 | | Quit evilnick1 (Read error: 110 (Connection timed out)) |
| 11:22:02 | amiconn | Is it just the progress bar or also the current time? Maybe there's an error in progressbar position calculation |
| 11:22:10 | Llorean | Current time is off too |
| 11:22:49 | Llorean | If I stop and resume, both are correct. Until I do, it's playing audio from 5.5 hours in, and displaying 17.5 hours in (since I simply seeked one second forward from my bookmark at about that point) |
| 11:22:50 | amiconn | Hmm. This used to work? |
| 11:23:30 | Llorean | I'm not certain. I've never experienced something like this before, though I was using a half-month old build when I just ran into it, and it's still in current SVN. |
| 11:23:32 | * | amiconn wonders whether this has to do with the recent change in current_id3 handling in playback.c |
| 11:23:47 | Llorean | I listen to audiobooks pretty regularly, so I'd *think* it's something I'd have encountered before, but I can't say for certain. |
| 11:24:18 | amiconn | I don't have such a long file. For the longest mp3 file I have, seeking is working fine (that file is a little longer than an hour and is also cbr iirc) |
| 11:24:49 | | Join DerPapst [0] (n=DerPapst@p4FE8FF85.dip.t-dialin.net) |
| 11:27:25 | | Quit fragilematter ("leaving") |
| 11:28:32 | Llorean | After running VBRfix on the file, I get the same issue. I assume this means that it's an issue that occurs even with the proper headers. |
| 11:28:47 | | Quit planetbeing () |
| 11:28:51 | * | Llorean assumed the file had them anyway, but didn't know how to test. |
| 11:30:51 | | Join planetbeing [0] (n=planetbe@c-71-236-164-204.hsd1.or.comcast.net) |
| 11:36:12 | | Join jaykay [0] (n=chatzill@p579E6691.dip.t-dialin.net) |
| 11:44:33 | | Quit stoffel (Read error: 113 (No route to host)) |
| 11:55:44 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 12:00 |
| 12:07:38 | | Quit MT (SendQ exceeded) |
| 12:10:11 | | Join MT [0] (n=chatzill@41.233.152.167) |
| 12:15:45 | | Quit FOAD ("I'll be back") |
| 12:16:01 | | Join FOAD [0] (n=dok@dinah.blub.net) |
| 12:19:15 | | Quit planetbeing () |
| 12:21:06 | | Quit Thundercloud (Remote closed the connection) |
| 12:25:42 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 12:26:03 | | Quit JayHaru (Read error: 110 (Connection timed out)) |
| 12:29:50 | Llorean | amiconn: One thing that seems odd to me. Bookmarks work pretty much fine, but seeking doesn't. |
| 12:31:59 | *** | Saving seen data "./dancer.seen" |
| 12:36:45 | | Join stripwax5443 [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 12:36:49 | | Quit stripwax5443 (Client Quit) |
| 12:48:22 | pixelma | Llorean: maybe it has to do with the changes in r20633 (and following), it caused some bugs which were ironed out since then but there could be more. Daily builds from before should still be available (April 4th), perhaps a quick way to test? |
| 12:49:34 | | Join Sedgewick [0] (n=Sedgewic@net-93-145-234-50.t2.dsl.vodafone.it) |
| 12:49:40 | Llorean | pixelma: I'm _pretty_ sure my previous build was from before that and still experiencing the problem. But not absolutely. I'll see if I can track down a revision when I can later. |
| 12:58:19 | | Join parafin [0] (i=parafin@parafin.static.corbina.ru) |
| 13:00 |
| 13:01:21 | * | GodEater wonders why the hell his PC is refusing to mount his sansa |
| 13:01:47 | GodEater | ....and of course it bloody does as soon as I mention it |
| 13:02:04 | | Join stoffel [0] (n=sfr@p57B4EA96.dip.t-dialin.net) |
| 13:07:37 | * | pixelma wonders where the interest in FS #8824 (c200 keymap) went |
| 13:09:33 | rasher | pixelma: not enough devs with c200s around? |
| 13:10:25 | pixelma | I put the patch there about a week ago (and people showed interest in it before, here in IRC) :) |
| 13:12:20 | GodEater | is usb still not enabled in the release c200 bootloaders ? |
| 13:13:38 | pixelma | wouldn't make much sense if it isn't even enabled in the last release build... :) |
| 13:14:12 | rasher | USB isn't enabled in any release bootloaders |
| 13:15:14 | GodEater | you know, I think I've had brain failure this morning |
| 13:15:24 | GodEater | I'd best not touch anything complicated - I might break it |
| 13:16:32 | | Join schrottplatz [0] (n=max@f053225254.adsl.alicedsl.de) |
| 13:16:44 | | Join tvelocity [0] (n=tony@athedsl-4471682.home.otenet.gr) |
| 13:16:49 | schrottplatz | hi |
| 13:17:15 | schrottplatz | when comes the pictureflow out? |
| 13:17:20 | schrottplatz | are there any plans? |
| 13:17:40 | stripwax | schrottplatz - pictureflow is already part of rockbox, and I don't understand your question |
| 13:17:54 | schrottplatz | but i cant play the songs.. |
| 13:18:00 | schrottplatz | out of pictureflow |
| 13:18:24 | stripwax | pictureflow does not yet let you select the songs to play, that is true. it only shows the albumart pictures.. |
| 13:18:33 | Llorean | It's in the demo category for this very reason. |
| 13:18:46 | schrottplatz | yes |
| 13:18:55 | | Join miepchen^schlaf [0] (n=miepel@p579EC802.dip.t-dialin.net) |
| 13:19:09 | schrottplatz | and when will it be released? |
| 13:19:41 | Llorean | There's nothing to "release" |
| 13:19:44 | Llorean | Everything we have is there. |
| 13:20:10 | schrottplatz | will it ever work? |
| 13:20:15 | stripwax | If you mean 'when will it be possible to select the tracks directly from pictureflow itself' - I don't think there are any immediate plans |
| 13:20:21 | stripwax | pictureflow works. it shows pictures. |
| 13:20:22 | schrottplatz | yes |
| 13:20:38 | schrottplatz | ok |
| 13:20:40 | schrottplatz | :( |
| 13:20:47 | Llorean | schrottplatz: Rockbox is entirely volunteer effort. There are no timelines or plans, things only happen if interested people do the work. |
| 13:21:01 | schrottplatz | i know |
| 13:21:10 | stripwax | schrottplatz - if you're interested, you can take a look at the code and help extend it to enable song selection from pictureflow? |
| 13:21:35 | schrottplatz | hmm i can only code php... |
| 13:21:53 | schrottplatz | i could make a better design |
| 13:22:36 | schrottplatz | but it seems like you are happy with it :/ |
| 13:23:30 | | Join einhirn [0] (n=Miranda@p4FC61507.dip0.t-ipconnect.de) |
| 13:25:33 | GodEater | a better design for pictureflow ? |
| 13:26:40 | | Join wincent [0] (n=wincent@dyndsl-091-096-000-117.ewe-ip-backbone.de) |
| 13:29:19 | stripwax | I think he means a better rockbox web design? |
| 13:29:37 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 13:30:06 | GodEater | if he does, he's not been paying attention to the "redesign the www" thread in the forums |
| 13:33:01 | | Quit wincent (Read error: 60 (Operation timed out)) |
| 13:33:30 | | Join cmwslw [0] (n=cmwslw@c-68-53-245-240.hsd1.tn.comcast.net) |
| 13:38:42 | | Join einhirn_ [0] (n=Miranda@p4FC625F1.dip0.t-ipconnect.de) |
| 13:38:42 | schrottplatz | GodEater: yes the webdesign |
| 13:38:52 | | Part cmwslw ("Ex-Chat") |
| 13:38:54 | schrottplatz | which forum abi? |
| 13:39:13 | Llorean | The Rockbox forum. |
| 13:44:22 | stripwax | Hm, running test_codec a couple times seems to give sizeable variation in timings (e.g. +- 1.5MHz ish on coldfire h120, which seems to be of the same approx order of magnitude as the effect I'm trying to test for). Is there another way to measure codec performance other than watching the buffering debug screen? |
| 13:45:20 | Llorean | Is there a possibility there's a bug in test_codec causing that? |
| 13:45:52 | schrottplatz | Llorean: are there already subs? |
| 13:46:07 | Llorean | schrottplatz: "subs"? |
| 13:46:28 | schrottplatz | submissions |
| 13:46:51 | Llorean | schrottplatz: There's a forum thread with ideas and mock-ups. |
| 13:47:18 | schrottplatz | i ve an idea |
| 13:47:52 | schrottplatz | i made already something similar |
| 13:47:53 | schrottplatz | http://milian-web.deviantart.com/art/Music-Wallpaper-112347903 |
| 13:47:58 | stripwax | Llorean - it's possible, I guess... do you know of any bug in test_codec? |
| 13:48:25 | Llorean | schrottplatz: If you wish to discuss it, the best place is the thread in the forum. |
| 13:48:50 | schrottplatz | :/ |
| 13:49:09 | Llorean | stripwax: No, but I thought the purpose of it was to remove as many external factors - to be as close as deterministic as possible. If it's giving different results on repeats of the same input, it sounds to me like it's either not doing its job, or it's just not very good at it. |
| 13:50:18 | Llorean | schrottplatz: This kind of thing needs to be discussed somewhere that discussion can be asynchronous, so that many can view, comment, and reply over a period of time. IRC is not really suitable. |
| 13:50:54 | schrottplatz | tell me what do you think of it, pls |
| 13:51:15 | rasher | It's not exactly a website design.. |
| 13:51:53 | schrottplatz | yes not yet |
| 13:52:01 | schrottplatz | but the style... |
| 13:52:27 | Llorean | It's rather hard to infer from that image what you'd actually make website navigation look and function like. |
| 13:53:04 | schrottplatz | http://macku.to.pl/rockbox/rockbox.html <- this is aaaaaaawwwwwwesome |
| 13:53:38 | Llorean | Yes, it's from the thread we referenced you to. |
| 13:53:51 | | Quit Sedgewick ("off") |
| 13:54:49 | schrottplatz | but the yellow at the to should be a bit brighter |
| 13:55:09 | scorche | [04:48:21] <Llorean> schrottplatz: If you wish to discuss it, the best place is the thread in the forum. |
| 13:55:11 | stripwax | schrottplatz - it would be very helpful for everyone involved if you added your comments to the thread in question, rather than here |
| 13:56:56 | schrottplatz | :( |
| 13:58:14 | stripwax | schrottplatz - that way, the people involve can find your comments. if they're just in an irc log somewhere, they will never read what you have to say .. |
| 13:58:26 | | Quit einhirn (Read error: 110 (Connection timed out)) |
| 14:00 |
| 14:00:33 | | Quit stoffel (Read error: 113 (No route to host)) |
| 14:01:19 | | Join moos [0] (i=mustapha@rockbox/staff/moos) |
| 14:04:06 | | Join stoffel [0] (n=sfr@p57B4EA96.dip.t-dialin.net) |
| 14:05:35 | schrottplatz | is there a good tool to sync the newest podcast with my sansa? im using rhythmbox... |
| 14:06:16 | scorche | this is #rockbox...not #rhythmbox... |
| 14:06:56 | schrottplatz | omg |
| 14:10:47 | | Quit flydutch ("/* empty */") |
| 14:17:24 | | Quit kps00000 (Read error: 110 (Connection timed out)) |
| 14:18:11 | | Join PaulJam [0] (i=Paule@vpn-3073.gwdg.de) |
| 14:32:00 | *** | Saving seen data "./dancer.seen" |
| 14:34:18 | | Join __lifeless [0] (n=lifeless@188.16.109.162) |
| 14:39:42 | | Join midijunkie [0] (n=Miranda@pD954737A.dip0.t-ipconnect.de) |
| 14:56:01 | | Join hittudiv [0] (n=hittudiv@210.212.160.101) |
| 14:56:10 | | Quit n1s ("Lämnar") |
| 14:57:01 | | Quit SirFunk (Read error: 110 (Connection timed out)) |
| 14:57:56 | | Quit stoffel (Read error: 113 (No route to host)) |
| 15:00 |
| 15:01:00 | | Join PaulJam_ [0] (i=PaulJam_@vpn-3055.gwdg.de) |
| 15:01:09 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
| 15:02:29 | | Quit PaulJam_ (Read error: 113 (No route to host)) |
| 15:03:37 | | Join PaulJam_ [0] (i=Paule@vpn-3051.gwdg.de) |
| 15:04:20 | | Join SirFunk [0] (n=Sir@208.15.25.145) |
| 15:08:18 | | Join Horscht86 [0] (n=Horscht@p4FD4F696.dip.t-dialin.net) |
| 15:11:03 | | Quit antil33t (Read error: 54 (Connection reset by peer)) |
| 15:16:38 | | Join antil33t [0] (n=Mudkips@121-72-135-110.dsl.telstraclear.net) |
| 15:17:19 | | Quit MT (SendQ exceeded) |
| 15:17:24 | | Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) |
| 15:18:21 | | Quit PaulJam (Read error: 113 (No route to host)) |
| 15:21:26 | | Join MT [0] (n=chatzill@41.233.152.167) |
| 15:21:49 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 15:25:37 | | Quit Horschti (Read error: 110 (Connection timed out)) |
| 15:26:49 | | Join funman [0] (i=53c2ba56@rockbox/developer/funman) |
| 15:27:46 | funman | hello |
| 15:29:44 | funman | FlynDice: yesterday I tried to write from the lcd framebuffer using a buffered only memory area |
| 15:30:02 | | Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 15:30:27 | funman | it didn't show any difference, I think the other devices use a framebuffer for DMA, separated from rockbox' "lcd_framebuffer" |
| 15:31:52 | | Quit SirFunk (Connection timed out) |
| 15:42:51 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 15:45:50 | funman | i'm getting some documents on USB to start having a look at Sansa AMS. |
| 15:46:09 | funman | Do you have some advices ? (I have USB spec 2.0 and the OnTheGo Supplement) |
| 15:47:02 | mcuelenaere | funman: regarding implementing a Rockbox USB driver: look at usb-drv-arc.c for an example |
| 15:47:48 | mcuelenaere | (usb-drv-tcc.c & usb-jz4740.c are other USB drivers) |
| 15:48:02 | mcuelenaere | usb-tcc* |
| 15:48:17 | | Nick Horscht86 is now known as Horscht (n=Horscht@p4FD4F696.dip.t-dialin.net) |
| 15:50:11 | funman | i had a quick look but i need some vocabulary first ("endpoint" for example) |
| 15:50:47 | mcuelenaere | have you seen http://www.beyondlogic.org/usbnutshell/usb1.htm ? |
| 15:50:54 | mcuelenaere | it's quite good |
| 15:54:25 | funman | thanks, that looks clear! |
| 15:54:46 | * | mcuelenaere wonders whether that link shouldn't be on some wiki page |
| 16:00 |
| 16:08:17 | | Join aapo [0] (n=tiina@cs181133007.pp.htv.fi) |
| 16:08:37 | | Quit shadearg ("goodbye.") |
| 16:08:57 | | Quit hittudiv (Read error: 110 (Connection timed out)) |
| 16:09:57 | aapo | hi, I tryied preparing to compile rockbpx on Linux. I started sudo ./rockboxdev.sh and chose all targets, it doesn't get end, it stucked on " ar: regex.o: No such file or directory" |
| 16:10:13 | | Quit BlakeJohnson86 (Remote closed the connection) |
| 16:10:16 | aapo | making "/tmp/rbdev-build/build-gcc-m/libiberty" |
| 16:11:53 | aapo | cd /tmp/rbdev-build/build-gcc-m/libiberty & sudo make -> I got regex.o |
| 16:12:41 | | Join shadearg [0] (i=arg@ipv4.panoptix.net) |
| 16:12:42 | rasher | aapo: making all targets is currently rather broken, do them one at a time |
| 16:12:52 | gevaerts | just a wild guess, but do you have things like $MAKEFLAGS or other bits that may influence building? |
| 16:13:10 | aapo | starting sudo ./rockboxdev.sh again leads: ROCKBOXDEV: mkdir build-binu-m, can't make, directory exists |
| 16:13:30 | rasher | aapo: yeah, you need to clean out the dirs it created.. but build-binu-m ?? |
| 16:13:59 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 16:14:09 | aapo | I just follow the LinuxSimpleGuideToCompiling |
| 16:14:34 | | Quit funman ("http://www.mibbit.com ajax IRC Client") |
| 16:15:27 | rasher | aapo: Clean out the dirs, start rockboxdev.sh again and type only a single letter at the prompt |
| 16:16:02 | aapo | rasher, ok, what dirs I clean? /tmp/rbdev-build? |
| 16:16:16 | rasher | Anything in /tmp starting with rbdev |
| 16:16:43 | aapo | rasher, ok I will try |
| 16:26:18 | | Quit robin0800 ("No Ping reply in 90 seconds.") |
| 16:26:48 | | Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 16:27:17 | | Join kps00000 [0] (n=kevin@i209-195-113-123.cia.com) |
| 16:32:03 | *** | Saving seen data "./dancer.seen" |
| 16:32:03 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 16:38:05 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
| 16:38:44 | | Join aum [0] (n=hegren@bbis.us) |
| 16:39:25 | | Join faemir [0] (n=faemir@88-106-238-71.dynamic.dsl.as9105.com) |
| 16:40:01 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 16:40:04 | | Part aum |
| 16:55:28 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 16:55:28 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 16:56:07 | | Quit robin0800 (Read error: 60 (Operation timed out)) |
| 17:00 |
| 17:03:01 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 17:03:48 | | Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) |
| 17:06:53 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 17:11:01 | | Quit parafin ("So long and thanks for all the fish") |
| 17:11:06 | | Join parafin [0] (i=parafin@paraf.in) |
| 17:18:54 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 17:18:54 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 17:28:50 | | Join sdubois92 [0] (n=steven@c-24-63-173-219.hsd1.ma.comcast.net) |
| 17:29:14 | sdubois92 | When i start my ipod, it asks if i want to build the db. But i don't want to use the db, can i turn this message off? |
| 17:30:04 | stripwax | sdubois92 - you can delete the db |
| 17:31:21 | sdubois92 | stripwax: i did |
| 17:33:16 | | Quit robin0800 (Remote closed the connection) |
| 17:48:41 | | Join toffe82 [0] (n=chatzill@adsl-75-12-168-33.dsl.frs2ca.sbcglobal.net) |
| 17:51:09 | | Quit l403 (Read error: 148 (No route to host)) |
| 17:52:55 | | Join PaulJam__ [0] (i=PaulJam_@vpn-3051.gwdg.de) |
| 17:57:45 | PaulJam__ | sdubois92: could it be that your start screen setting is set to database? |
| 18:00 |
| 18:08:12 | | Join PaulJam [0] (i=PaulJam_@vpn-3053.gwdg.de) |
| 18:08:21 | | Join jason [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 18:08:42 | | Quit gevaerts (Nick collision from services.) |
| 18:09:10 | | Join gevaerts [0] (n=fg@195.144.92.159) |
| 18:10:53 | | Join tomers [0] (n=chatzill@bzq-84-108-58-176.cablep.bezeqint.net) |
| 18:12:27 | | Quit PaulJam_ (Read error: 110 (Connection timed out)) |
| 18:13:04 | | Quit PaulJam__ (Read error: 60 (Operation timed out)) |
| 18:28:44 | tomers | I created "FS #10116 - USB HID class driver" and I would like your help committing this |
| 18:29:25 | tomers | It can be separated into small change sets, which will make it easier to review and be understood |
| 18:30:10 | gevaerts | I've just been looking at FS #10142 and it got me wondering. What |
| 18:30:22 | gevaerts | What's the license of the linux ch9.h? |
| 18:30:49 | gevaerts | That file doesn't have any license or contact information in it at all... |
| 18:32:08 | *** | Saving seen data "./dancer.seen" |
| 18:32:12 | tomers | That's really weird, indeed. But its a bit too late as its already in Rockbox's code. |
| 18:32:38 | gevaerts | I know, this isn't a new problem (if it is one at all) |
| 18:32:56 | tomers | I can assume it isn't any proprietary license, as it wouldn't be included there in the first place |
| 18:33:25 | tomers | How do you suggest we work to commit my changes? |
| 18:33:52 | gevaerts | no, but without information I assume it's GPLv2 strict, and we should at least mark that in our copy |
| 18:33:53 | | Quit bimbel ("Woah!") |
| 18:34:14 | tomers | We should ask in the Linux mailing-list |
| 18:35:25 | | Join PaulJam_ [0] (n=PaulJam_@vpn-3042.gwdg.de) |
| 18:35:32 | tomers | Other files in /usr/src/linux-headers-2.6.27-11/include/linux/usb/ seem to have GPL v2 license |
| 18:35:37 | gevaerts | Anyway that isn't a blocker for FS #10142. Are there any real changes in that, or just some new values? |
| 18:36:32 | | Quit schrottplatz ("o.O") |
| 18:36:49 | gevaerts | Also, I'm not actually sure about the tabs in there. We do usually leave files with external origin in their original style |
| 18:36:54 | tomers | No real changes, but do the diff yourself to verify. There are some parts that weren't integrated. I guessed they were not included earlier, either since they were not required, or they did not existed |
| 18:37:29 | gevaerts | There seem to be some more comments as well |
| 18:37:36 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 18:37:54 | | Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) |
| 18:37:58 | tomers | I learned that Rockbox does not modify the original code styling, but I think we does change tabs to spaces, am I right? |
| 18:38:27 | rasher | gevaerts: I think that's only the rule if there's any chance we're going to keep them in sync with upstream |
| 18:38:56 | gevaerts | rasher: well, tomers is doing just that right now :) |
| 18:39:10 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 18:39:27 | rasher | Well in that case yes, we should change as little as possible I believe |
| 18:41:04 | tomers | So what is the verdict? keeping the original tabs? |
| 18:41:27 | rasher | I'd say so |
| 18:41:30 | mcuelenaere | What YUV format does Rockbox use? |
| 18:42:12 | kkurbjun | for blitting? |
| 18:42:23 | mcuelenaere | yes |
| 18:42:24 | gevaerts | On the other hand, the types are different (uint8_t vs __u8 and things like that), so merging is not straightforward anyway |
| 18:42:33 | kkurbjun | 4:2:0 I believe is the name for it |
| 18:42:42 | mcuelenaere | thanks |
| 18:43:00 | kkurbjun | mcuelenaere: did you see that the mr500 has yuv blitting in the lcd driver? |
| 18:43:17 | mcuelenaere | not yet |
| 18:43:17 | kkurbjun | if you were thinking about that for the creative ZVM |
| 18:43:26 | mcuelenaere | no, I was talking about the Onda VX747 |
| 18:43:32 | kkurbjun | oh, gotcha |
| 18:43:33 | gevaerts | tomers: do you expect that merging from linux later on again is useful? We're not going to see USB3 anytime soon on a rockbox-supported DAP I guess, so we could just use the current file and maintain it ourself |
| 18:43:36 | mcuelenaere | (which also has HW-accelerated YUV) |
| 18:44:23 | | Join l403 [0] (n=l@85.132.159.239) |
| 18:44:23 | gevaerts | And if we maintain it ourself, we get rid of the tabs... |
| 18:44:29 | kkurbjun | nice |
| 18:46:36 | tomers | gevaerts: I don't think this file changes often, and keeping it somewhat in sync with Linux, today, can only be good for us. I don't see the pitfalls. Also, I am in favor of converting tabs to spaces |
| 18:47:52 | tomers | gevaerts: It will make the difference between the two system more obvious. |
| 18:48:13 | gevaerts | tomers: I'm certainly in favour of syncing now. I think I'll apply the patch as it is now |
| 18:48:40 | tomers | gevaerts: Thanks! I'll work on my next patch now. |
| 18:48:52 | | Quit bmbl ("Woah!") |
| 18:49:36 | LambdaCalculus37 | This is weird... I just build the m68k environment on my machine, but m68k-elf-gcc is missing from /usr/local/m68k-elf/bin |
| 18:49:43 | * | LambdaCalculus37 summons a Mac owner |
| 18:50:20 | * | gevaerts gives LambdaCalculus37 a mirror ;) |
| 18:50:29 | LambdaCalculus37 | gevaerts: Another Mac owning dev? ;) |
| 18:51:10 | gevaerts | LambdaCalculus37: m68k mac OK? ;) |
| 18:51:28 | rasher | LambdaCalculus37: preglow reported being unable to build m68k |
| 18:51:32 | LambdaCalculus37 | gevaerts: Can you build the dev environment on it? ;) |
| 18:51:50 | LambdaCalculus37 | rasher: Same reason? Because of the missing m68k-elf-gcc binary? |
| 18:52:12 | rasher | LambdaCalculus37: I don't think so |
| 18:52:31 | LambdaCalculus37 | rasher: All the other needed tools appear to be there. |
| 18:52:35 | LambdaCalculus37 | Just missing that one. |
| 18:54:58 | LambdaCalculus37 | rasher: IIRC Domonoky also has a Mac, right? As does JdGordon. |
| 18:55:51 | rasher | That sounds correct |
| 18:56:10 | rasher | midgey as well, it seems |
| 18:56:44 | LambdaCalculus37 | And I think lostlogic does, too. |
| 18:56:55 | LambdaCalculus37 | Hopefully one of them has the file I need. |
| 18:57:06 | | Quit robin0800 (Remote closed the connection) |
| 18:57:20 | LambdaCalculus37 | I can build for all other platforms except m68k right now, and that's bad since I own a Coldfire target (H340). |
| 18:59:34 | | Quit stripwax (Read error: 104 (Connection reset by peer)) |
| 19:00 |
| 19:01:19 | | Quit dmb ("Leaving") |
| 19:02:17 | | Quit PaulJam (Read error: 113 (No route to host)) |
| 19:15:46 | | Join planetbeing [0] (n=planetbe@c-71-236-164-204.hsd1.or.comcast.net) |
| 19:28:30 | | Join kenzo [0] (n=5430d510@gateway/web/cgi-irc/labb.contactor.se/x-455157f81f676fef) |
| 19:29:22 | kenzo | Guys, I really need some help in installing rockbox |
| 19:30:00 | LambdaCalculus37 | Well, tell us what kind of help you need. |
| 19:32:06 | kenzo | Im trying to install it on a iPod 5,5 using a Mac. I have no clue whatsoever about compiling and what have you not;) The rockboxUtility does not work and I cant seem to get Mtools helping me either. I get error report that the ipod is still a Mac and not windows. |
| 19:32:24 | | Quit jeffdameth (Read error: 113 (No route to host)) |
| 19:32:44 | LambdaCalculus37 | When what you need to do is format the iPod to use FAT32 instead of HFS+. |
| 19:33:18 | LambdaCalculus37 | Restoring the iPod on a Windows machine with iTunes is the easiest way to do that. |
| 19:33:35 | kenzo | I really dont have that option |
| 19:33:48 | kenzo | I want to make it on my own machine, you know |
| 19:33:51 | | Join jeffdameth [0] (n=jeff@dyndsl-095-033-064-125.ewe-ip-backbone.de) |
| 19:34:20 | kenzo | can someone guide me through the mtools procedure? |
| 19:34:28 | | Join stoffel [0] (n=sfr@p57B4EA96.dip.t-dialin.net) |
| 19:34:32 | LambdaCalculus37 | How about just follow the instructions here: http://www.rockbox.org/twiki/bin/view/Main/IpodConversionToFAT32 |
| 19:35:34 | kenzo | cant even find the config file), its driving me nuts. |
| 19:37:00 | | Quit jhMikeS (Nick collision from services.) |
| 19:37:06 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 19:40:37 | | Quit moos ("Rockbox rules the DAP world") |
| 19:41:00 | kenzo | The problem for me lies in "Format the main partition with FAT32 file system". Anyone, lease? |
| 19:41:47 | LambdaCalculus37 | I just told you what to do. |
| 19:41:59 | LambdaCalculus37 | And Rockbox Utility is telling you what to do. |
| 19:42:13 | LambdaCalculus37 | You have to format your drive to use FAT32. |
| 19:42:24 | kenzo | Rockbox Utility is not working for my iPod! |
| 19:42:36 | kenzo | Its stated clearly in the known issues |
| 19:43:11 | LambdaCalculus37 | kenzo: Unless you want me to write it out in giant neon letters, please follow the instructions on the page I linked to earlier. |
| 19:43:27 | rasher | kenzo: you need to format it as fat32. If you don't know how, I suggest seeking out OS support somewhere |
| 19:44:18 | kenzo | I am fully aware that I need FAT32. The problem is that all the automated procedures of getting this job done is not working. |
| 19:44:36 | kenzo | Not the utility function, and the mtools is way over my head |
| 19:44:47 | kenzo | was just trying tog get some kind help |
| 19:44:55 | LambdaCalculus37 | Then perhaps you should turn to Google. We didn't write mtools, and therefore we don't support it. |
| 19:45:06 | LambdaCalculus37 | Ask the mtools authors for assistance. |
| 19:45:49 | kenzo | Or perhaps maybe the team could write a tutorial that actually works... |
| 19:45:54 | rasher | Bagder: http://build.rockbox.org/cvsmod/chlog-20090418T173904Z.html no icons in the menu - what gives? |
| 19:45:59 | markun | kenzo: perhaps |
| 19:46:01 | rasher | kenzo: many people have used it |
| 19:46:05 | LambdaCalculus37 | The tutorial works just fine. |
| 19:46:35 | Bagder | rasher: and no themes... |
| 19:46:44 | | Join flydutch [0] (n=flydutch@host79-26-dynamic.13-87-r.retail.telecomitalia.it) |
| 19:46:51 | rasher | ooh indeed |
| 19:46:55 | markun | kenzo: if you eventually find a good way to do it, maybe you can help to make the tutorial better. |
| 19:47:16 | rasher | Bagder: did you see http://rasher.dk/rockbox/targetnames.php |
| 19:47:51 | Bagder | oh nice |
| 19:48:10 | * | rasher notices that he hadn't removed the : from m:robe |
| 19:48:13 | kenzo | This is not working: RockboxUtility....and this: For 5.5G iPods These iPods have their storage exported as 2048-byte sectors. Simply add an argument to the 'newfs_msdos' command:.... and on top of it you have to be a nerd to learn another program in order to install Rockbox. Great work guys. |
| 19:48:34 | LambdaCalculus37 | kenzo: We'll be happy to refund any money you paid for Rockbox. |
| 19:48:43 | kenzo | I just love the attitude you guys are giving |
| 19:49:25 | rasher | kenzo: We *know* RockboxUtility doesn't work with HFS ipods. It's not supposed to. You're supposed to convert it to FAT32. We have a guide for doing that. You have failed to do so. |
| 19:50:02 | rasher | Alternatively, you can convert it using a Windows machine. |
| 19:50:03 | LambdaCalculus37 | We've already told you that Rockbox does not work on HFS iPods. |
| 19:50:06 | kenzo | Are you guys totally deaf???????? Blind???? or what? The guide has FLAWS!!!!!!!!!!!! |
| 19:50:09 | Bagder | I don't think its our fault your ipod is HFS |
| 19:50:17 | kenzo | I know it doesnt support HFS |
| 19:50:19 | Bagder | and now he's just rude |
| 19:50:24 | rasher | kenzo: No need to get abusive. |
| 19:50:32 | rasher | kenzo: You have yet to explain what your problem is |
| 19:50:49 | LambdaCalculus37 | kenzo: I think you're just angry because you can't follow simple instructions. |
| 19:51:20 | LambdaCalculus37 | We didn't write mtools, so how can we support it or give advice on it? That's best left to the people who *did* write it. |
| 19:51:32 | kenzo | lambda: you are seriously stoned. I have clearly written my problems, yet you insist on refering to the guide which is the basic problem!!!!!!!!!!!!!!!!!!!!!! |
| 19:51:41 | rasher | kenzo: Which step of the IpodConversionToFAT32 page is giving you trouble? |
| 19:51:48 | Bagder | kenzo: please calm down and talk to us |
| 19:51:48 | kenzo | 1 min |
| 19:51:54 | LambdaCalculus37 | kenzo: I usually am not stoned on Saturdays. ;) |
| 19:52:06 | DerPapst | heh ;) |
| 19:52:12 | kenzo | hehe;) |
| 19:52:18 | kenzo | this line: newfs_msdos -F 32 -S 2048 -v iPod /dev/rdiskNs2 |
| 19:52:23 | kenzo | command line |
| 19:52:34 | kenzo | and the Rockbox Utility |
| 19:52:52 | rasher | Stop talking about the utility. It's not relevant until you've converted your ipod to FAT |
| 19:52:57 | kenzo | which leaves me with the option of learning linux to play FLAC:D hahah |
| 19:53:19 | LambdaCalculus37 | And is that a bad thing to learn it? What's wrong with learning how to do things? |
| 19:53:34 | gevaerts | Why would you need to learn linux at all? |
| 19:53:37 | rasher | kenzo: What did you type for that command? Did you replace N with the number you found in the previous step? |
| 19:53:51 | kenzo | I agree - thats why I have been in fron t of my comp the last 10 hours! Im not kiddin |
| 19:53:57 | LambdaCalculus37 | gevaerts: Because we said so? ;) |
| 19:54:03 | kenzo | yes, i replaced it like it says |
| 19:54:14 | rasher | So what is the *exact command* you ran? |
| 19:54:18 | kenzo | haha, funny LAMDA |
| 19:54:18 | rasher | And what was the output? |
| 19:54:33 | kenzo | moment |
| 19:54:55 | * | LambdaCalculus37 wonders why people keep getting his handle wrong |
| 19:55:01 | kenzo | where can I possibly find that now when I have tried for 10 hours straight? |
| 19:55:16 | rasher | kenzo: well you could try again |
| 19:55:17 | LambdaCalculus37 | By pressing up at the command line a couple of times? |
| 19:55:57 | kenzo | ?? |
| 19:56:22 | Bagder | if you've tried it for 10 hours, one would think you would have it remembered by now... |
| 19:57:01 | kenzo | or maybe not - Im outta here! |
| 19:57:08 | DerPapst | kenzo: connect your ipod and rerun that command again after making sure N is still the same number |
| 19:57:08 | kenzo | Wankers! |
| 19:57:12 | rasher | Stop that. |
| 19:57:34 | Bagder | kenzo: if you can't be nice and polite, you can just as well leave |
| 19:57:34 | | Quit kenzo ("CGI:IRC (EOF)") |
| 19:58:03 | DerPapst | ... silence |
| 19:58:12 | LambdaCalculus37 | That was easy. |
| 19:58:45 | LambdaCalculus37 | Peace. |
| 19:59:22 | rasher | LambdaCalculus37: honestly, I don't think you were helping things.. |
| 19:59:52 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 20:00 |
| 20:00:40 | | Quit FOAD (Read error: 60 (Operation timed out)) |
| 20:00:41 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 20:01:31 | * | LambdaCalculus37 will remain quiet for a while here |
| 20:02:58 | | Join barrywardell [0] (n=barrywar@79.97.77.138) |
| 20:07:45 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 20:12:36 | | Quit stoffel ("leaving") |
| 20:14:43 | | Quit flydutch (Read error: 110 (Connection timed out)) |
| 20:14:55 | | Join showstopper [0] (n=4db57f33@gateway/web/cgi-irc/labb.contactor.se/x-b4b46d420ca60ea3) |
| 20:19:56 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 20:19:57 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 20:20:23 | | Quit showstopper ("CGI:IRC (Ping timeout)") |
| 20:22:07 | | Quit barrywardell () |
| 20:25:25 | | Join barrywardell [0] (n=barrywar@79.97.77.138) |
| 20:32:10 | *** | Saving seen data "./dancer.seen" |
| 20:34:30 | | Quit aapo (Remote closed the connection) |
| 20:35:09 | | Quit bzed_ ("leaving") |
| 20:35:12 | mcuelenaere | gevaerts: shouldn't FS #10143 rather be a mail on rockbox-dev than a Flyspray item? |
| 20:35:17 | | Quit bzed ("leaving") |
| 20:35:24 | | Join bzed [0] (n=bzed@devel.recluse.de) |
| 20:37:31 | gevaerts | mcuelenaere: mails tend to be forgotten about, flyspray tasks not so easily |
| 20:55:48 | | Join merbanan [0] (n=banan@c-83-233-163-99.cust.bredband2.com) |
| 20:57:03 | | Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 20:58:22 | | Join pyro_maniac [0] (i=foobar@p57BB98E1.dip0.t-ipconnect.de) |
| 20:59:23 | | Quit pyro_maniac1 (Read error: 110 (Connection timed out)) |
| 21:00 |
| 21:00:09 | | Quit jhMikeS (Nick collision from services.) |
| 21:00:11 | | Join _jhMikeS_ [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 21:01:26 | | Join archivator [0] (n=archivat@77.70.28.57) |
| 21:01:54 | MT | merbanan : Hi :), in COOKContext , is the initial value of "random_state" always zero ? |
| 21:02:13 | merbanan | MT: doesn't matter |
| 21:02:30 | merbanan | can be anything it is just a random seed |
| 21:03:14 | | Join PaulJam__ [0] (i=PaulJam_@vpn-3017.gwdg.de) |
| 21:03:35 | MT | merbanan : I was just checking to see if the code is working properly (after the isolation of the codec an all that) .. after I call cook_decode_init I always get a random_state of zero |
| 21:04:07 | | Join EternalRains [0] (n=Abztrkhi@c-24-127-231-171.hsd1.fl.comcast.net) |
| 21:05:54 | | Join PaulJam [0] (i=Paule@vpn-3011.gwdg.de) |
| 21:07:52 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 21:10:40 | | Quit PaulJam__ (Read error: 60 (Operation timed out)) |
| 21:15:50 | | Join dmb [0] (n=dmb@unaffiliated/dmb) |
| 21:22:28 | | Quit PaulJam_ (Read error: 113 (No route to host)) |
| 21:31:34 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
| 21:32:28 | mcuelenaere | hmm is YUV data in Rockbox supposed to be displayed rotated? |
| 21:32:51 | | Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 21:32:57 | kkurbjun | mcuelenaere: it depends on the natural orientation of the player |
| 21:33:14 | kkurbjun | if the screen is portrait format the intention is for it to be rotated |
| 21:38:59 | | Join bluebrother [0] (n=Dom@f053154147.adsl.alicedsl.de) |
| 21:39:41 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 21:46:45 | * | MT waves to linuxstb :) |
| 21:54:06 | gevaerts | tomers: I'm not entirely sure if usb_class_driver.h is the right place for this PACK_DESCRIPTOR macro. On the other hand, I don't really know a better place either... |
| 21:54:35 | | Join PaulJam_ [0] (i=PaulJam_@134.76.3.8) |
| 21:55:06 | | Join froggyman [0] (n=47ba40e2@gateway/web/cgi-irc/labb.contactor.se/x-a8c4e7b34a203047) |
| 21:57:46 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 21:58:39 | | Quit dmb (Read error: 104 (Connection reset by peer)) |
| 21:59:45 | | Quit PaulJam (Read error: 60 (Operation timed out)) |
| 22:00 |
| 22:02:47 | gevaerts | On the other hand, it's just one small macro so moving it later is not a big problem I guess... |
| 22:03:31 | tomers | I also notices it is not the ideal place, but that was the one I can up with eventually |
| 22:03:51 | gevaerts | I'll commit it as-is. If we ever find a better place, we move it |
| 22:06:52 | mcuelenaere | what's the YUV test in test_fps.c supposed to show? some grey area? |
| 22:09:05 | | Join CIA-19 [0] (n=CIA@208.69.182.149.simpli.biz) |
| 22:15:33 | Unhelpful | so, would it probably be best in the jpeg reader to implement a getc and putc that work from a small-ish buffer? maybe 16B, larger if we want to reduce read frequency a bit? |
| 22:15:48 | Bagder | rasher: about the target names, how about a column that uses "line-model" if there's a line, and "company-model" otherwise? |
| 22:16:14 | | Quit jaykay ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]") |
| 22:16:55 | tomers | gevaerts: Please verify that FS #10146 (USB: Pass to the USB classes a pointer to USB core buffer) compiles before committing. I have no time to checkout a new, clean, tree. |
| 22:16:59 | Unhelpful | i'd started out with a small buffer that's read into at appropriate places, but that's getting to be painful, even while just processing the initial markers |
| 22:17:32 | gevaerts | tomers: I always do that anyway. Let me read through it first though :) |
| 22:17:53 | rasher | Bagder: done |
| 22:18:17 | rasher | That's probably a good compromise between unambigous and short |
| 22:18:47 | Bagder | and reasonably close to what we have today |
| 22:18:55 | mcuelenaere | rasher: have you seen FS #10137? |
| 22:19:26 | gevaerts | tomers: it misses the actual call to those functions |
| 22:20:09 | rasher | mcuelenaere: no, nice |
| 22:20:47 | rasher | mcuelenaere: unclear license on the js though :| |
| 22:21:02 | mcuelenaere | heh, I guessed something like that would arise :) |
| 22:21:05 | mcuelenaere | I could rewrite it |
| 22:22:08 | tomers | gevaerts: Are you sure? They are callbacks. The are being called in control_request(). See usb_core_request_endpoint() |
| 22:23:21 | gevaerts | tomers: I get http://pastebin.com/m1a521203 |
| 22:23:52 | * | gevaerts wonders if mcuelenaere saw that he added some red earlier today |
| 22:24:00 | mcuelenaere | more? |
| 22:24:13 | | Join jmillikin [0] (n=jmilliki@c-24-130-159-24.hsd1.ca.comcast.net) |
| 22:25:08 | gevaerts | r20730 apparently |
| 22:25:19 | CIA-19 | mcuelenaere r20734 trunk/firmware/target/mips/ingenic_jz47xx/onda_vx767/lcd-onda_vx767.c: Really fix red |
| 22:25:59 | | Part sdubois92 |
| 22:28:10 | | Quit barrywardell () |
| 22:29:06 | tomers | gevaerts: Thanks. I've uploaded an updated patch. |
| 22:31:02 | | Quit FlynDice (Remote closed the connection) |
| 22:32:03 | gevaerts | tomers: still not OK. http://pastebin.com/m23424da8 |
| 22:32:12 | *** | Saving seen data "./dancer.seen" |
| 22:33:23 | tomers | gevaerts: Fixed. I must be tired! |
| 22:33:33 | | Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) |
| 22:35:28 | gevaerts | tomers: it compiles now. Now I'm trying to understand what it's good for :) |
| 22:36:24 | | Join schrottplatz [0] (n=max@f053225254.adsl.alicedsl.de) |
| 22:36:32 | gevaerts | You want to centralise control handling I guess? |
| 22:36:39 | tomers | gevaerts: I had to send data in the HID from the control request handler. I either had to implement a statically allocated buffer in the HID class, or use the one in the USB core. |
| 22:37:27 | tomers | This will allow in the future for the class drivers not to allocate buffer statically. |
| 22:37:29 | gevaerts | hm, ok. I guess HID is a bit special in that it needs more data to set things up than to actually function |
| 22:37:59 | tomers | But do you think that this is the appropriate solution? |
| 22:38:07 | gevaerts | I mean, for storage we don't care because we use dozens of kilobytes anyway |
| 22:38:44 | gevaerts | well, that memory is there anyway, so we might as well use it |
| 22:39:05 | | Join barrywardell [0] (n=barrywar@79.97.77.138) |
| 22:39:14 | tomers | Great :-) So are you going to commit this? |
| 22:39:26 | gevaerts | yes |
| 22:40:20 | | Quit FlynDice (Remote closed the connection) |
| 22:40:54 | CIA-19 | gevaerts r20735 trunk/firmware/usbstack/ (6 files): Allow class drivers to reuse the core data buffer for control transfers. This doesn't make much difference right now, but it should keep HID memory ... |
| 22:43:48 | | Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 22:45:23 | mcuelenaere | gevaerts, tomers: did you try this patch on target ? |
| 22:46:03 | gevaerts | mcuelenaere: I didn't, but it's part of a larger patch that does work. Did it break anything? |
| 22:46:37 | mcuelenaere | I'm not sure, I'm getting device descriptor read errors |
| 22:48:00 | | Quit midijunkie ("?(???~•~)?") |
| 22:49:19 | | Join midijunkie [0] (n=Miranda@pD954737A.dip0.t-ipconnect.de) |
| 22:49:22 | gevaerts | I don't really see how that can be caused by these changes. They just pass a pointer that's not even used for now. Let me get a target... |
| 22:49:42 | | Join Harman [0] (n=chatzill@75.143.251.250) |
| 22:49:45 | mcuelenaere | hmm then this will probably be my buggy USB driver |
| 22:49:48 | | Quit midijunkie (Client Quit) |
| 22:49:54 | mcuelenaere | reverting to r20734 didn't resolve it, so nvm |
| 22:50:02 | | Join midijunkie [0] (n=Miranda@pD954737A.dip0.t-ipconnect.de) |
| 22:53:30 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 22:53:35 | | Join evilnick1 [0] (n=evilnick@pool-173-52-140-21.nycmny.east.verizon.net) |
| 22:53:59 | schrottplatz | hmmmm |
| 22:54:07 | schrottplatz | somehow i dont like the main menu |
| 22:54:19 | | Join killan [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 22:54:29 | | Quit FOAD (Read error: 60 (Operation timed out)) |
| 22:54:30 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 22:55:18 | | Quit _jhMikeS_ (Nick collision from services.) |
| 22:55:22 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 23:00 |
| 23:00:05 | gevaerts | mcuelenaere: I can confirm that the code still works properly on my mini |
| 23:00:14 | mcuelenaere | ok |
| 23:00:35 | CIA-19 | mcuelenaere r20736 trunk/firmware/target/mips/ingenic_jz47xx/lcd-jz4740.c: Fix some issues with YUV blitting on Onda VX747 (still not working properly) |
| 23:01:52 | amiconn | mcuelenaere: The yuv test in test_fps is supposed to show a two-dimensional colour gradient |
| 23:02:06 | mcuelenaere | oh |
| 23:02:16 | mcuelenaere | is there any screenshot of that somewhere? |
| 23:02:29 | amiconn | One axis varies the U component, the other varies the V component |
| 23:02:47 | amiconn | The Y component is fixed |
| 23:03:12 | amiconn | And the format is indeed 4:2:0. This isn't chosen by rockbox, it's just the standard MPEG YUV format |
| 23:03:31 | mcuelenaere | YUV 4:2:0 ? (not YCbCr 4:2:0) |
| 23:03:50 | amiconn | There is no target screenshot since this is blitted directly to the lcd. The sim should show it though iirc |
| 23:03:56 | | Quit _Auron_ (Read error: 104 (Connection reset by peer)) |
| 23:04:16 | | Quit LambdaCalculus37 ("too nice to sit on my butt all day") |
| 23:05:02 | amiconn | Yeah, YCbCr to be precise. YUV is just shorter (although not 100% precise naming) |
| 23:06:00 | mcuelenaere | hmm the IPU supports both YUV 4:2:0 and YCbCr 4:2:0 as input format |
| 23:06:39 | tomers | gevaerts: I uploaded yet another cosmetic patch. I'm starting to 'clean my desk up' before the HID patch. Maybe I'll do it tomorrow, as I am going to sleep soon... |
| 23:07:12 | gevaerts | there's no hurry |
| 23:07:29 | | Join Keripo [0] (n=Keripo@eng004.wireless-resnet.upenn.edu) |
| 23:10:19 | | Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) |
| 23:10:29 | amiconn | mcuelenaere: The sim does indeed show how test_fps yuv output should look like |
| 23:10:44 | froggyman | is there a list of all the screen sizes somewhere, for all supported rockbox targets? |
| 23:10:50 | mcuelenaere | yes, I saw it (and on-target doesn't look like it at all) |
| 23:11:00 | mcuelenaere | @amiconn |
| 23:11:33 | bluebrother | froggyman: check the firmware/export/config-*.h files or rbutil/rbutilqt/rbutil.ini |
| 23:11:47 | | Quit evilnick (Read error: 113 (No route to host)) |
| 23:11:50 | bluebrother | it's not a list of all screen sizes but they are present there. |
| 23:11:57 | gevaerts | tomers: I haven't gone through it all yet, but you replace 0x80 by USB_DIR_IN somewhere in usb_core_ack_control(). While the USB_DIR_IN is indeed 0x80, I tend to see it more as an endpoint address kind of thing |
| 23:12:16 | * | gevaerts is probably being silly about it |
| 23:14:22 | froggyman | but, there isnt a list on the wiki of the screen sizes |
| 23:14:38 | rasher | froggyman: DeviceChart |
| 23:16:12 | tomers | gevaerts: I agree with you (for now). Can you please remove this, and continue with the reviewing process, and I'll look over it more seriously later? |
| 23:16:48 | gevaerts | ok |
| 23:16:49 | tomers | Maybe there's more appropriate #define for that. Anyway, I dislike having hard-coded values in the code... |
| 23:17:30 | gevaerts | Actually, usb_ch9.h has "It's also one of three fields in control requests bRequestType" in the comment that explains USB_DIR_IN |
| 23:18:32 | froggyman | rasher: where exactly do i find that? |
| 23:18:51 | bluebrother | froggyman: that's a wiki name. Just go to the wiki page with that name |
| 23:18:59 | rasher | froggyman: You type in DeviceChart in the "Go" field |
| 23:19:10 | rasher | or the search field in the menu |
| 23:19:33 | bluebrother | search? What's that? |
| 23:20:42 | froggyman | ok enough of the mockery, i found it |
| 23:25:39 | | Quit Harman ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]") |
| 23:27:59 | gevaerts | tomers: I think I'll leave that USB_DIR_IN there. The comment in usb_ch9.h makes it clear that it applies to bRequestType as well |
| 23:32:44 | CIA-19 | gevaerts r20737 trunk/firmware/ (6 files in 3 dirs): USB related Cosmetics, whitespace and readability fixes (FS #10147 by Tomer Shalev) |
| 23:33:47 | Bagder | http://build.rockbox.org/cvsmod/chlog-20090418T213314Z.html <= now with the correct menu setup |
| 23:35:45 | | Quit einhirn_ ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 23:39:01 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 23:48:34 | | Quit Horscht ("Verlassend") |
| 23:48:55 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 23:51:01 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 23:51:01 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 23:52:37 | | Quit Seed ("cu, Andre") |
| 23:58:37 | | Quit archivator () |
icon identifies that the person is a core developer (has commit access).