| 00:02:58 | | Quit martian67 ("gone") |
| 00:04:23 | | Join martian67 [0] (i=lol3izer@about/linux/regular/martian67) |
| 00:04:51 | | Join solexx [0] (n=jrschulz@e176116136.adsl.alicedsl.de) |
| 00:06:40 | | Join phinze [0] (n=phinze@173-19-89-233.client.mchsi.com) |
| 00:07:03 | | Quit phinze (Client Quit) |
| 00:07:30 | | Join phinze [0] (n=phinze@173-19-89-233.client.mchsi.com) |
| 00:07:53 | | Quit solexx_ (Read error: 60 (Operation timed out)) |
| 00:08:20 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 00:09:31 | | Join T0paz [0] (n=jonny@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) |
| 00:11:30 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) |
| 00:13:26 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
| 00:13:58 | | Quit phinze ("leaving") |
| 00:15:46 | | Quit bertrik ("Leaving") |
| 00:18:23 | | Quit {phoenix} (Read error: 104 (Connection reset by peer)) |
| 00:21:05 | | Quit balug_ ("Ex-Chat") |
| 00:28:44 | | Join film42 [0] (n=GT@ip68-96-68-104.oc.oc.cox.net) |
| 00:29:31 | | Quit Acksaw (Connection timed out) |
| 00:35:18 | | Quit LambdaCalculus37 ("Ka-chunka") |
| 00:37:27 | | Join Strife89 [0] (n=michael@204.116.244.200) |
| 00:42:19 | | Quit n1s () |
| 00:55:29 | | Join Lapoot [0] (n=408b682e@gateway/web/cgi-irc/labb.contactor.se/x-ff94ee7aa7fa9e3f) |
| 00:56:41 | | Quit Lapoot (Client Quit) |
| 00:58:24 | Unhelpful | Llorean: with 32 (or even 33) levels, you can fade rgb565 pixels with one 32-bit multiply. you can go to 64 or 65 levels with two multiplies per pixel. if you want two blend two pixel values, that's two fades, so either two or 4 multiplies per pixel, depending on quality |
| 01:00 |
| 01:00:20 | Unhelpful | for AA fonts, if we make the glyphs 8-bit grayscale bitmaps, we can just use their values as the mask for blending pixel values to the screen |
| 01:02:18 | Unhelpful | it looks like the current AA font patch uses 4-bit (ie, 16 levels) fonts... so the color blending can be optimized to one multiply. |
| 01:03:16 | | Quit Xerion (Read error: 104 (Connection reset by peer)) |
| 01:03:45 | Unhelpful | it might be better to use N^2, rather than (N^2)-1, as the "top" value for blends, simply because bringing them back into scale after a multiply can be done with a shift |
| 01:09:00 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 01:11:07 | | Quit ender` (" In politics, absurdity is not a handicap. -- Napoleon Bonaparte") |
| 01:13:38 | | Part toffe82 |
| 01:13:50 | Unhelpful | hrm, it also special-cases fully-transparent and fully-opaque now. i wonder if that's actually a good idea... all depends on the cost of branches, i suppose |
| 01:15:16 | amiconn | The font cache is 4KB on archos, 10KB now on newer lowmem targets, and 60KB on bigmem targets |
| 01:16:21 | amiconn | 16-GNU-Unifont.fnt is 1.83MB |
| 01:16:29 | Unhelpful | any idea how costly branch misses are on coldfire/arm? |
| 01:16:31 | amiconn | That is 1-bit |
| 01:17:36 | Unhelpful | amiconn: unifont is actually not a great choice for an example font, since it's pretty much a pure bitmap font, as i understand it. there's a vector version, but it's outlines-of-squares for most of the glyphs |
| 01:17:59 | rasher | So turning on AA costs a restart and a tiny bit of buffer size? |
| 01:18:10 | amiconn | Well, all our fonts are bitmap fonts, because we're using .bdf as the source |
| 01:18:12 | rasher | It's not like the archoses can do AA anyway |
| 01:18:34 | amiconn | And .bdf does only andle 1-bit afaik |
| 01:18:39 | amiconn | *handle |
| 01:18:55 | rasher | It does. You'll obviously be using a vector format as source |
| 01:19:27 | Zoxc | Unhelpful and 50/50 is special too :) |
| 01:19:29 | * | amiconn just fails to see why we should do this |
| 01:19:58 | rasher | amiconn: Because aliased fonts are ugly? |
| 01:20:02 | Unhelpful | it really only makes any sense at all on color targets |
| 01:20:21 | amiconn | It costs buffer size, it bloats the shipped .zip, and it makes font rendering slower than it already is. |
| 01:20:36 | rasher | Everything has a cost |
| 01:20:49 | amiconn | Yeah, and colour targets are already suffering most from the slow font rendering |
| 01:21:06 | * | amiconn should really make test_gfx.c ready for commit |
| 01:21:23 | rasher | And yet people have been using this patch for a long time |
| 01:21:27 | * | amiconn doesn't deem aliased fonts ugly |
| 01:21:27 | Unhelpful | well... we could make a 2-bit AA font for the greyscale targets, but it would be unreasonable to try to do AA rendering for anything but black-on-white or white-on-black. |
| 01:21:48 | linuxstb | Does the AA patch remove support for the existing 1bpp fonts? |
| 01:22:10 | amiconn | Quite the opposite, with the sole exception of subpixel rendering (which we can't do because we don't know the panel orientation |
| 01:22:37 | rasher | Well that could be figured out, couldn't it? |
| 01:22:39 | Unhelpful | linuxstb: if i'm reading it correctly, fonts get a flag for whether they are 1bpp or 4bpp |
| 01:23:03 | amiconn | rasher: It differs at runtime, in an undetectable way, at least on some targets |
| 01:23:13 | Zoxc | it's much harder for computers to figure out subpixel orientation |
| 01:23:16 | amiconn | +I *know* that there are two different panels for H300 |
| 01:23:17 | | Quit suom1 (Read error: 104 (Connection reset by peer)) |
| 01:23:22 | rasher | amiconn: then let the user select it? |
| 01:23:37 | Unhelpful | rasher: subpixel would mean either making fonts 3x as large, and predetermining the subpixel values for them, or actually rendering vector fonts in rockbox |
| 01:23:54 | * | linuxstb doesn't see the problem with supporting AA fonts, as long as 1bpp fonts remain available |
| 01:24:05 | | Join suom1 [0] (i=markus@viitamaki.net) |
| 01:24:20 | Unhelpful | we already have a separate fonts pack, we could also have an AA fonts pack |
| 01:28:01 | linuxstb | BTW, regarding kugel's commit earlier today - do we really want to include unifont in every rockbox.zip? |
| 01:28:17 | amiconn | huh? |
| 01:28:40 | amiconn | Seen r19829 and r19831? |
| 01:28:44 | | Quit Strife89 ("Gone for dinner.") |
| 01:29:27 | linuxstb | amiconn: I've only read the commit messages. So it now doesn't include the font for every included theme? |
| 01:29:53 | amiconn | It does. Before them, it included too much |
| 01:30:08 | linuxstb | But before kugel's commit, it only included the default font. |
| 01:30:28 | amiconn | It should have included the fonts for the included themes, afaiu |
| 01:30:56 | linuxstb | That's not my understanding - the font for the default theme was included as a special exception. |
| 01:31:01 | amiconn | His fix uncovered another bug in wpsbuild.pl, which I fixed |
| 01:31:02 | rasher | It was broken already. It just erred on the side of including too little |
| 01:32:35 | amiconn | linuxstb: It just worked this way by coincidence - cabbiev2 specifies fonts using Font.WWW.HHH.D: whereas all other themes just specify Font: |
| 01:33:00 | amiconn | And we don't include unifont in all .zips, only those which have unicatcher |
| 01:34:05 | rasher | Which is what was the intention all along, as far as I can tell |
| 01:34:07 | linuxstb | Then it sounds like the implementation of including the default font was buggy - my recollection is that only inclusion of the default font was intended. |
| 01:34:39 | rasher | linuxstb: So for a standard build, most themes would be broken? |
| 01:34:55 | rasher | That seems a bit silly. |
| 01:34:57 | linuxstb | rasher: No - the user is expected to always install the fonts. |
| 01:35:04 | amiconn | There was this other bug anyway - it also included backdrops, icons, and viewer icons for all themes, not only those intended for the target |
| 01:35:07 | linuxstb | But we distribute them separately. |
| 01:35:17 | linuxstb | (because they very rarely change) |
| 01:35:38 | linuxstb | The default font is an exception, because things will break very noticably if a user boots into Rockbox before installing the fonts. |
| 01:35:50 | amiconn | Either we would need to distribute the themes separately, or include the necessary fonts. And iirc that was the intention |
| 01:36:10 | rasher | Then we shouldn't include the themes either, if you ask me |
| 01:36:26 | rasher | we could have a "themes and fonts" pack, then |
| 01:37:00 | amiconn | But that pack would be target specific, unlike the current fonts pack |
| 01:37:13 | rasher | Doom. |
| 01:37:37 | rasher | I just don't think it makes sense to distribute themes in the main package where they will not work without further work by the user |
| 01:37:48 | amiconn | Things would be better if we had that theme site up & running... |
| 01:38:01 | rasher | Stuff seems to be happening in the tracker |
| 01:38:58 | linuxstb | rasher: I don't see it as further work though - installing the fonts is part of the basic first-time install... |
| 01:39:31 | rasher | Assuming the user gets this right |
| 01:39:40 | rasher | And if he doesn't, that's our fault |
| 01:40:12 | | Quit flydutch ("/* empty */") |
| 01:42:03 | Unhelpful | hrm, the math in AA fonts is a bit confusing :/ |
| 01:44:03 | | Join ze [0] (i=ze@76.91.72.105) |
| 01:44:27 | Zoxc | a 4bit pallete is good enougth to represent subpixeled fonts |
| 01:45:28 | Unhelpful | Zoxc: yes, but you need values for the three subpixels. |
| 01:46:20 | Unhelpful | also, 3x as many multiplies :/ |
| 01:46:31 | Zoxc | why? :) |
| 01:46:54 | | Join Strife89 [0] (n=michael@204.116.244.200) |
| 01:47:03 | Unhelpful | because, if each subpixel is being blended the same amount, you multiply them all together. |
| 01:47:21 | Unhelpful | without even truly unpacking them |
| 01:52:56 | *** | Saving seen data "./dancer.seen" |
| 01:55:56 | Zoxc | can you filter subpixels before passing them as an bitmap? |
| 01:57:15 | Unhelpful | well, we could potentially generate LUTs for the current foreground color. we'll still need to per-subpixel scale the background, which may be an image. |
| 01:57:38 | | Join QuickStart [0] (n=QUICKSTA@pool-72-88-190-6.nwrknj.east.verizon.net) |
| 01:57:48 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 02:00 |
| 02:03:16 | | Join kugel [0] (n=kugel@e178105142.adsl.alicedsl.de) |
| 02:04:58 | kugel | linuxstb: I agree with rasher, that the fonts used by preinstalled themes should also be preinstalled |
| 02:05:31 | kugel | fonts are part of the theme. A theme without font is simply broken, and should either ship the font, or not be shipped at all |
| 02:06:19 | kugel | Unhelpful: it seems you got interested in AA fonts? |
| 02:07:21 | | Quit HellDragon (Client Quit) |
| 02:07:51 | kugel | amiconn: I don't know how much of a good example the e200 is, but I have used AA fonts for quite sometime, and there was no noticeable difference in drawing performance over normal fonts. Also, back when jott was active here, I talked to him, and he told me they're almost equally fast |
| 02:08:39 | Unhelpful | i get interested in things that can use interesting algorithms mostly. i think there's room to improve the speed and code/memory size of AA fonts... maybe. :) |
| 02:09:04 | kugel | maybe :) |
| 02:09:44 | Zoxc | how do you render colored subpixeled fonts? :) |
| 02:10:06 | Unhelpful | i just had to figure out how to do accurate division without dividing or multiplying. i think i can SWAR-ify the same method and use it on AA fonts, so that we can kill the LUT and retain reasonable performance |
| 02:10:11 | kugel | Unhelpful: oh, and you convert TTFs to AA fonts |
| 02:10:18 | Unhelpful | Zoxc: we're not doing subpixel |
| 02:10:23 | Unhelpful | at present, anyway |
| 02:10:40 | Zoxc | I was asking, in general :) |
| 02:11:03 | kugel | Unhelpful: I'd really like to see a performance comparision between the font rendering codes, do you have an idea how that could be doneß |
| 02:11:19 | Zoxc | loop them and use the rtc? :) |
| 02:11:43 | Unhelpful | Zoxc: well, pretty clearly, you need a different blend value applied to each pixel. if you're using RGB888, that's not a big deal, you have to scale per-subpixel *anyway*. |
| 02:11:46 | kugel | s/ß/?/ |
| 02:12:20 | Unhelpful | RGB565 is another matter... we can quite cheaply apply a scaling factor to all three subpixels of an RGB565 value with one multiply... provided they're all being scaled by the same amount. |
| 02:14:01 | | Quit culture (Read error: 145 (Connection timed out)) |
| 02:14:05 | Zoxc | couldn't you store the fonts as palettes and only color the palette? |
| 02:14:33 | * | Zoxc wants algorithm to color subpixeled fonts :) |
| 02:16:21 | pixelma | the screenshots I saw in the forums of WPSs with anti-aliased fonts just looked blurry to me |
| 02:16:45 | amiconn | For sub-pixel rendering we'd need 2*3bpp fonts, one for vertical and one for horizontal subpixel alignment |
| 02:18:05 | * | Unhelpful is pretty sure that most font renderers no longer use the "naive" method of applying the whole-pixel AA methods to each subpixel |
| 02:18:30 | | Quit xnyhps ("Zzzz...") |
| 02:18:46 | | Quit kachna (Remote closed the connection) |
| 02:19:20 | jhMikeS | Is there a better way to ensure an .o is linked first in plugins besides: http://pastebin.com/d3886603e (??) /* me hate makefiles */ |
| 02:19:30 | | Join evilnick [0] (i=620ec27e@gateway/web/ajax/mibbit.com/x-6cf2872f1b928fcb) |
| 02:19:44 | Unhelpful | wasn't that what first-generation subpixel AA did? and didn't it produce poor results? |
| 02:20:29 | Unhelpful | amiconn: or a font on disk with 9x9 subpixels that you scale down on load... but that sounds nasty. |
| 02:21:02 | Zoxc | I use r := value * rv div 256; but it doesn't include the background (r) in the formula |
| 02:21:07 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
| 02:22:10 | Zoxc | black on white gives good results without filtering :/ |
| 02:22:16 | Unhelpful | Zoxc: you just have to apply the inverse of that scale (255-n, assuming 0-255 alphas) to the background pixel or subpixel, and then add |
| 02:23:39 | Unhelpful | also, div 256 can be cheaply done as a shift, but is wrong if you're using 8-bit alpha values |
| 02:24:17 | Zoxc | well define apply :) |
| 02:24:20 | kugel | amiconn: AA fonts is a wanted feature, especially on targets which are just powerful enough for that. |
| 02:25:12 | kugel | also, the current patch completely remains the classic font rendering, so non-aa fonts aren't being slowed down at all (given that AA fonts are noticeably slower anyway) |
| 02:25:27 | kugel | and from my experience they are nto |
| 02:29:01 | Unhelpful | Zoxc: multiply bg pixel by (max-n), divide by maxn. mutiply fg pixel by n, divide by maxn, add. |
| 02:29:54 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 02:30:05 | amiconn | Classic font rendering is slow as-is on anything not vertically packed |
| 02:30:17 | amiconn | I have an old idea how to improve it |
| 02:32:19 | amiconn | This idea would allow algorithmic emboldening almost for free, and it might also fix rendering combining marks in most (simple) cases |
| 02:33:00 | amiconn | (i.e. anything that would require fancy things like variable vertical positioning) |
| 02:33:10 | amiconn | *would *not* |
| 02:35:04 | | Join yhuang [0] (n=yhuang@nat01-voorhees-ext.rutgers.edu) |
| 02:36:07 | jhMikeS | Unhelpful: c = (a*c1 + (max-a)*c0) / max = a*(c1 - c0) / max + c0 (knocks out another multiply) |
| 02:37:06 | Unhelpful | jhMikeS: true, but i don't think we can SWAR signed math, can we? |
| 02:37:55 | Zoxc | can we do fast low pass filtering? :) |
| 02:38:00 | | Join Lars_G [0] (n=Lars@ippool.ifxnetworks.com.ve) |
| 02:38:08 | Lars_G | Will I be hanged if I ask a peripherical question? |
| 02:38:36 | Unhelpful | with some masking tricks, you can multiply all three subpixels at once for rgb565, using one 32-bit multiply. making that worked signed seems likely to be a bit more tough :/ |
| 02:38:52 | jhMikeS | Unhelpful: I'll have to look into that if somehow I managed in an old project |
| 02:39:42 | evilnick | Lars_G: If it's totally offtopic then ask it in #rockbox-community |
| 02:39:55 | Lars_G | I'll try there |
| 02:40:16 | | Quit BigBambi (Read error: 54 (Connection reset by peer)) |
| 02:40:31 | | Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) |
| 02:40:38 | Unhelpful | i suppose it *might* be possible... hrm. |
| 02:41:47 | Zoxc | I'm mostly worried about the filtering since everything else might be cached to a degree |
| 02:41:52 | kugel | Unhelpful: I remember it started similary when you got into bmp resize, some little ideas, then concentrate on optimizing (still in mind), then doing :) |
| 02:42:07 | kugel | I'd be happy if you'd have a look at it |
| 02:42:32 | kugel | and looking at bmp.c/resize.c you seem to be able to understand font drawing :p |
| 02:42:53 | Zoxc | subpixeled albums! there we go :D |
| 02:43:03 | jhMikeS | Unhelpful: It definitely looks like I didn't :) |
| 02:44:16 | Unhelpful | jhMikeS: ok, i think it can be done... what we do for SWAR multiplies with RGB565 is take (c<<16) | c and mask out the individual colors, so that the high 16 only have G, and the low 16 have R and B |
| 02:45:13 | Unhelpful | this leaves at least 5B between each subpixel... to do signed subtractions, we would need to add a 1 bit to the left of each subpixel, which we can do with 1 OR, and then do the subract |
| 02:47:13 | kugel | Unhelpful: the patch implements 4bbps fonts. test have shown that it's basically equally to 8bbp quality-wise |
| 02:47:18 | kugel | 2bbp looked bad |
| 02:47:42 | kugel | and these 4bbp fonts look really good to me |
| 02:48:02 | jhMikeS | still having a fit about gcc here (trying to be sure to include a divX0 handler now for ARM in plugins and codecs) |
| 02:48:32 | Unhelpful | jhMikeS: a what? i'm still not sure why the link order of objects matters? |
| 02:49:15 | jhMikeS | function-sections makes it miss my implmentation of __div0 in favor of the libgcc one (which just returns 0) |
| 02:50:05 | | Quit PaulJam (".") |
| 02:50:11 | Unhelpful | ah, i suspect the order in which we link "our" objects won't matter then, unless we can explecitily make libgcc come last? |
| 02:51:00 | jhMikeS | I was making my gcc-support.o come first which fixes the issue (I've seen that suggested often in dealing with the problem for ARM) |
| 02:51:15 | jhMikeS | codec_crt0.c makes it a non-issue there |
| 02:52:03 | kugel | what's div0 supposed to do? divide by zero? |
| 02:52:15 | Zoxc | u16 foreground = cache[alpha]; color = color * (31 - alpha) >> 8 + foreground & 1F; could something like this work? |
| 02:52:25 | jhMikeS | plugins are a different story. I just wondered if there was a nicer way than what I pasted. My makefile chops are rather weak |
| 02:52:56 | Unhelpful | Zoxc: not for subpixel, no, unless we force fonts to always be subpixel-aligned. |
| 02:53:20 | jhMikeS | kugel: It's the standard handler for when the software division routines are passed a zero denominator. |
| 02:54:08 | Unhelpful | i'm pretty sure we can have different font colors per viewport, too, can't we? that means either an alpha cache per viewport, or one alpha cache that we are constantly regenerating. |
| 02:54:14 | jhMikeS | without your own, the default one will fail silently on ARM |
| 02:54:34 | kugel | ah |
| 02:54:46 | jhMikeS | anything div 0 returns 0 in the default |
| 02:54:52 | kugel | what's the return of that? 0? |
| 02:55:20 | kugel | Unhelpful: possible yes, but rather unused |
| 02:55:41 | * | kugel has never seen such a theme |
| 02:55:56 | jhMikeS | kugel: In the core we treat it like a data abort or undefined instruction and call UIE |
| 02:56:38 | Unhelpful | kugel: nonetheless, we need to support that :/ |
| 02:56:58 | kugel | sure |
| 02:57:23 | pixelma | kugel: I use different foregound colours in different viewports in the c200 and M5 version of my theme - even with a meaning |
| 02:57:30 | kugel | It won't be unsupported, just because it increases calculations? |
| 02:58:35 | Unhelpful | kugel: i'm just trying to decide if we truly even need a cache. i don't think it can even work if we want to do subpixel, but subpixel looks entirely too nasty to do, anyway |
| 02:58:42 | kugel | jhMikeS: I have seen divide by zero errors on my sansa, doesn't that mean it doesn't fail? |
| 02:59:00 | kugel | who says we want subpixel? |
| 03:00 |
| 03:00:01 | kugel | Unhelpful: using a cache will be benifitful in most cases, and don't change much in the rest, or? |
| 03:01:06 | Unhelpful | kugel: i just don't know. it saves us, i suppose, possibly one multiply per pixel, at the cost of calculating 16 pixel values to init it. |
| 03:01:46 | | Join Barahir_ [0] (n=jonathan@BAI097f.bai.pppool.de) |
| 03:02:20 | Unhelpful | amiconn: you don't feel that your graphics test/benchmark plugin is inclusion-ready... does it build and run? and could you maybe pastebin it? |
| 03:03:36 | kugel | Unhelpful: it saves recalculating the alpha values, is that just 1 multiply? |
| 03:03:40 | jhMikeS | kugel: If it got trapped, it happened in the core. The plugins and codec have none for ARM so far. |
| 03:04:01 | kugel | oh, I understand |
| 03:04:51 | kugel | Unhelpful: also, I think initing once in a while, but saving 1 multply per drawing is a good pay off |
| 03:05:13 | | Join Darksair [0] (n=user@221.221.157.6) |
| 03:05:26 | kugel | the alpha values don't change much, depending on the backdrop (IIUC) |
| 03:05:50 | jhMikeS | having the loader-initialized API pointers makes this worth doing now |
| 03:06:08 | | Quit tyfoo (Read error: 104 (Connection reset by peer)) |
| 03:06:28 | | Quit daurn (Remote closed the connection) |
| 03:06:43 | | Quit kachna (Read error: 113 (No route to host)) |
| 03:07:05 | Unhelpful | kugel: well, i figure we can cache pre-scaled text-color values, but we'll pretty much have to scale the BG per-pixel, won't we? |
| 03:08:10 | kugel | I don't think the current version does that (but don't quote me on that, I didn't understand it fully) |
| 03:08:16 | kugel | does *not*, I mean |
| 03:08:52 | kugel | uhm |
| 03:08:55 | kugel | does was right I guess |
| 03:09:51 | kugel | anyway, I'd really like to know how it performs against classic font drawing in the current version |
| 03:10:08 | kugel | some exact statistics I mean |
| 03:10:57 | QuickStart | umm can an alarm clock function be installed in an upcomming release of rockbox |
| 03:11:10 | Unhelpful | QuickStart: pretty sure we have one. |
| 03:11:30 | QuickStart | I mean with wakeup functionality |
| 03:11:32 | kugel | any e200 eq user here? |
| 03:11:54 | kugel | QuickStart: I think it's available for targets which have the hardware to do it |
| 03:12:47 | * | kugel isn't really convinced of the keymap in the eq screen on the e200 |
| 03:12:52 | QuickStart | does the e200 have it |
| 03:13:02 | kugel | no |
| 03:13:19 | QuickStart | k |
| 03:15:13 | | Quit kugel (Remote closed the connection) |
| 03:16:57 | | Quit Barahir (Read error: 110 (Connection timed out)) |
| 03:17:41 | Zoxc | Unhelpful, you think you can merge this? http://pastebin.com/m4fafea56 |
| 03:22:01 | Unhelpful | i'm not sure what it's supposed to be doing? |
| 03:25:08 | | Quit daurnimator (No route to host) |
| 03:27:03 | | Quit T0paz (Read error: 113 (No route to host)) |
| 03:36:51 | Lars_G | how do I make rockbox only charge on usb plug rather than go of?, on a e200 |
| 03:36:58 | | Quit xSlack ("Ex-Chat") |
| 03:37:08 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 03:39:31 | | Join xSlack [0] (n=brett@173-17-70-78.client.mchsi.com) |
| 03:39:59 | | Quit xSlack (Remote closed the connection) |
| 03:44:54 | | Quit gregorovius (Read error: 60 (Operation timed out)) |
| 03:45:46 | | Join gregorovius [0] (n=diego@host202.190-30-23.telecom.net.ar) |
| 03:53:00 | *** | Saving seen data "./dancer.seen" |
| 03:53:42 | | Part Lars_G |
| 03:56:38 | | Quit Thundercloud (Remote closed the connection) |
| 03:59:29 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
| 04:00 |
| 04:08:26 | | Join Barahir [0] (n=jonathan@BAI6fe7.bai.pppool.de) |
| 04:10:49 | | Quit QuickStart (Remote closed the connection) |
| 04:12:55 | | Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) |
| 04:16:18 | | Join blkhawk- [0] (n=blkhawk@g226137215.adsl.alicedsl.de) |
| 04:23:15 | edrz | well, Lars_G seems to have left, but I have the same question. |
| 04:23:23 | edrz | there is this FAQ: http://www.rockbox.org/twiki/bin/view/Main/SansaFAQ#Does_USB_work |
| 04:23:49 | | Quit agaffney (Read error: 54 (Connection reset by peer)) |
| 04:23:54 | | Quit martian67 (Remote closed the connection) |
| 04:23:59 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
| 04:24:10 | | Quit Barahir_ (Read error: 110 (Connection timed out)) |
| 04:24:25 | | Quit Darksair (Read error: 104 (Connection reset by peer)) |
| 04:24:36 | edrz | but, my e250r shows the USB connection icon when plugged into USB while rockbox is running, but otherwise appears to hang and doesn't show up on the USB bus (debian lenny stock kernel) |
| 04:25:14 | | Join martian67 [0] (i=lol3izer@about/linux/regular/martian67) |
| 04:28:30 | edrz | if powered off, it books into the original firmware when plugged into USB ... |
| 04:29:19 | edrz | are the sansa's rockbox USB issues something that can possibly be fixed in the future? |
| 04:32:31 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
| 04:33:17 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@g226137215.adsl.alicedsl.de) |
| 04:38:14 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 04:39:19 | Unhelpful | pluginlib albumart searching. any thought before commit? i think perhaps cheating include guards might be cleaner than using #ifdef PLUGIN around the includes in the core source file... unhelpful.pastebin.com/m7e0ee32e">http://unhelpful.pastebin.com/m7e0ee32e |
| 04:40:11 | | Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) |
| 04:40:14 | | Join Darksair [0] (n=user@221.221.157.6) |
| 04:42:59 | rasher | Unhelpful: are you missing a file? Or do I just not undestand how this works |
| 04:47:51 | Unhelpful | not sure what you mean? it works like the other pluginlib_* files, it directly includes a core file, with some defines to cover up rb for core function calls that that file makes |
| 04:48:06 | Unhelpful | oh, wait, i see what you mean :) |
| 04:49:38 | Unhelpful | this better? unhelpful.pastebin.com/m1b2fa807">http://unhelpful.pastebin.com/m1b2fa807 |
| 04:49:45 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 04:50:19 | rasher | That would be the one I was looking for. I'm not one to judge the work though |
| 04:51:13 | | Quit Nico_P (Remote closed the connection) |
| 04:51:19 | Unhelpful | well, it's similar to existing work for bitmap loader/scaler in pluginlib on mono targets. :) |
| 04:54:40 | | Join unpaidbill [0] (i=bill@420nugs.info) |
| 04:54:55 | unpaidbill | so, any chance the docs are wrong and rockbox actually does work on a sansa e260v2 ? |
| 04:55:36 | Unhelpful | supported targets are on the front page at rockbox.org |
| 04:58:21 | | Quit gregorovius () |
| 04:59:39 | unpaidbill | that's what i was afraid of. |
| 04:59:52 | unpaidbill | disappointing, but at least it's not as bad as being stuck with ipod firmware :P |
| 05:00 |
| 05:08:58 | | Quit Darksair ("Do you hear that? This is the sound of inevitability. This is the sound of your death, Mr. Anderson.") |
| 05:10:50 | | Quit BHSPitLappy (Remote closed the connection) |
| 05:20:32 | | Quit agaffney (Read error: 54 (Connection reset by peer)) |
| 05:21:27 | | Quit Strife89 ("Going to bed. 40 minutes to midnight.....") |
| 05:33:04 | edrz | was that a bad question? |
| 05:38:40 | | Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 05:38:45 | | Quit HBK (Client Quit) |
| 05:39:41 | | Join Minthe [0] (n=Minthe@gw13.ecc.u-tokyo.ac.jp) |
| 05:40:38 | | Part Aurix_Lexico |
| 05:42:46 | | Quit havien (Remote closed the connection) |
| 05:50:57 | | Join havien [0] (n=none@68-189-143-101.dhcp.wlwl.wa.charter.com) |
| 05:53:01 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:06:57 | | Join m0f0x [0] (n=m0f0x@189-47-54-115.dsl.telesp.net.br) |
| 06:08:24 | | Join agaffney_ [0] (n=agaffney@gentoo/developer/agaffney) |
| 06:14:41 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 06:19:29 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
| 06:21:13 | | Quit agaffney_ (Read error: 104 (Connection reset by peer)) |
| 06:21:17 | Minthe | Is there BeChris? |
| 06:42:49 | | Join Davekong [0] (n=Davekong@64.252.170.210) |
| 06:57:42 | | Quit Minthe ("Leaving...") |
| 06:58:49 | | Quit __lifeless (Remote closed the connection) |
| 07:00 |
| 07:00:16 | | Part Davekong ("Leaving") |
| 07:01:45 | | Join __lifeless [0] (n=lifeless@90.151.33.49) |
| 07:14:30 | | Quit rocko ("Leaving") |
| 07:22:19 | | Quit axionix (Remote closed the connection) |
| 07:22:31 | | Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) |
| 07:28:47 | | Quit Seed ("cu, Andre") |
| 07:46:06 | Unhelpful | we have pictureflow on m:robe100 sim, and it should work on other swcodec targets with HAVE_TAGCACHE |
| 07:46:13 | | Join mint09 [0] (n=scott@c-75-71-12-234.hsd1.co.comcast.net) |
| 07:46:24 | Llorean | Why do we want pictureflow on targets without AA support in the WPS? |
| 07:46:44 | Unhelpful | but, it would appear that colors are inverted in greylib on m:robe100... is this a sim bug, or an actual oddity of the target? |
| 07:46:57 | mint09 | a buddy of mine told me you have some type of eraser for sansas (e200 and c200). can you guys send them this way if available? |
| 07:47:14 | Unhelpful | Llorean: to be able to look at your album art at all? pictureflow uses greylib on non-color targets, so it can display album art nicely on targets where core can't. |
| 07:47:59 | Llorean | Unhelpful: I guess it just seems like it'd be odd to have AA on the target if you could only use it in pictureflow and not in the WPS (and we'd get a lot of "Well, why not in the WPS?" style comments/requests) |
| 07:49:18 | Unhelpful | i just code what looks interesting, or what other people suggest that looks interesting. amiconn wanted to be able to use PF on mono, and it wasn't all that hard to do :) |
| 07:50:29 | Llorean | Aaah |
| 07:51:01 | Llorean | How fast is scaling? |
| 07:52:05 | Unhelpful | depends on the target, really. downscaler can process 2560x1600 in 16s on e200... i don't have any coldfire hardware to test, but i commited code to use the emac there, which should be substantially faster than the C math on those targets. |
| 07:53:03 | *** | Saving seen data "./dancer.seen" |
| 07:53:43 | Llorean | I was more thinking, regarding mpegplayer. |
| 07:54:09 | Llorean | On the Gigabeat F we can do about >50fps decoding, I think. |
| 07:54:16 | Llorean | At 320x240, that is. |
| 07:54:31 | Unhelpful | OH. the scaler is not really video-worthy on our targets, i suspect |
| 07:54:44 | Llorean | Well, you could probably do much lower quality for video. |
| 07:56:28 | Unhelpful | yes... jhMikeS and i talked about this a bit ago, he wanted to use the scaler for thumbnailing in mpegplayer. apparently we already have a nearest-neighbor scaler for that, but thumbnails could be done using a HQ scaler. |
| 07:57:01 | Llorean | Where would thumbnails be used? |
| 07:57:04 | | Quit mint09 ("Ex-Chat") |
| 07:57:39 | Unhelpful | i'm not sure... but he said that there's apparently already a thumbnail/preview generator that can scale. might be something he has locally. |
| 07:58:06 | Unhelpful | the only real use i can see is if mpegplayer implemented its own filebrowser |
| 07:58:19 | Llorean | Or for a different sort of seeking. |
| 07:58:39 | Unhelpful | why would we want to scale on seek? |
| 07:58:41 | Llorean | Like Netflix does on the xbox, show you a bunch of thumbnails of what's coming up so you can see further ahead than just 'current frame' |
| 07:58:59 | Unhelpful | ahh... i've never used seek on the 360 yet, but i get the idea |
| 07:59:02 | Llorean | Kinda like pictureflow, but with points in the video. |
| 07:59:18 | amiconn | Llorean: Choosing resume points, iiuc |
| 07:59:49 | Llorean | Aaah |
| 07:59:53 | Llorean | Thumbnails for bookmarks. |
| 07:59:55 | Llorean | Good idea |
| 08:00 |
| 08:00:33 | Unhelpful | in any case, the core scaler can certainly work for the purpose, but apparently right now the scaling is done on planar YUV data, while the scaler on color targets works in packed RGB. |
| 08:01:30 | Llorean | I suppose for slower targets we could have a "really bad" scaler that just scales down to the nearest integer fraction that fits on screen, maybe? For people who really just can't be bothered to re-encode. |
| 08:01:32 | Unhelpful | my suggestion was that if he wants to scale the planar YUV, he consider copying the scaler out to another file, to use the greyscale version of it. |
| 08:01:50 | amiconn | For greylib mpegplayer it should already be usable then, iiuc. That one just decodes Y |
| 08:02:14 | | Join Rob2223 [0] (n=Miranda@p4FDCDF3B.dip.t-dialin.net) |
| 08:02:33 | Unhelpful | amiconn: yes and no. it would still need a frontend that can feed the scaler... another thing i suggested he change, actually, if he were going to fork the scaler for that purpose |
| 08:02:48 | Unhelpful | hack out the callback stuff, since he'd be using it exclusively on in-memory data |
| 08:03:12 | amiconn | hmm |
| 08:04:23 | Unhelpful | it would make the code smaller, and marginally faster, for that purpose... on greyscale, a frontend to the core scaler would probably be a smaller solution. |
| 08:05:13 | amiconn | greylib = {greyscale, mono} |
| 08:05:52 | amiconn | Of course mpegplayer doesn't work on archos... but it does work on m:robe 100 |
| 08:06:23 | Unhelpful | the same frontend could work with the greyscale pluginlib scaler - that basically *is* the core scaler, built in pluginlib for targets where it's not useful in core. |
| 08:06:31 | amiconn | jhMikeS: I'm not sure that having the real div0 handler available is worth the hassle. div0 handling differs depending on target anyway. |
| 08:07:43 | | Join at0m [0] (n=a548c80b@gateway/web/cgi-irc/labb.contactor.se/x-89035dcd6b837335) |
| 08:08:47 | | Quit Rob2222 (Read error: 60 (Operation timed out)) |
| 08:09:09 | Unhelpful | amiconn: here's what i have so far: unhelpful.pastebin.com/m2499cda1">http://unhelpful.pastebin.com/m2499cda1 |
| 08:10:09 | Unhelpful | the loading screen is broken right now, since it uses colors in native mode... and for some reason, greylib brightness is inverted on m:robe100 sim |
| 08:10:53 | | Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) |
| 08:11:11 | Unhelpful | also, the #if LCD_DEPTH > 1 around all the set_foreground calls should go... and i should move some of the possibly-useful-elsewhere macros from pictureflow into the feature_wrappers.h :) |
| 08:11:17 | | Quit unpaidbill ("BitchX: take the red pill") |
| 08:11:44 | kadoban | Unhelpful: i believe "normal drawing" brightness is inverted on the m:robe100 sim as well (the standard lcd_ functions) |
| 08:13:48 | amiconn | The greylib shouldn't be inverted (i.e. 0 should be black, 255 should be full red). I thought I fixed that |
| 08:15:48 | Unhelpful | well, this is what i see on sim :/ |
| 08:17:23 | * | amiconn rebuilds some sims |
| 08:20:06 | Unhelpful | for the native-mode parts of PF that use bitmap drawing, what exactly should i be doing on mono? it looks like on mono, there is (because it would be useless) no color setting... so, what, draw just turns pixels on? |
| 08:22:18 | * | amiconn points Unhelpful to our fine wiki: http://www.rockbox.org/twiki/bin/view/Main/GraphicsAPI |
| 08:22:53 | amiconn | Meh, that reminds me of another thing I want to do... |
| 08:26:40 | lucent | ...dance? |
| 08:29:57 | * | amiconn just fixed mentioned wiki page a bit |
| 08:31:16 | lucent | reminds me that I want to fix up the description for building cross-compile tools |
| 08:31:29 | Unhelpful | amiconn: ah... all i needed was an rb->lcd_set_drawmode in addition to the MYLCD(set_drawmode) :D |
| 08:31:53 | lucent | I'm not certain what to write in place, or how to address the fact that it presently suggests to edit rockboxdev.sh (while this has been made obsolete by environment variables) |
| 08:32:31 | Unhelpful | remove that suggestion, and document how it works now? |
| 08:33:23 | lucent | Unhelpful: we have the released versions though, does the Wiki reflect SVN now or released versions? |
| 08:33:28 | amiconn | lucent: No, improve & unify bitmap handling. There would be only one pair of functions: lcd_bitmap()/lcd_bitmap_part(). In-memory bitmaps would have a header telling whether they're mono, native, or transparent |
| 08:33:48 | lucent | sorry about distracting you folks from lcd stuffs |
| 08:34:03 | Unhelpful | lucent: hurgh.... yes, that's not pretty, either. |
| 08:34:26 | amiconn | This would also bring transparent bitmaps to greyscale and mono targets, using a mask bitmap referenced in that header |
| 08:34:45 | Llorean | lucent: I told you earlier, it should reflect SVN |
| 08:34:45 | Llorean | Do you still have me on ignore? |
| 08:34:45 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
| 08:34:53 | Unhelpful | amiconn: on color/grey targets, the header's format field indicates mono/native |
| 08:34:59 | | Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net) |
| 08:35:04 | Llorean | There's no "released version" of rockboxdev.sh |
| 08:35:06 | | Join alpha1beta [0] (n=Michael@unaffiliated/alpha1beta) |
| 08:35:11 | amiconn | The caller wouldn't have to worry about the type, it would be some kind of "bitmap object" (and that even though I don't like OO in general...) |
| 08:36:11 | Unhelpful | also, format is extended quite a bit, to tell the loader we want transparent, scaled, aspect preserved, etc. |
| 08:37:20 | amiconn | I'm not talking about the parameter to the bmp loader, but about in-memory bitmaps |
| 08:37:28 | Unhelpful | lucent: seriously, have you *still* got Llorean on ignore? because he's answered your question. |
| 08:37:53 | amiconn | Right now they're just arrays of either fb_data (native) or uint8_t (mono), and the caller needs to know what they are |
| 08:38:32 | amiconn | They would get a little header that states their type, as well as width and height (so those parameters would no longer be necessary for the respective functions) |
| 08:38:52 | Unhelpful | isn't that what's in struct bitmap? |
| 08:39:02 | amiconn | hmm? |
| 08:39:35 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 08:39:41 | Unhelpful | struct bitmap contains a pointer to the bitmap data, the width, the height, and, on grey/color targets, a format field, which the loader sets to FORMAT_NATIVE or FORMAT_MONO. |
| 08:40:39 | amiconn | Ah, forgot that someone already started on this in the loader |
| 08:40:40 | | Join flydutch [0] (n=flydutch@host5-154-dynamic.14-87-r.retail.telecomitalia.it) |
| 08:41:06 | Unhelpful | somebody? i could swear the file header says you were the last one to touch it before me :) |
| 08:41:34 | Unhelpful | (and i'm sure everybody who touches it has updated the comments) |
| 08:42:42 | amiconn | Well, anyway currently the various lcd drivers don't make use of that, as built-in bitmaps don't have it, only ones loaded from bmp |
| 08:43:28 | amiconn | The header will need a secondary data pointer for transparent bitmaps (on depths < 16) |
| 08:44:08 | | Join Tyler [0] (n=5ef5dd54@gateway/web/cgi-irc/labb.contactor.se/x-0deb91acc3114833) |
| 08:44:39 | | Nick Tyler is now known as Guest3700 (n=5ef5dd54@gateway/web/cgi-irc/labb.contactor.se/x-0deb91acc3114833) |
| 08:44:55 | Guest3700 | Hi guys! Is this the right place to ask for some quick rockbox support? |
| 08:45:11 | Llorean | Yes. |
| 08:45:18 | Llorean | But check in the manual first, please |
| 08:45:29 | lucent | for supported targets, sure |
| 08:47:39 | Guest3700 | i already read the iPod Video Manual but it didn't really help. I've installed Rockbox yesterday but now it looks like it's completely slowing down my iPod. Is this normal? |
| 08:48:09 | lucent | we refer to the original firmware as OF for clarity, and Rockbox as RB |
| 08:48:09 | Llorean | Guest3700: Slowing down how? |
| 08:48:21 | lucent | are you saying that OF is operating more slowly with RB installed? |
| 08:48:50 | Guest3700 | for example: I click on a track (any track) and it takes up to 40 seconds to start playing. |
| 08:49:07 | lucent | Guest3700: where from, though? OF or RB? |
| 08:49:22 | Guest3700 | RB |
| 08:49:49 | * | lucent tilts head pondering this |
| 08:50:11 | Llorean | Guest3700: Which SVN revision, and what settings have you changed? |
| 08:50:18 | Llorean | Are you using database or filetree, do you have album art? |
| 08:51:47 | Guest3700 | what's svn? I haven't changed any settings yet (except "Load to RAM" but I restored the default), there are no album covers. I'm using the database |
| 08:52:04 | Llorean | Are you using the release version, or the current version? |
| 08:52:28 | amiconn | Hmm, there's definitely a bug in the m:r100 sim colour setup |
| 08:52:30 | Llorean | You should set Load To Ram back on, that should speed things up significantly. You should also enable dircache, this is also described in the manual. |
| 08:55:43 | Guest3700 | I think it's the current version. I downloaded the automatic installer. Ok. I enabled the dircache and Load to RAM, rebooted but it's still slow. |
| 08:55:56 | Llorean | Is it also slow if you play from the filetree? |
| 08:56:20 | amiconn | It sets the "no-backlight" colours even if the simulated backlight is on (but with proper brightness mapping), and then is sets the "backlight" colours when pressing a button, but inverted |
| 08:56:25 | * | lucent wonders "what file format is this? Apple something-or-other?" |
| 08:56:46 | amiconn | Running fire.rock makes it obvious |
| 08:56:58 | Llorean | lucent: The file format *should* be irrelevant, it's most likely the database being slow. |
| 08:57:43 | at0m | how can we tell how much RAM is used by the DB? I've installed a larger disk in my player, and i'm afraid to fill the RAM with the DB instead of music buffer.. |
| 08:57:57 | lucent | Llorean: don't tell me that, tell Guest3700 |
| 08:57:57 | Guest3700 | Filetree is also slow -.- |
| 08:57:57 | Llorean | at0m: You could just not turn on "Load to RAM" |
| 08:58:23 | | Part alpha1beta ("Leaving.") |
| 08:58:25 | Llorean | Guest3700: If you select a song in filetree it takes 40 seconds to start? Is this a real time (timed) or are you exaggerating? |
| 08:58:33 | at0m | Llorean: that's what i'm doing, using file browser and disabled both directory and DB from RAM |
| 08:59:02 | Llorean | at0m: You can see how much RAM you have free in the debug menus. Check how much is available to buffering |
| 08:59:20 | at0m | Llorean: excellent, cheers. |
| 08:59:51 | | Join Rob2222 [0] (n=Miranda@p4FDCEE06.dip.t-dialin.net) |
| 09:00 |
| 09:00:29 | Guest3700 | Llorean: I just counted the time it took to start a new song and it's 35.2 seconds |
| 09:01:00 | Llorean | lucent: I told you that, because I thought it was information you might wish to be aware of when trying to help someone in the future (so that you might better ask them the most likely to be 'interesting' questions). I didn't direct it at him because I assume he can still read even if it has your name in front, and because there's no reason for him not to answer it at this poitn. |
| 09:01:42 | Llorean | Guest3700: And you said it wasn't doing this at first, then the behaviour started? What exactly did you do before it started? |
| 09:03:10 | Unhelpful | amiconn: so this may be a sim bug, not a greylib bug? i did notice that the greylib colors are *quite* strange with the "backlight" off - ie, bright red to medium grey, rather than bright red to dark red |
| 09:03:30 | * | lucent loses interest in helping today |
| 09:03:35 | Guest3700 | oh sorry. I think I didn't say that clearly: I installed Rockbox yesterday, syncronised it during the night and now I used it for the first time. So it never was "quick" |
| 09:03:51 | | Part lucent |
| 09:04:17 | Llorean | Guest3700: What do you use to sync? |
| 09:04:18 | amiconn | It seems like it's a sim bug. The sim colours for m:r100 are strange - imo they should be black to red for backlight on, and black to darkish grey for backlight off |
| 09:05:09 | Guest3700 | Mediamonkey 3. |
| 09:05:40 | Llorean | How are you playing songs in the filetree, exactly? (And in the database, for that matter?) |
| 09:07:15 | Unhelpful | what's mono+swcodec besides m:robe? |
| 09:08:01 | n1s | clip? |
| 09:08:04 | Guest3700 | Well ... I go to the certain folder, and SELECT-click the song. In Database it's the same (Path would be something like Database->Artist->AC/DC->Back in Black->Shoot to thrill.mp3) SELECT-click and wait |
| 09:08:14 | Unhelpful | that's the only other thing i can think of, as well |
| 09:08:38 | n1s | Unhelpful: i'm pretty sure it's the only one besides the mrobe |
| 09:08:58 | Unhelpful | and clip is unsupported, and not fully working? |
| 09:09:22 | n1s | Guest3700: is it as slow for all songs or only some? |
| 09:09:23 | Llorean | Guest3700: Could your player be highly fragmented? |
| 09:09:49 | n1s | Unhelpful: yes, it's unsupported not sure how well it works |
| 09:10:26 | Unhelpful | i'll pester gevaerts later, it appears he has both, anyway :) |
| 09:10:49 | amiconn | Actually the weird sim colours covered a few other bugs... |
| 09:10:58 | Unhelpful | here's the revised patch, the loading splash works properly on mono now: unhelpful.pastebin.com/m5f89025e">http://unhelpful.pastebin.com/m5f89025e |
| 09:11:56 | Guest3700 | I don't know, how can I check? (Sorry I'm a idiot at the computer) But now there's a small success: The Database now works really fast (Start, Pause, Resume) but the Playlist and the Filetree are still slow. By the way: I followed this tutorial to get my playlists to work with RB http://www.mediamonkey.com/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=12 |
| 09:12:51 | Guest3700 | ok. database is slow again -.- I didn't change anything |
| 09:13:07 | Llorean | Guest3700: Does it seem to depend on which song you select? |
| 09:14:30 | | Join Minthe [0] (n=Minthe@gw13.ecc.u-tokyo.ac.jp) |
| 09:15:45 | Guest3700 | no it doesn't depend on the song. but it seems like it needs some time to copy the songs from a folder into the RAM or something like that because after something like 40 seconds the first track starts to play and after that the following 5-8 tracks are also fast. (But that's just in the DataBase and sadly not in the Playlist...) |
| 09:16:13 | Llorean | What do you mean "in the playlist"? |
| 09:16:18 | Llorean | Both should buffer your audio. |
| 09:16:34 | | Quit rvvs89 (Read error: 110 (Connection timed out)) |
| 09:16:49 | Llorean | Which iPod do you have, and what "automatic installer" did you use? |
| 09:17:38 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 09:19:55 | Guest3700 | did you check the link I posted? When I first syncronised the iPod+RB with MM there were no Playlists because MM doesn't store them as .m3u... I used the "Rockbox Utility" from the official page (http://www.rockbox.org/twiki/bin/view/Main/RockboxUtility) |
| 09:21:57 | amiconn | There is a really ooooolld sim colour bug :\ |
| 09:22:18 | Llorean | Guest3700: Which iPod do you have? |
| 09:22:32 | amiconn | Looks like it's more than 3 years old |
| 09:22:41 | Llorean | And what about when you play from the filetree, does it skip quickly after it finished buffering there? |
| 09:24:34 | Guest3700 | iPod Video (5G) 30GB. No it doesn't skip quickly in filetree. It seems like it just buffers the current song, after the song's over it buffers the next song, etc.. |
| 09:25:10 | Llorean | You can check the buffering status via the debug menu. |
| 09:25:28 | Llorean | So the disk stops spinning when the first track is started, and spins again as soon as you try to skip? |
| 09:26:47 | n1s | Guest3700: which format are your songs in? |
| 09:27:36 | Guest3700 | is it the "View dircache info"? Yes that's the way how the disk currently works. Most of my songs are mp3 (about 95%) |
| 09:27:53 | | Quit Tristan (Remote closed the connection) |
| 09:29:37 | amiconn | Do we have a dedicated macro for inverted-display targets (like m:robe 100) already? |
| 09:29:43 | * | amiconn can't find any |
| 09:30:40 | Llorean | Guest3700: That will tell us if dircache is actually working. It wasn't what I'd intended, but worth checking |
| 09:32:04 | * | amiconn fixed the sim colour inits locally, but isn't sure about the best way to fix the inversion for m:r100 greylib simulation |
| 09:32:07 | Guest3700 | well what point of the debug menu is the one that helps you? "Buffering Thread"? |
| 09:32:55 | Llorean | That's the one. You should watch it while music is playing and see which buffers get full |
| 09:39:49 | * | amiconn exaggerated a little |
| 09:40:03 | Guest3700 | pcm is constantly changing (also when playing songs from the DB), alloc and real are changing from about 0% to 50% (when playing DB both of them were full) and usefl remains at 30% (only small changes). When the first track ends and the second one starts the are all empty |
| 09:40:16 | amiconn | The sim colour init bug was introducded on Feb 13 2006, in r8686 |
| 09:41:01 | Llorean | Guest3700: That's very unusual behaviour. |
| 09:41:06 | amiconn | ...and I "ported" the bug to the extended init (for greylib simulation) in r8845 |
| 09:41:06 | kadoban | amiconn: so will that actually invert the colors in the simulator (fixing that bug)? or is it somehow not that simple? |
| 09:41:21 | Llorean | PCM should fluctuate, the second two should be full I believe, and the last one should fill up, then empty, then fill up, then empty |
| 09:42:01 | amiconn | kadoban: That's another bug, actually. Colours in the sim looked weird right after sim start, and also right after greylib init, due to a bug in the initial colour setup (mixing backlit and non-backlit colours) |
| 09:42:26 | kadoban | ahh, i see |
| 09:42:27 | Guest3700 | In the worst case I'd have to uninstall RB -.- |
| 09:42:29 | amiconn | The inversion needs to be fixed as well, but I'm not sure where the best place to do this is |
| 09:43:44 | Llorean | Guest3700: In the filetree, are they sorted in folders by album, or are they in the iPod format with strange four-character filenames? |
| 09:45:30 | amiconn | There are several possible way to fix that. I could do it in the greylib (sim specific part) by inverting returned pixel values for mr100. I could also do it in the sim code, either by inverting the pixel value, or by inverting the sdl gradient |
| 09:46:00 | Guest3700 | yes. F00/P01 and so on. When I unchecked this option in MediaMonkey every single song was in X(iPod Drive letter):\Music\ |
| 09:46:09 | Guest3700 | no subfolders, etc. |
| 09:46:36 | amiconn | Doing it in the sim would have the advantage that I wouldn't need to check for mr100 specifically, but could compare UI_LCD_BGCOLORLIGHT and UI_LCD_FGCOLORLIGHT |
| 09:46:53 | Llorean | Guest3700: Have you tried removing the iPod structure, and just copying the files over normally and seeing if the problem goes away? |
| 09:46:56 | amiconn | But how do I compare "r, g, b" values in the preprocessor? |
| 09:49:18 | Guest3700 | No but MediaMonkey has two sync options: The first one is the usual iPod structure and the second one is different (like I said: evey song in \Music without any subfolders) I tried both ways with a small playlist (20 tracks) but it didn't make any difference. RB is slow... |
| 09:50:35 | | Join Davekong [0] (n=Davekong@64.252.170.210) |
| 09:50:43 | Llorean | Guest3700: Try just playing the songs from a folder, not using a playlist. |
| 09:51:11 | Guest3700 | same effect |
| 09:51:21 | Guest3700 | the only working thing is the DB |
| 09:51:22 | Llorean | There's no way you could've tried it. |
| 09:51:33 | | Join gregzx [0] (n=chatzill@dru199.neoplus.adsl.tpnet.pl) |
| 09:51:39 | Llorean | You have 27 seconds from when I said it to when you said "no effect" so it clearly wasn't 40 seconds this time if you did. |
| 09:52:26 | Guest3700 | no, I tried it some time ago (honestly). |
| 09:52:42 | Llorean | I thought you hadn't manually copied any songs over to have a normal folder structure |
| 09:53:01 | Llorean | That's what I'm suggesting |
| 09:53:04 | *** | Saving seen data "./dancer.seen" |
| 09:53:12 | Llorean | Copy a folder of songs over normally, and try playing a song in it. |
| 09:53:48 | Guest3700 | Oh! I thought this might be the same way how MediaMonkey syncronises when the Apple-Structure isn't enabled. Ok I'll try it |
| 09:56:01 | Guest3700 | the filepath just has to be something like this: X.\Artist\(album?)\xxx.mp3 right? |
| 09:56:34 | Llorean | Anything, really |
| 09:56:38 | kadoban | Guest3700: rockbox doesn't really care what the file path is |
| 09:56:41 | Llorean | Just put some songs in a folder and try to play one |
| 09:56:41 | | Join DogBoy [0] (n=john@unaffiliated/dogboy) |
| 09:57:12 | amiconn | Hmm, I'll probably just do a quick fix for now, then try to implement another idea of mine during the WE |
| 09:57:46 | amiconn | (moving the sim lcd colours to the config-<target>.h files, then use them for the sim, screendumps, ...) |
| 09:57:55 | | Part DogBoy ("Leaving") |
| 09:59:23 | amiconn | Right now mono screendumps always use the archos colours except for mr100, and 2bpp screendumps always use the h1x0 colours |
| 09:59:27 | Guest3700 | ok. In theory I copy music to the iPod, (safely) disconnect, go to Files->AC-DC->Black Ice->any mp3, right? |
| 09:59:37 | Llorean | Yes, click select on it |
| 10:00 |
| 10:00:07 | amiconn | This will need some funny preprocessor macros... |
| 10:00:31 | Guest3700 | sh*t ... there are no mp3s in the folder? I saw them in Windows explorer but RB can't find them ... |
| 10:07:41 | | Part Davekong ("Leaving") |
| 10:09:23 | Guest3700 | Well, thank you for you support Llorean but I'll now sadly uninstall RB. Once again: Thank you :-) Bye |
| 10:09:59 | | Quit Guest3700 ("CGI:IRC (EOF)") |
| 10:22:46 | Unhelpful | ok, i think that mono pictureflow is pretty much done... i cleaned up comments, the only other thing i can think of is maybe adding a feat_ prefix for things from feature_wrappers.h, but function/macro names are long enough, already. |
| 10:24:01 | | Join culture [0] (n=none@cpc2-bele3-0-0-cust89.belf.cable.ntl.com) |
| 10:49:12 | Unhelpful | amiconn: remind me to kill MEM_FUNCTION_WRAPPERS dead, and soon :/ |
| 10:49:54 | amiconn | Those should go into the pluginlib (which shouldn't be difficult now)... |
| 10:50:54 | Unhelpful | i know. mpegplayer borrows some files from codecs for mpeg audio decoding... it doesn't like the codeclib, though, does it? |
| 10:51:44 | amiconn | It compiles libmad on its own (due to potentially different iram usage) |
| 10:52:29 | amiconn | The codeclib wouldn't be useful (ci <-> rb) |
| 10:53:46 | amiconn | Unhelpful: Btw, the loader-inited codec api pointer probably needs fixing test_codec. Did you try that plugin after your change? |
| 10:54:22 | | Join fyrestorm [0] (n=fyre@cpe-68-173-234-24.nyc.res.rr.com) |
| 10:54:35 | Unhelpful | no, you're right, that probably does need to be fixed. won't be hard, should be pretty much the same as the plugin overlay loader |
| 10:55:11 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 10:55:21 | amiconn | Hmm, maybe not |
| 10:56:44 | amiconn | It uses rb->codec_load_file(), which should do the required init |
| 10:59:19 | n1s | is anyone against committing FS #9717 possibly enclosed in an #ifdef SIMULATOR to get rid of those annoying sim warnings? |
| 10:59:42 | Unhelpful | i wish i could say pf is "beautiful" on mrobe sim now... but it's as good as it'll get |
| 11:00 |
| 11:01:28 | | Quit Minthe ("Leaving...") |
| 11:01:35 | Unhelpful | have we tested if an #ifdef for sim makes it build quietly on both sim an target? |
| 11:02:52 | Unhelpful | amiconn: is test_codec the only reason that we *pass* the codec API pointer when loading codecs? or is there a reason that core needs to do that, as well? |
| 11:03:18 | amiconn | I think it's the only reason. codecs.c 's histoy should tell |
| 11:03:31 | n1s | the warnings only show up for sims because for some reason newer versions on the sdl headers include other headers that define those macros so #ifdef for sim should be fine, can't test locally because i don't get these warnings |
| 11:04:25 | * | Unhelpful does for clip :) |
| 11:05:47 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 11:06:09 | Unhelpful | amiconn: if that's the only reason, might it be possible to instead add a pointer to one core codec_api to the plugin API? |
| 11:06:43 | amiconn | ? |
| 11:07:20 | amiconn | The codec gets different apis, depending whether it's loaded from the core or from test_codec |
| 11:08:01 | Unhelpful | it does now, but does it have to? |
| 11:08:46 | Unhelpful | heh, pf looks a bit... funny on clip sim. |
| 11:10:08 | amiconn | Yes, it has to. test_codec mimics being the core |
| 11:12:36 | | Join T0paz [0] (n=jonny@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) |
| 11:12:54 | amiconn | I'm not sure greylib simulation is 100% correct in the sim. |
| 11:13:57 | | Join nplus [0] (n=nplus@243.131.Globcom.Net) |
| 11:14:33 | amiconn | In the *Clip* sim, I mean |
| 11:16:12 | bluebrother | Bagder: around? |
| 11:16:24 | amiconn | The sim sdl surface needs 2 colours normally for mono targets. Greylib simulation adds another 129 colours The Clip sim uses twice as many colours, meaning it would need >256 colours for greylib simulation. Since this is impossible for paletted surfaces, it does some nasty reduction |
| 11:16:28 | * | amiconn sigh |
| 11:22:04 | * | amiconn is building a clip sim |
| 11:22:12 | Unhelpful | amiconn: well, nasty or not, it certainly seems to work. i just mostly meant that PF knows *nothing* about the clip's segmented display - a few of my tall covers extend into it, and the title on the splash screen pretty much straddles the split |
| 11:22:52 | | Join gartral [0] (n=Gartral@75.33.64.73) |
| 11:23:07 | | Join {phoenix} [0] (n=dirk@p54B47B0F.dip.t-dialin.net) |
| 11:23:22 | T0paz | the creative firmware contains 5048 functions :/ |
| 11:23:38 | T0paz | going to be here a while |
| 11:23:51 | Unhelpful | hrm... but, it looks like LCD_HEIGHT is only the height of the blue part of the display? it's very odd, the reflections don't touch the display bottom as they should, but the FPS counter goes almost to the bottom (with album titles at top |
| 11:25:22 | amiconn | I guess this is due to the surface mixup |
| 11:25:45 | amiconn | The extra colours are just chopped off, it seems (i.e. set the same as the last used colour) |
| 11:26:11 | amiconn | LCD_HEIGHT is the height of the whole display (64) |
| 11:26:21 | Unhelpful | it also looks like we have the color inversion for greylib on clib, as well? |
| 11:26:43 | Unhelpful | the ? on the no-cover bitmap should be light |
| 11:27:10 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 11:27:26 | amiconn | cliblip ;) Yes, I think so |
| 11:28:47 | pixelma | Unhelpful: btw. the slightly smaller images in pf look odd on the c200 because the angles are not right |
| 11:29:07 | amiconn | hmpf |
| 11:29:29 | amiconn | Clip sim doesn't compile... (test plugins enabled, so invisible in the build table) |
| 11:29:40 | Unhelpful | pixelma: eh? i'm not sure precisely what you mean? |
| 11:30:00 | pixelma | ok, getting a screenshot for you |
| 11:30:14 | amiconn | Button map missing in greyscale.c |
| 11:30:40 | | Quit JdGordon (Remote closed the connection) |
| 11:31:48 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 11:36:07 | | Join PaulJam [0] (n=PaulJam_@vpn-3087.gwdg.de) |
| 11:38:49 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
| 11:44:00 | amiconn | Unhelpful: The clip also needs greylib inverted, but it's handle in the UI_LCD_SPLIT part. Just doing it there would be dirrty... |
| 11:45:08 | pixelma | Unhelpful: http://home.infocity.de/m.arnold/temp/c200-pf-comparisom.png . Note the "gap" between the outmost slides and the inner ones, it just doesn't look right in my eyes. It's probably due to the fact that the c200's screen has a more "widescreen" aspect ratio than others and pf always shows 5 slides |
| 11:45:33 | pixelma | hehe... typo in file name but the link is correct |
| 11:45:55 | Unhelpful | huh... how old is "old"? |
| 11:46:50 | Unhelpful | oh, and the change to using configfile would've wiped your settings and used defaults |
| 11:46:52 | pixelma | quite, don't know exactly... just found an old screenshot lying around here |
| 11:47:27 | pixelma | huh? |
| 11:47:46 | | Join merbanan [0] (n=banan@83.233.243.211) |
| 11:48:15 | pixelma | not sure what you want to tell me with this |
| 11:50:22 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 11:52:57 | Unhelpful | last weekend or so, i converted pictureflow to use configfile, instead of writing a struct out to disk. this would've caused it to use the default values for everything configurable, like the margin between the center and side covers, and the spacing between side covers. it also looks to me like the covers are *smaller*, though, and that's the part that really strikes me as strange. |
| 11:53:06 | *** | Saving seen data "./dancer.seen" |
| 11:55:30 | pixelma | I didn't adjust anything wrt to spacing so this is the new default. The smaller is what it makes things look odd I think and that's because of your change some time ago to make the slides LCD_HEIGHT/2 or so - was fixed 50x50 before on the c200 which is more than half of the screen height |
| 11:56:03 | | Quit AndyI () |
| 11:56:42 | Unhelpful | hrm, you may be right about that. |
| 11:57:22 | pixelma | smaller spacing makes it look a bit bettere |
| 11:57:27 | Unhelpful | that makes the "old" quite old... i think the major difference is the scaling and the new defaults, but perhaps i can get the defaults looking nicer at that aspect ratio |
| 11:57:29 | pixelma | better too |
| 11:59:00 | pixelma | it looks like spacing between the center piece and previous and next slide is fixed? |
| 11:59:39 | pixelma | I mean the 3 center ones |
| 12:00 |
| 12:01:18 | * | pixelma hates the also slightly broken pf button mapping on the c200 and that it's not easy fixable :\\ |
| 12:01:45 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 12:02:03 | Unhelpful | that's the "center margin" setting :) |
| 12:02:40 | pixelma | I often quit the plugin instead of going to the menu |
| 12:03:49 | Unhelpful | the blank space on either side of the middle slide is the "center margin" setting |
| 12:07:40 | pixelma | playing around a bit with it, it will look better when increased. The weird look is probably due to the fact that with the default center margin and spacing settings the spacing between the 3 center slides is smaller than the outer ones |
| 12:09:26 | | Quit AndyIL (Read error: 113 (No route to host)) |
| 12:09:45 | | Join MethoS [0] (n=lem@91.97.242.22) |
| 12:10:01 | gartral | thr e200s wont render more than 2 slides too either side untill you bump it too 12, then it "squashes" the right half of them over the slide your trying too view |
| 12:10:31 | pixelma | I also prefer the slightly bigger pictures in general because the lower part of the reflection is almost invisible anyways and then I like to see more "detail" in the art itself |
| 12:10:36 | | Quit nplus ("Leaving") |
| 12:11:01 | Unhelpful | gartral: bump what to 12? |
| 12:11:12 | gartral | the slide count, sorry |
| 12:11:23 | Unhelpful | 10 is the maximum. |
| 12:11:31 | gartral | and i meant to put 10, not 12 |
| 12:13:03 | gartral | oh, and center margin has to be 0 to reproduce the squashing and overlay effect |
| 12:14:31 | | Join bimbel [0] (n=Miranda@unaffiliated/bmbl) |
| 12:14:38 | Unhelpful | gartral: the e200 is also portrait - it doesn't have a lot of space, horizontally. and i don't know what you mean by "squashing", exactly? let me try these settings on mine... |
| 12:15:14 | gartral | no, dont bother, i cant get it too do it again, might have been a one off bug |
| 12:16:49 | | Join Guest14006 [0] (n=timmy@86.4.165.0) |
| 12:17:17 | Guest14006 | |
| 12:17:46 | Unhelpful | "number of slides" should probably go away, anyway - it just sets how many slides to render, something that we can calculate based on other settings |
| 12:17:48 | | Nick Guest14006 is now known as Timmmy (n=timmy@86.4.165.0) |
| 12:18:04 | | Quit timc ("Leaving") |
| 12:18:21 | | Join timc [0] (n=aoeu@124.93.243.83) |
| 12:19:58 | gartral | and the "spacing" setting dosnt seem to do anything, either |
| 12:22:10 | Unhelpful | it does, it's simply that it's practically impossible to see it on portrait targets. |
| 12:22:27 | Unhelpful | there's basically not room for more than three slides on the screen :/ |
| 12:23:26 | bluebrother | how about rotating the screen like mpegplayer does? |
| 12:24:11 | Unhelpful | a lovely idea, can core draw rotated text for use, as well? |
| 12:25:02 | bluebrother | no idea. Just had this idea popping into my mind |
| 12:25:18 | | Quit lightbulbjim (Read error: 113 (No route to host)) |
| 12:25:19 | gartral | also, im seeing the same reflection stopping before it hits the last pixel issue, it stops about 5 pixel away from bottom |
| 12:25:46 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 12:26:16 | Unhelpful | "the ... issue"... is this a known, previously reported bug? |
| 12:27:41 | Unhelpful | pixelma: could always make the size larger, and move the slides closer to screen top... |
| 12:30:03 | | Quit bmbl (Read error: 110 (Connection timed out)) |
| 12:31:35 | amiconn | Core cannot draw rotated text. mpegplayer implements its own version of that |
| 12:32:17 | * | amiconn still wonders who though that a portrait lcd would be a good idea on a dap |
| 12:32:22 | amiconn | *thought |
| 12:32:25 | Unhelpful | i feared that... sounds like a candidate for pluginlib |
| 12:32:53 | Unhelpful | i'm not sure, but all of ours have, except the karma, which is square-ish |
| 12:33:23 | gartral | huh, im seeing one more bug, a few albums have the wrong art associated too them, this is only apparent on one album so far, and the art file is 5 pixels thinner than it is tall |
| 12:33:31 | * | amiconn only has landscape targets except the beast |
| 12:33:46 | gartral | one albumart* |
| 12:33:48 | | Join tyfoo [0] (n=tyfoo@77-20-31-238-dynip.superkabel.de) |
| 12:33:59 | * | gartral only has an e250 |
| 12:34:05 | Unhelpful | gartral: is it supposed to be thinner than it is tall? |
| 12:34:45 | gartral | no, i mean the file was saved at 300x295, and it appears as the art for three albums |
| 12:35:35 | gartral | and im using the simple cover.bmp in with the audio files way of displaying them |
| 12:37:00 | pixelma | Unhelpful: aside from the my preferences - I guess the main "problem" is not accounting much for screen aspect ratios? I don't have an idea for a solution though |
| 12:38:33 | gartral | well, pictureflow is more the aesthetic plugin anyway, i would probably use it more if i could start a=or affect pplayback through it |
| 12:40:29 | amiconn | This should be possible once that it doesn't use bufalloc anymore |
| 12:41:05 | amiconn | (running it during playback, select an album to play, or perhaps even inserting individual tracks from an album) |
| 12:42:06 | | Join akur [0] (n=akur@82.155.158.245) |
| 12:42:46 | | Part akur |
| 12:42:58 | amiconn | It would simply act as yet another different browser. We already have two browsers anyway (file and database) |
| 12:43:09 | pixelma | on the c200 at least , it also needs better controls, otherwise you could only select the first track in an album to play ;\ |
| 12:43:53 | gartral | amiconn: you can start pictuerflow while playing if you get to it before the buffers fill, but it does cause the DAP to freeze up |
| 12:44:54 | amiconn | pixelma: That's really just a button map fix. It probably requires getting rid of PLA in PF, and going from there |
| 12:45:39 | JdGordon | why does PF need a mor complicated button map than PLA? |
| 12:46:14 | * | JdGordon gone again |
| 12:47:28 | pixelma | I know. Although if it has a quite standard control schem (up/down/left/right, select, menu, quit). If there was this one context to use... but it stupidly combines contexts |
| 12:49:56 | pixelma | JdGordon: I'd consider PLA in its current form and how it's used there the most complicated one, so everything else would be simpler |
| 12:49:59 | | Join lightbulbjim [0] (n=jim@203.171.93.108.static.rev.aanet.com.au) |
| 12:49:59 | amiconn | Combining PLA contexts will *always* break on some targets, so it must not be done. If a plugin would need combined contexts, it must not use PLA |
| 12:50:30 | amiconn | That doesn't mean it shouldn't use the action code, but then it needs to define its own, custom context(s) |
| 12:51:13 | amiconn | Imo all plugins should use the action code - it would remove the need for all this _PRE #ifdefing |
| 12:51:32 | amiconn | Same goes for alternate buttons triggering the same action (M3 comes to mind) |
| 12:55:28 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 12:55:59 | gartral | or pressing power on the e200s, causing it to both stop and go back a dir/quite WPS |
| 12:57:21 | amiconn | That's something different - bugs in the core keymap |
| 12:57:38 | gartral | ah |
| 13:00 |
| 13:00:03 | | Join miepchen^schlaf [0] (n=miepel@p579EC609.dip.t-dialin.net) |
| 13:01:14 | | Join Jaykay [0] (n=chatzill@p579E77AB.dip.t-dialin.net) |
| 13:05:24 | | Quit vertic24 (Read error: 110 (Connection timed out)) |
| 13:12:42 | | Quit at0m ("CGI:IRC (Ping timeout)") |
| 13:13:33 | | Join tvelocity [0] (n=tony@adsl4-123.her.forthnet.gr) |
| 13:18:09 | | Quit MethoS (Read error: 131 (Connection reset by peer)) |
| 13:22:25 | | Quit Jaykay (Read error: 104 (Connection reset by peer)) |
| 13:22:51 | | Join Jaykay [0] (n=chatzill@p579E77AB.dip.t-dialin.net) |
| 13:27:58 | | Join at0m [0] (n=a548c80b@gateway/web/cgi-irc/labb.contactor.se/x-d3536b03d35d0ec9) |
| 13:28:57 | | Quit m0f0x () |
| 13:37:20 | | Quit tvelocity (Read error: 110 (Connection timed out)) |
| 13:53:08 | *** | Saving seen data "./dancer.seen" |
| 13:58:08 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:59:48 | | Join Horschti [0] (n=Horscht@xbmc/user/horscht) |
| 14:00 |
| 14:15:12 | | Quit flydutch ("/* empty */") |
| 14:17:41 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 14:18:47 | Jaykay | llorean: please ping me when you are back |
| 14:26:49 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 14:27:16 | | Join gregzx_ [0] (n=chatzill@drx15.neoplus.adsl.tpnet.pl) |
| 14:27:52 | | Quit gregzx (Nick collision from services.) |
| 14:27:56 | | Nick gregzx_ is now known as gregzx (n=chatzill@drx15.neoplus.adsl.tpnet.pl) |
| 14:28:12 | | Quit HBK- (Read error: 104 (Connection reset by peer)) |
| 14:28:33 | | Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 14:32:19 | | Quit Thundercloud (Remote closed the connection) |
| 14:34:24 | | Quit jhMikeS (Nick collision from services.) |
| 14:34:30 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 14:35:18 | | Quit markun ("leaving") |
| 14:37:13 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 14:37:58 | amiconn | jhMikeS: What about using the SWI instruction for the div0 handler on arm? |
| 14:39:49 | * | amiconn is also not convinced that we really it. Just returning 0 is fine imo. Garbage in, garbage out |
| 14:40:43 | amiconn | Afaik SH1 division just returns 0 on div0, as does software division on coldfire (which we don't use anymore though) |
| 14:45:52 | | Quit AndyI (Read error: 104 (Connection reset by peer)) |
| 14:47:04 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 15:00 |
| 15:01:41 | | Quit {phoenix} (Remote closed the connection) |
| 15:07:57 | | Quit bimbel ("Woah!") |
| 15:16:19 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 15:18:43 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 15:35:11 | | Quit Thundercloud (Remote closed the connection) |
| 15:37:51 | | Quit faemir ("Lost terminal") |
| 15:37:56 | | Quit gromit` (Read error: 110 (Connection timed out)) |
| 15:41:05 | | Join gromit` [0] (n=gromit@ALagny-154-1-66-58.w86-203.abo.wanadoo.fr) |
| 15:42:10 | | Join stoffel_ [0] (n=sfr@p57B4F184.dip.t-dialin.net) |
| 15:47:58 | n1s | amiconn: isn't the point of a div0 handler to make it easier to fin div by 0 bugs? |
| 15:48:44 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
| 15:49:26 | | Quit Bensawsome (Read error: 104 (Connection reset by peer)) |
| 15:53:12 | *** | Saving seen data "./dancer.seen" |
| 15:58:53 | | Join Lynx_ [0] (n=till@xdsl-84-44-173-253.netcologne.de) |
| 16:00 |
| 16:00:11 | jhMikeS | amiconn: Hadn't thought about it. It would still need the wrapper API. Perhaps more elegant? |
| 16:06:19 | | Quit T0paz (Read error: 104 (Connection reset by peer)) |
| 16:07:19 | | Join gromit`` [0] (n=gromit@ALagny-154-1-74-251.w81-48.abo.wanadoo.fr) |
| 16:08:40 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 16:10:14 | | Quit Aurix_Lexico (Remote closed the connection) |
| 16:12:04 | | Quit gromit` (Read error: 60 (Operation timed out)) |
| 16:14:15 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
| 16:17:13 | | Join kugel [0] (n=chatzill@rockbox/developer/kugel) |
| 16:21:44 | | Join kugel_ [0] (n=kugel@e178084119.adsl.alicedsl.de) |
| 16:21:51 | | Quit kugel (Client Quit) |
| 16:21:57 | | Nick kugel_ is now known as kugel (n=kugel@e178084119.adsl.alicedsl.de) |
| 16:25:48 | | Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) |
| 16:25:51 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 16:29:26 | | Quit at0m ("leaving for home!") |
| 16:33:36 | | Quit __lifeless (Remote closed the connection) |
| 16:35:03 | | Quit stoffel_ ("leaving") |
| 16:35:21 | | Join _lifeless [0] (n=lifeless@90.151.33.49) |
| 16:35:37 | | Quit _lifeless (Remote closed the connection) |
| 16:36:11 | | Join _lifeless [0] (n=lifeless@90.151.33.49) |
| 16:37:34 | | Quit _lifeless (Remote closed the connection) |
| 16:38:03 | | Join _lifeless [0] (n=lifeless@90.151.33.49) |
| 16:39:47 | LambdaCalculus37 | Since I'm doing the Clip manual and some of that work may end up being included in other AMS Sansa targets, I think I may make a general installation chapter for these targets if they all have the same install method. |
| 16:40:19 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) |
| 16:40:56 | LambdaCalculus37 | Currently, it looks like the AMS Sansa bootloader install method is similar to that of the H100 and H300 (patch an official firmware update with our bootloader and let the device do a firmware update). |
| 16:41:18 | | Join T0paz [0] (n=jonny@spc1-horn1-0-0-cust255.cosh.broadband.ntl.com) |
| 16:42:27 | kugel | LambdaCalculus37: I think we didn't figure out the final installation mehtod yet :) But yes, as of now, it's requring patching a OF file using mkamsboot, and let the OF's firmware update procedure install our bootloader |
| 16:44:21 | LambdaCalculus37 | kugel: Yes, but when it comes to the time to make the AMS Sansas a supported target, we may end up making a different tool to do the work, similar to iPodpatcher or Sansapatcher, or FWpatcher for the iriver H100 and H300. |
| 16:44:32 | LambdaCalculus37 | But this is speculation, of course. :) |
| 16:48:32 | | Quit EspeonEefi ("さよなら") |
| 16:56:44 | kugel | Unhelpful: ping |
| 17:00 |
| 17:02:55 | | Quit kugel (Remote closed the connection) |
| 17:11:39 | | Join Xqtftqx [0] (i=4b7655d1@gateway/web/ajax/mibbit.com/x-0c031f514c7da1b2) |
| 17:12:20 | | Quit Xqtftqx (Client Quit) |
| 17:13:55 | | Quit miepchen^schlaf () |
| 17:16:54 | T0paz | does anybody know when mcuelenaere tends to be here? |
| 17:17:42 | gevaerts | T0paz: rasher.dk/rockbox/ircstats/2009.php">http://rasher.dk/rockbox/ircstats/2009.php |
| 17:18:22 | rasher | The timezone is (I believe) CEST |
| 17:18:57 | gevaerts | So (if I read that right) European evening |
| 17:19:31 | T0paz | ah, cool |
| 17:19:33 | T0paz | same as me |
| 17:19:47 | T0paz | (well, nearly) |
| 17:19:59 | | Quit AndyI () |
| 17:20:27 | T0paz | i have managed to successfully mess up the volume-fade-out when you pause, on this creative zen |
| 17:20:48 | T0paz | working without proper register descriptions isn't very easy |
| 17:23:10 | | Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) |
| 17:26:06 | | Quit robin0800 (Remote closed the connection) |
| 17:29:10 | | Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
| 17:29:31 | | Join xqtftqx [0] (i=4b7655d1@gateway/web/ajax/mibbit.com/x-64b16605fda84849) |
| 17:29:43 | xqtftqx | I may have just found out something with the zune! |
| 17:29:48 | xqtftqx | 1401/tcp open goldleaf-licman? |
| 17:29:54 | gartral | should the rockbox1d game be removed, or moved too demos, because it really isnt a game >.> |
| 17:30:18 | xqtftqx | I found the zunes IP adress when it was connected and ran a port scan and found that port 1401 is open on the zune |
| 17:30:46 | LambdaCalculus37 | xqtftqx: Can you find out something about the firmware signature that way? |
| 17:31:02 | xqtftqx | Im not sure, i dont even know what the port is |
| 17:31:36 | gartral | i would use a packet sniffer (like wireshark) too take a detailed examination of it |
| 17:31:49 | xqtftqx | yeah, im gonna take a look at what happens when it requests a song preview |
| 17:32:09 | xqtftqx | and maybe setup a dns server, and forward it to my own song. Maybe a buffer overflow? |
| 17:32:24 | xqtftqx | Then if we could run code, dump the flash and take a look that way |
| 17:33:08 | gartral | mm, i belive they do have to have some form of authentication from the zune servers at microsoft, but this is third hand knowledge |
| 17:33:47 | xqtftqx | Its a 30 second song preview |
| 17:34:23 | gartral | if m$ had there way, the zune would be a subscription only audio device >.> |
| 17:36:18 | xqtftqx | Im going to run an arp attack on the zune, see what i can find |
| 17:37:44 | xqtftqx | But i was just comming in here to say that there is sometihng |
| 17:41:40 | | Join toffe82 [0] (n=chatzill@adsl-75-12-168-240.dsl.frs2ca.sbcglobal.net) |
| 17:41:46 | xqtftqx | Port 1401: Goldleaf License Manager |
| 17:41:52 | xqtftqx | What do you think that is? |
| 17:42:10 | | Join pyro_maniac [0] (n=jens@77-21-68-46-dynip.superkabel.de) |
| 17:42:11 | gartral | drm authentication |
| 17:42:21 | rasher | xqtftqx: Whatever it is - that doesn't have to be what's running on that port. I wouldn't give it too much thought until you know what traffic happens |
| 17:42:40 | xqtftqx | I understand that, but thats what it looks like |
| 17:42:55 | gartral | like i said, it probably links back too microsoft, or proxies through them |
| 17:42:55 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 17:43:07 | xqtftqx | It does |
| 17:43:25 | gartral | then its %98 DRM related |
| 17:43:37 | xqtftqx | Whenever it requests a song, it starts sending stuff to microsoft |
| 17:43:51 | gartral | yep, thats what it sounds like |
| 17:44:26 | xqtftqx | Im just trying to find any holes i can for this thing |
| 17:44:59 | | Quit robin0800 (Read error: 54 (Connection reset by peer)) |
| 17:45:16 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 17:45:38 | | Quit robin0800 (Remote closed the connection) |
| 17:46:16 | | Quit xqtftqx ("http://www.mibbit.com ajax IRC Client") |
| 17:46:43 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 17:51:34 | gartral | i cant find anything on the goldleaf licman |
| 17:53:15 | *** | Saving seen data "./dancer.seen" |
| 17:57:55 | | Join kugel [0] (n=chatzill@e179036194.adsl.alicedsl.de) |
| 18:00 |
| 18:00:42 | | Part jon-kha ("[IRSSI] Irssi: just when you thought it couldn't get any better") |
| 18:00:54 | | Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) |
| 18:00:56 | | Join jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 18:01:08 | | Part jon-kha ("[IRSSI] Tiger Woods uses Irssi. FORE!") |
| 18:01:12 | | Quit kugel (Client Quit) |
| 18:01:14 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 18:01:29 | | Join kugel [0] (n=kugel@e179036194.adsl.alicedsl.de) |
| 18:07:24 | | Join kugel_ [0] (n=kugel@e179036194.adsl.alicedsl.de) |
| 18:08:48 | | Quit Makuseru (Read error: 104 (Connection reset by peer)) |
| 18:08:54 | | Quit kugel (Nick collision from services.) |
| 18:08:58 | | Nick kugel_ is now known as kugel (n=kugel@e179036194.adsl.alicedsl.de) |
| 18:11:13 | | Quit intrados () |
| 18:17:28 | | Join barrywardell [0] (n=barrywar@79.97.89.191) |
| 18:17:33 | | Part barrywardell |
| 18:17:53 | | Join barrywardell [0] (n=barrywar@79.97.89.191) |
| 18:19:07 | | Join jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 18:24:55 | | Join Jaykay_ [0] (n=chatzill@p579E79EB.dip.t-dialin.net) |
| 18:31:08 | | Join kugel_ [0] (n=kugel@e179036194.adsl.alicedsl.de) |
| 18:31:16 | | Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) |
| 18:31:52 | | Quit kugel (Nick collision from services.) |
| 18:32:02 | | Nick kugel_ is now known as kugel (n=kugel@e179036194.adsl.alicedsl.de) |
| 18:33:05 | | Nick kugel is now known as kugel_ (n=kugel@rockbox/developer/kugel) |
| 18:33:27 | | Nick kugel_ is now known as kugel (n=kugel@rockbox/developer/kugel) |
| 18:33:52 | | Join casainho [0] (n=chatzill@89-180-98-234.net.novis.pt) |
| 18:34:47 | casainho | hello :-) - I would like to know if on "int sd_read_sectors(IF_MV2(int drive,) unsigned long start, int count, void* buf)", if buf is a pointer? |
| 18:35:19 | casainho | and if I can do like this "*buf++ = sdcard_receive_byte();" to receive each byte and put on buffer? |
| 18:35:41 | | Join RichardDavis [0] (n=447eb8b9@gateway/web/cgi-irc/labb.contactor.se/x-b5ae1a5714b19946) |
| 18:37:47 | | Join Jaykay__ [0] (n=chatzill@p579E79EB.dip.t-dialin.net) |
| 18:42:06 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
| 18:42:12 | kugel | casainho: look at sd_transfer_sector in ata_sd_as3525.c, or sd_read_sector in ata-sd-pp.c |
| 18:42:14 | | Nick Jaykay__ is now known as Jaykay (n=chatzill@p579E79EB.dip.t-dialin.net) |
| 18:42:31 | casainho | kugel: I will, thanks ;-) |
| 18:44:23 | | Quit RichardDavis ("CGI:IRC (EOF)") |
| 18:44:55 | | Quit Makuseru (Read error: 104 (Connection reset by peer)) |
| 18:45:22 | | Join RichardDavis [0] (n=447eb8b9@gateway/web/cgi-irc/labb.contactor.se/x-7b1d6973be5fe65a) |
| 18:45:51 | casainho | I didn't used mutex before, can someone please xplain why the need? for example, on SD card drivers "mutex_lock(&sd_mtx);" ?? and this mutex is just used on drivers or will be used by ipper layers? |
| 18:45:57 | casainho | upper layers? |
| 18:46:27 | RichardDavis | RichardDavis : request write permission to TWiki to help contribute to documentation, FAQs, How-Tos |
| 18:46:30 | | Join m4rr0s [0] (n=mpreath@69.216.162.4) |
| 18:46:52 | | Quit m4rr0s (Client Quit) |
| 18:48:13 | | Quit RichardDavis (Client Quit) |
| 18:52:43 | kugel | casainho: http://www.rockbox.org/twiki/bin/view/Main/RockboxKernel#Mutex_functions |
| 18:54:47 | | Join mpreath [0] (n=mpreath@69.216.162.4) |
| 18:54:57 | mpreath | good morning |
| 18:55:22 | | Join markun [50] (n=markun@rockbox/developer/markun) |
| 18:55:24 | | Quit mpreath (Client Quit) |
| 18:56:02 | | Quit Jaykay_ (Read error: 110 (Connection timed out)) |
| 18:56:10 | | Join m4rr0s [0] (n=mpreath@69.216.162.4) |
| 18:59:22 | | Join webguest46 [0] (n=1815f5e1@gateway/web/cgi-irc/labb.contactor.se/x-e6aea0b306eb81ba) |
| 19:00 |
| 19:00:25 | | Quit robin0800 (Remote closed the connection) |
| 19:01:41 | | Quit LambdaCalculus37 ("Ka-chunka") |
| 19:03:19 | webguest46 | I noticed there wasn't a VID or PID for the Sansa e260 on the autodetect wiki.... so I thought I should report it..... |
| 19:04:12 | rasher | webguest46: Please do - also, is this an "old" (PortalPlayer based) e260, or a new (AMS based) e260? |
| 19:04:47 | webguest46 | not sure how I would know... |
| 19:05:08 | webguest46 | Device: Sansa e260 |
| 19:05:47 | webguest46 | VID: 0781 PID: 7420 |
| 19:06:05 | rasher | webguest46: check the firmware version in the original firmware |
| 19:07:50 | rasher | webguest46: Settings > Info here.. |
| 19:08:51 | webguest46 | (already did a manual install of rockbox) |
| 19:09:45 | rasher | Did you use mkamsboot or sansapatcher? |
| 19:09:55 | webguest46 | (I do recall having some "old V1" version that was updateable... not an un-updatable "v2" version) |
| 19:09:59 | webguest46 | sansapatcher |
| 19:10:11 | rasher | Alright, v1/PP then |
| 19:12:14 | | Quit m4rr0s ("Leaving") |
| 19:12:35 | | Join m4rr0s [0] (n=mpreath@69.216.162.4) |
| 19:12:50 | Llorean | Jaykay: Yes? |
| 19:13:04 | | Join gartral1 [0] (n=Gartral@75.33.92.18) |
| 19:13:27 | | Quit barrywardell () |
| 19:14:14 | Jaykay | llorean: i thought i could annoy you with a discussion about the closure of http://www.rockbox.org/tracker/9818.... |
| 19:14:32 | Llorean | It's not a bug. |
| 19:15:01 | Jaykay | i already read this somewhere. |
| 19:15:21 | | Join barrywardell [0] (n=barrywar@79.97.89.191) |
| 19:15:22 | Jaykay | so does displaying of the "wrong" information dely displaying of the right information? even a little bit? |
| 19:15:25 | | Quit webguest46 ("CGI:IRC (Ping timeout)") |
| 19:15:30 | Llorean | No. |
| 19:15:46 | Jaykay | sure? |
| 19:15:52 | Llorean | It defaults to other information (based on how the WPS designed) until the metadata is available. |
| 19:16:14 | Llorean | If it bothers you, just design a WPS that doesn't have a default condition when metadata is unavailable. |
| 19:16:15 | Jaykay | yeah but these information must also be loaded |
| 19:16:27 | Jaykay | but they are available.... |
| 19:16:38 | Llorean | The information isn't immediately available. |
| 19:16:45 | Llorean | Until the file is loaded off disk, it's not. |
| 19:16:54 | Llorean | While the *other* information is the path to the file, which is stored in the playalist |
| 19:17:01 | Llorean | So it's available before you've ever even accessed the file. |
| 19:17:18 | Jaykay | ok.... thanks |
| 19:19:13 | | Quit Lynx_ (Read error: 104 (Connection reset by peer)) |
| 19:21:14 | | Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) |
| 19:21:25 | | Quit m4rr0s (Remote closed the connection) |
| 19:22:42 | | Join Lynx_ [0] (n=till@xdsl-87-78-157-192.netcologne.de) |
| 19:27:38 | casainho | can someone please explain to me if "void* buf" on an argument of a function, means that "buf" is a pointer? why the void type? |
| 19:28:49 | bluebrother | casainho: a void* is simply a pointer without explicitly mentioning the type |
| 19:28:55 | kugel | because you can pass any pointer to it, without compiler warnings |
| 19:29:05 | kugel | and without explicit casting |
| 19:29:05 | bertrik | yes, buf is a pointer, it's probably void * because it can be easily cast |
| 19:29:17 | bluebrother | you need to typecast it to your desired target pointer type, then you can do any pointer arithmetics you want |
| 19:29:18 | | Quit gartral (Read error: 110 (Connection timed out)) |
| 19:29:49 | bluebrother | you usually use a void* if you don't want (or cannot) specify the type. |
| 19:30:07 | casainho | thanks :-) −− and so I am doing like this: unsigned short *addr_buf = &buf[]; |
| 19:30:31 | bluebrother | for example, malloc() returns a void*, as malloc has no idea what type the memory you're allocating should be. |
| 19:30:35 | casainho | and I will use *addr_buf to put data on buff |
| 19:30:40 | | Join kugel_ [0] (n=kugel@e179036194.adsl.alicedsl.de) |
| 19:30:47 | | Quit kugel (Nick collision from services.) |
| 19:30:48 | bluebrother | though malloc() might be a bad example because Rockbox doesn't have it ;-) |
| 19:30:49 | | Nick kugel_ is now known as kugel (n=kugel@e179036194.adsl.alicedsl.de) |
| 19:31:09 | casainho | bluebrother: hmmm... a simpler example for me, please ;-) |
| 19:31:18 | bluebrother | casainho: I don't get your context. |
| 19:31:46 | bluebrother | (of the unsigned short *addr_buf line) |
| 19:31:49 | casainho | *addr_buf++ = sdcard_receive_byte(); |
| 19:31:52 | bertrik | void * are also often used to supply context to a callback function, but that's probably not an easy example |
| 19:32:13 | kugel | casainho: ok, how about this example: in rockbox we have a quicksort function, which sorts any stuff you pass to it (using the function pointer passed to it) |
| 19:32:55 | kugel | because you want to quicksort any type of data, the data is void*, and casted to the real data in the function which quicksort uses |
| 19:34:11 | casainho | kugel: okok - I think I understand now. And english is not my main language, that makes difficult for me to understand the things ;-) |
| 19:34:17 | bluebrother | hmm. Not sure if that is an easy example as you need to provide quicksort a function which does the sorting. Though I can't think of a better one right now ... |
| 19:34:43 | kugel | yea, it's the only one that came into my mind (and which is in rockbox) |
| 19:34:48 | casainho | okok - I will see if my code works :-) |
| 19:35:39 | bluebrother | maybe memcpy is a bit simpler −− you can pass it any type of memory you want to copy, and give it the number of bytes. |
| 19:35:52 | casainho | can you look at this code and see if it will work? - http://pastebin.com/m73a7ff3a |
| 19:36:22 | bluebrother | but memcpy itself copies bytes, so it typecasts the data pointers to bytes and copies them. You need to take care yourself that the data itself aligns with the number of bytes. |
| 19:37:21 | * | kugel still thinks ata_sd_as3525.c is a good example of doing sd transfers |
| 19:37:23 | bertrik | casainho, I think you can simply use "buf" instead of "&buf[]" |
| 19:37:39 | kugel | read or write doesn't really matter for understanding the *buf stuff |
| 19:37:41 | bluebrother | casainho: not sure how exactly you code will work (I guess the compiler will throw a warning), but line 4 should be *addr_buf = (unsigned short*)buf; |
| 19:38:06 | casainho | kugel: sd card drivers for Sansa V2 uses SD bus while I am using SPI bus.... |
| 19:38:33 | bluebrother | well, isn't the real point simply the void* thingy? ;-) |
| 19:38:40 | kugel | so? the transfer is the same logic, just the hardware access functions/marcros are slightly different |
| 19:38:44 | kugel | or am I wrong here? |
| 19:39:26 | casainho | kugel: I don't really know, I know that they are different and I have example drivers outside Rockbox that are much more simple for me to understand, read |
| 19:40:17 | * | gevaerts thinks that if casting void * to char * counts as advanced stuff, you need to learn C first |
| 19:40:18 | casainho | kugel: but I am being looking to that ata_sd_as3525.c, as reference of what I must implement ;-) |
| 19:42:01 | bertrik | as far as I know, sd transfers are indeed slightly different from spi transfers, so ata_sd_as3525 might not be the best reference |
| 19:43:19 | bluebrother | Bagder: ping |
| 19:43:22 | kugel | casainho: look, I reduced the transfer function to make it clear how to handle the buf pointer http://pastie.org/369712 |
| 19:43:33 | Bagder | bluebrother: I'm here now a few mins at least! |
| 19:43:45 | bluebrother | oh! Looks I need to be quick ;-) |
| 19:43:59 | casainho | kugel: THANKS!!! I will run it now and debug ;-) |
| 19:44:01 | bluebrother | I want to finally get around and finish the rbutil-gets-releaseversions-from-web |
| 19:44:32 | bluebrother | should we introduce another -info file or put it in the daily one? I'm in favor of the latter, to have less downloads to handle |
| 19:44:58 | kugel | casainho: and transfer in this snippet is the number which is actually transfered in *1* while step |
| 19:46:05 | bertrik | that snippet doesn't make sense to me |
| 19:46:09 | bluebrother | casainho: not sure what exactly you want to do in that function, but you'll always write to the same byte at buf −− plus, as you don't typecast it the compiler doesn't know what type it is. |
| 19:46:11 | Bagder | bluebrother: I'm fine with putting it in the already existing daily file |
| 19:46:56 | Bagder | bluebrother: I think we should make it "[model] = [release]" to allow for different targets to have different releases |
| 19:47:07 | bluebrother | Bagder: then I'm asking for a new section in the daily release-info file like here: http://www.alice-dsl.net/dominik.riebeling/rockbox/release-info |
| 19:47:24 | Bagder | exactly what I have in mind |
| 19:47:28 | bluebrother | :) |
| 19:47:31 | kugel | btw, what happened to the beast? |
| 19:47:49 | kugel | I see the manual is downloadable, but it's been quite about releasing it recently |
| 19:47:49 | Bagder | bluebrother: I'll get a version going for you to try later tonight or so |
| 19:47:56 | Llorean | Bagder, bluebrother: Sounds good to me. It will be nice to be able to have point releases for just needed targets and have it handled well |
| 19:48:20 | Bagder | yeah, like the archoses 3.0.1 |
| 19:48:24 | bluebrother | Bagder: cool. I already did some local work on this so I expect it to be finished rather quickly |
| 19:48:27 | casainho | bluebrother: on that function, I need to send some commands to SD Card, to read multiple blocks of t512 bytes each. And I think I must write on "buf" every byte, on this case 512 bytes for each "count", right? |
| 19:49:02 | bluebrother | oh, and I decided that the Quick Start tab buttons should get disabled if there wasn't a release for the selected player (like M3), as the Quick Start now installs the release. |
| 19:49:10 | casainho | kugel: I think I understand - thanks |
| 19:49:16 | gevaerts | kugel: there's this OF update issue. I'm not sure if it's lear if that's a problem yet |
| 19:49:51 | bluebrother | we could make it use the most current build instead, but the user should get notified first. Plus, I'd like to get a new rbutil out soon to have this no sansa found issue finally gone |
| 19:49:59 | | Quit _lifeless (Remote closed the connection) |
| 19:50:25 | | Quit HBK- (Client Quit) |
| 19:50:48 | bluebrother | casainho: no. That void* is only a pointer to some memory −− if you want to transfer more than one byte to it you need to access that yourself. |
| 19:52:19 | casainho | bluebrother: I don't understand... can you please rectify the code here? http://pastebin.com/m73a7ff3a |
| 19:52:29 | kugel | Llorean: do you use the eq on the e200? |
| 19:53:17 | bluebrother | well, look at line 27. In that function buf (or to be exact, the local copy to that memory) (a) has a type and (b) gets incremented after each write. |
| 19:53:18 | *** | Saving seen data "./dancer.seen" |
| 19:53:33 | gevaerts | casainho: you call sdcard_receive_byte() and you store the result in a short? |
| 19:53:36 | bertrik | casainho, your code doesn't look so bad, I think you should use a byte pointer instead of a unsigned short pointer though |
| 19:53:45 | bluebrother | it's like *((unsigned short*)buf)+i |
| 19:53:48 | gevaerts | Also, what's the point of &buf; |
| 19:54:28 | Llorean | kugel: No, I don't use the EQ really |
| 19:54:33 | bluebrother | hmm, will &buf[] work at all? &buf[0] will work, not sure about the former. |
| 19:54:45 | casainho | I am doing now this: uint8_t *addr_buf = buf; |
| 19:55:00 | * | bluebrother hands casainho a (uint8_t*) |
| 19:55:08 | kugel | Llorean: I'm a bit disappointed of the keymap there |
| 19:55:21 | kugel | just slightly, but stil |
| 19:55:24 | Llorean | The EQ is a hard screen to keymap, I think. |
| 19:55:29 | Llorean | It's not "great" on any target, really |
| 19:55:36 | bertrik | casainho, that looks about right |
| 19:55:52 | casainho | well, I got the data... does anyone knows how can I cheeck? the is some byte where I can see the partition? |
| 19:56:31 | bertrik | IIRC, the last few bytes of sector 0 are often 0x55AA or 0xAA55 |
| 19:56:36 | bluebrother | read sector 0 and check for 0x55 0xaa at the last two bytes (could be 0xaa 0x55) |
| 19:59:50 | kugel | Llorean: hm, btu on the e200 you toggle through the modes with select, and finish with right |
| 19:59:56 | kugel | swapping this would be better |
| 20:00 |
| 20:01:07 | Llorean | What do you mean by "finish"? |
| 20:01:21 | kugel | leave the eq screen |
| 20:01:52 | Llorean | That is a little strange |
| 20:02:36 | gartral1 | i think finish was used for "done" there >.> |
| 20:03:12 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 20:03:24 | | Join linoge [0] (n=carlos@190-76-93-121.dyn.movilnet.com.ve) |
| 20:03:49 | casainho | :-) −− here the image of debug session: http://www.flickr.com/photos/43558168@N00/3223353030/sizes/o/ |
| 20:03:54 | casainho | yes, I got it ;-) |
| 20:04:09 | kugel | Llorean: I think pressing select seems more logical if you think "I'm done now", and right is more logical to toggle though the modes (as they are in the horizontal "line" anyway) |
| 20:04:31 | linoge | hi, i wanted to know if it's possible to port rockbox to ipod shuffle and if there's any project doing it ? |
| 20:04:38 | Llorean | kugel: Is it possible to make right *and* left toggle through them? |
| 20:04:54 | Llorean | Otherwise it makes more sense for "Right" to be Confirm and "Left" to be cancel, as this actually works for other settings too. |
| 20:05:40 | kugel | Llorean: not after my patch |
| 20:06:04 | bertrik | casainho, \o/ |
| 20:06:11 | kugel | it's only 3 modes, so having only 1 direction doesn't really hurt imo |
| 20:06:44 | kugel | I find it more important that left is cancelling (and leaving) constently in rockbox |
| 20:07:03 | kugel | (although it seems you can't do cancel in the eq screen) |
| 20:07:30 | Llorean | If left cancels, right should confirm then. |
| 20:07:55 | kugel | and what is select? |
| 20:08:08 | kugel | either select or right is toggeling through the modes |
| 20:08:17 | casainho | bertrik: now, do you think I can load the rockbox firmwae and run it? |
| 20:08:57 | kugel | right is confirming and select is toggling through modes currently |
| 20:09:33 | Llorean | I don't mind select toggling through modes. |
| 20:09:35 | T0paz | has anyone got any experience of remote ARM debugging (via JTAG or serial?) |
| 20:09:41 | bertrik | casainho, yes I think so, at least it's a big step in the right direction |
| 20:09:47 | Llorean | Since you don't get to pick a direction, just cycle, the center button for it isn't bad, I think |
| 20:09:54 | Llorean | I admit it's not ideal, though |
| 20:10:18 | casainho | bertrik: so now I need to test FAT driver, no? |
| 20:10:56 | kugel | Llorean: on the e200, select and right do mostly the same. And you're using select for confirming most of the time, so I'd rather have those swapped |
| 20:11:20 | kugel | but I don't really use the eq screen, so I might leave this open to someone who uses it often and finds it more annyoing |
| 20:12:17 | bertrik | casainho, yes indeed, I don't expect a lot of problems with that |
| 20:13:00 | casainho | bertrik: okok :-) - I hope to be able to do that in next hours |
| 20:13:23 | Unhelpful | kugel: pong? |
| 20:13:42 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 20:13:57 | kugel | Unhelpful: I just wanted to ask if pf is now building on the clip |
| 20:13:59 | kugel | is it? |
| 20:14:19 | Unhelpful | and m:robe100 :) |
| 20:15:46 | Unhelpful | it's a bit broken, visually, on the clip |
| 20:16:38 | kugel | you judge by the sim, right? |
| 20:16:54 | kugel | I'm gonna look how it is on a real clip, and tell you, ok? :) |
| 20:17:44 | kugel | Llorean: thanks for the badge :) |
| 20:17:48 | Unhelpful | i don't have a real clip :/ |
| 20:18:41 | | Quit Seed ("cu, Andre") |
| 20:19:40 | | Quit Timmmy (Remote closed the connection) |
| 20:21:47 | | Part linoge |
| 20:22:52 | kugel | Llorean: well, forget the talk, the manual lies about the keymapping in the eq screen |
| 20:23:11 | kugel | right now, select and right toggle, and power and left are leaving the eq |
| 20:24:33 | | Part gartral1 |
| 20:25:55 | kugel | rasher: ping |
| 20:27:24 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 20:27:36 | Llorean | kugel: That sounds fairly reasonable. |
| 20:28:56 | kugel | however, my patch will stop power from leaving the eq screen (only stop playback) |
| 20:29:24 | Llorean | Ah |
| 20:29:40 | Llorean | Does "play" to resume currently work in the EQ screen? |
| 20:30:05 | casainho | I am getting this error: /home/cas/Documentos/rockbox_player/rockbox/firmware/../firmware/target/arm/at91sam/rockboxplayerlittle/ata-sd-target.h:15: error: syntax error before ‘bool’ |
| 20:30:30 | casainho | and on line 15 of that file I have: int sd_transfer_sectors(IF_MV2(int drive,) unsigned long start, int count, void* buf, bool write); |
| 20:30:44 | casainho | what can be wrong? |
| 20:32:29 | bertrik | maybe a missing } or ), or maybe a macro is doing something weird |
| 20:33:38 | bertrik | do you know if IF_MV2 is defined? |
| 20:34:12 | casainho | yes, I think, here: #include "mv.h" /* for HAVE_MULTIVOLUME or not */ |
| 20:34:30 | kugel | Llorean: no, play toggles through the bands upwards |
| 20:34:53 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 20:35:30 | Llorean | kugel: I'm not *sure* a stop function is necessary in that screen then. But I'm not sure it's unnecessary eitherj ust one of those gray areas. |
| 20:35:47 | Llorean | It's not a list, so it doesn't work the same for overall controls |
| 20:35:57 | kugel | well, it's the side effect of removing ACTION_STD_CANCEL from the power button |
| 20:36:18 | kugel | which is causing the whole go-up-one-dir in the filebrowser thing |
| 20:36:23 | Llorean | Yeah |
| 20:36:54 | Llorean | Probably best just to go with the simplest solution then, and let it still be stop. |
| 20:36:57 | kugel | maybe the eq screen could just have 1 direction for toggling the bands too, so that play is free for resuming |
| 20:36:59 | Llorean | But then, is there a cancel now? |
| 20:37:17 | kugel | left is leaving (and confirming), there's no cancel for the rec screen |
| 20:37:31 | kugel | cancel as in discard changes I mean |
| 20:37:38 | Llorean | The rec screen? |
| 20:37:46 | kugel | eq*, sorry |
| 20:38:14 | Llorean | Maybe select should leave, and left/right should bidirectionally move through the choices. |
| 20:38:16 | bertrik | casainho, in that case, I don't know |
| 20:38:18 | Llorean | So it's all "directional buttons" |
| 20:38:31 | Llorean | I'm sure if right changes, people are going to try to press left to change too |
| 20:38:46 | Unhelpful | pixelma: really, PF consists of a horizontal list from which you scroll/select, and a vertical list... if we have a button context for each of those, it would seem to me that changing contexts would be a better solution than creating a custom one |
| 20:39:23 | kugel | well, they won't do it often, and if they press left accidently they wouldn't lose anything (as discarding isn't possible (or just not implemented)) |
| 20:39:37 | casainho | bertrik: okok.... |
| 20:39:38 | kugel | I'm more tempted to make right leave too actually |
| 20:39:49 | Llorean | kugel: Why? |
| 20:40:14 | Llorean | That basically makes the screen less intuitive, since you have two exit buttons that seem like they'd be directional controls, and both confirm where on other screens they're exit buttons where one cancels. |
| 20:40:20 | kugel | so that's consistent with the left button and the rest of the UI |
| 20:40:30 | Unhelpful | if we make select *do* something in track list, i guess that will need vertical scroll, select, and an escape button |
| 20:40:38 | Llorean | It makes its inconsistency with the rest of the UI less obvious, and thus less intuitive. |
| 20:40:51 | kugel | yea, that's why I initially wanted to have the right button toggle through the modes, and making select leaving only |
| 20:40:53 | Llorean | If it's inconsistent with the UI anyway, it should have its own inconsistency |
| 20:41:07 | Llorean | Rather than trying to hide its inconsistency in a way that people will think "Left isn't cancelling, what's wrong" is a bug |
| 20:41:48 | kugel | but anyway, this is all not really related to my patch, I might change this in a seperate one |
| 20:47:09 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 20:50:21 | | Join kugel_ [0] (n=kugel@e179038023.adsl.alicedsl.de) |
| 20:50:37 | | Quit kugel (Nick collision from services.) |
| 20:50:39 | | Nick kugel_ is now known as kugel (n=kugel@e179038023.adsl.alicedsl.de) |
| 20:50:53 | | Quit krazykit (Read error: 60 (Operation timed out)) |
| 20:56:21 | | Join gregzx [0] (n=chatzill@drx15.neoplus.adsl.tpnet.pl) |
| 21:00 |
| 21:00:28 | | Quit merbanan (Remote closed the connection) |
| 21:04:56 | casainho | I am getting this error: rockbox/firmware/export/hotswap.h:44:6: warning: "CONFIG_STORAGE" is not defined |
| 21:05:10 | casainho | but I get it defined on my config file.... |
| 21:07:27 | kugel | then it's not included properly |
| 21:07:51 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 21:08:34 | | Quit barrywardell () |
| 21:14:29 | kugel | rasher: ping |
| 21:14:56 | | Join _lifeless [0] (n=lifeless@94.50.176.150) |
| 21:15:05 | kugel | rasher: I need to fix some translations of buttons (for http://www.rockbox.org/tracker/task/9662) |
| 21:15:41 | kugel | those translations are mostly IDs which have a translation for each target (e.g. e200*:) |
| 21:15:58 | kugel | how do I invalidate the translations in other langs properly? |
| 21:22:38 | | Join MethoS [0] (n=lem@host-091-096-215-147.ewe-ip-backbone.de) |
| 21:33:53 | | Join webguest79 [0] (n=4433f8fe@gateway/web/cgi-irc/labb.contactor.se/x-382b45790c92eaf1) |
| 21:35:54 | webguest79 | I have an old version of rockbox on my iriver h120 and want to install the new 3.0 with the auto install. Do I transfer the file to my player and launch from there or do I launch from my computer with the player attached? |
| 21:36:39 | Unhelpful | why not 3.1 or a recent snapshot build? |
| 21:36:59 | webguest79 | which ever is being offered |
| 21:37:42 | webguest79 | i had downloaded 3.0 but didn't get installed |
| 21:38:40 | | Quit Seed ("cu, Andre") |
| 21:38:50 | | Join gnomonic [0] (n=niels@0x573d8f72.bynqu2.dynamic.dsl.tele.dk) |
| 21:39:11 | | Join QuickStart [0] (n=QUICKSTA@pool-72-88-190-6.nwrknj.east.verizon.net) |
| 21:39:26 | webguest79 | Unhelpfull> do I transfer the build to myplayer and launch from there? |
| 21:40:04 | Unhelpful | if you mean the zip file, no, your player won't know what to do with a zip file. have you tried using the rockbox utility? |
| 21:40:58 | webguest79 | I think that is what I have downloaded, the utility for an auto install |
| 21:41:39 | Unhelpful | then you need to run that on your computer |
| 21:42:05 | webguest79 | OK and it will find my connected player, correct? |
| 21:43:06 | Unhelpful | it should. i only have sansa e200 and gigabeat, no iriver, but the utility works fine for my sansa. |
| 21:43:38 | webguest79 | Good you may need to change you name if this works |
| 21:44:50 | webguest79 | thks |
| 21:45:55 | | Quit webguest79 ("CGI:IRC") |
| 21:48:48 | * | bluebrother wonders why people don't just simply _try_ first ... |
| 21:50:54 | | Join tchan1 [0] (n=tchan@c-67-173-9-133.hsd1.il.comcast.net) |
| 21:53:20 | *** | Saving seen data "./dancer.seen" |
| 21:55:23 | ze | bluebrother: #1 cause of poor computer litteracy, simply being afraid to try an unknown |
| 21:56:03 | | Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 21:56:28 | bluebrother | we shouldn't make installation safe then. |
| 21:56:49 | ze | heh |
| 21:56:54 | | Quit tchan (Read error: 110 (Connection timed out)) |
| 21:59:23 | T0paz | have any of the existing ports been done with no documentation? |
| 21:59:28 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 22:00 |
| 22:00:04 | Llorean | T0paz: What do you mean? |
| 22:00:23 | T0paz | well, beyond the processor instruction set |
| 22:00:44 | T0paz | REing all the peripheral configuration from the firmware |
| 22:01:35 | T0paz | i see that with most players you can find reasonable documentation on memory maps and things |
| 22:01:46 | | Join miepchen^schlaf [0] (n=miepel@p579EC609.dip.t-dialin.net) |
| 22:01:57 | bluebrother | T0paz: you can ask the ipl guys about their initial ports ... and we have the sansa |
| 22:06:58 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 22:14:00 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) |
| 22:17:00 | Unhelpful | kugel: did you try pictureflow on clip yet? the problems as i see them are 1) title in splash straddles the split between "screen" and "status" areas, and 2) tall covers can, as well |
| 22:17:24 | Unhelpful | i think the fix is to subtract/offset the status bar height for splash, and for cover drawing |
| 22:18:07 | kugel | Unhelpful: no, I'm on windows atm, trying to set up a vm |
| 22:19:19 | Unhelpful | i'm also thinking we should keep the current reflection height, but make the cover itself larger... perhaps as big as the largest square that can fit above the reflection, but more likely somewhere from 2/3 to 3/4 of that |
| 22:20:12 | | Join xSlack [0] (n=brett@173-17-70-78.client.mchsi.com) |
| 22:20:40 | | Quit Acky (Connection timed out) |
| 22:26:31 | | Quit kugel (Remote closed the connection) |
| 22:27:16 | | Nick BigBambi is now known as Technology (n=Alex@rockbox/staff/BigBambi) |
| 22:27:42 | | Nick Technology is now known as BigBambi (n=Alex@rockbox/staff/BigBambi) |
| 22:27:52 | | Join kugel [0] (n=kugel@e179038023.adsl.alicedsl.de) |
| 22:31:34 | | Quit pyro_maniac ("Leaving.") |
| 22:33:09 | | Quit gevaerts (Nick collision from services.) |
| 22:33:21 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 22:34:46 | | Join krazykit [0] (n=kkit@adsl-76-252-49-213.dsl.ipltin.sbcglobal.net) |
| 22:34:56 | casainho | I am getting the error: "No partition found", after ret = disk_mount_all(); |
| 22:35:23 | | Quit toffe82 (Read error: 145 (Connection timed out)) |
| 22:35:34 | bluebrother | casainho: do you have a partition table on the disk at all? |
| 22:35:36 | casainho | is there a good way to found the problem, knowing that I am using a JTAG debugger and can see values of the variables e follow the flow of the program? |
| 22:36:10 | casainho | bluebrother: yes, I used "gparted" to put a FAT16 on it, and before were with FAT32 and I got the same problem... |
| 22:36:34 | bertrik | casainho, can you step inside the mount function and see if/where it fails? |
| 22:36:39 | bluebrother | well, IIRC you need to enable FAT16 support explicitly in Rockbox |
| 22:37:03 | casainho | so, I should use for first FAT32? |
| 22:37:12 | bluebrother | dumping the partition table might be interesting though. Just to make sure the table is ok. |
| 22:37:19 | * | Unhelpful wonders if we'll have jtag debug on any commercial targets soon... |
| 22:37:19 | bertrik | and does SD vs. SDHC detection work correctly? |
| 22:37:21 | bluebrother | I assume the partition is properly formatted? |
| 22:38:07 | casainho | bertrik: yes, I am using 8GB sd card and I could read correctly the first sector: http://www.flickr.com/photos/43558168@N00/3223353030/sizes/o/ |
| 22:38:30 | casainho | bluebrother: is just to use gparted and ofrmat to FAT32? |
| 22:40:01 | | Quit xSlack (Read error: 110 (Connection timed out)) |
| 22:40:37 | | Join xSlack [0] (n=brett@173-17-70-78.client.mchsi.com) |
| 22:40:56 | casainho | bertrik: it just returns with mounted = 0 |
| 22:41:30 | casainho | Unhelpful: well, this can be a comercial player with JTAG... |
| 22:41:34 | casainho | if we want ;-) |
| 22:42:06 | Unhelpful | if we, and some large-enough manufacturer, want :/ |
| 22:42:36 | casainho | we don't need larg manufacturers... |
| 22:43:00 | Unhelpful | to make it affordable, and available to non-hobbyists, yes, we do. |
| 22:43:22 | casainho | no, I think |
| 22:43:33 | Unhelpful | 3D printers aren't *that* ubiquitous, yet, and they can't manufacture ICs :) |
| 22:43:35 | T0paz | is the JTAG interface usually accessible on the player PCB? |
| 22:43:38 | casainho | 200 euros would be affordable for me |
| 22:43:54 | | Join Strife89 [0] (n=michael@204.116.244.200) |
| 22:44:11 | casainho | T0paz: it can be... |
| 22:44:22 | T0paz | i've programmed CPLDs with a parallel port |
| 22:44:31 | T0paz | total cost of hardware of about $2 |
| 22:44:40 | Unhelpful | casainho: i paid a bit more than half that for a 60GB beast, though. |
| 22:44:40 | Llorean | 200 euro is a ridiculous amount to pay for a flash-based MP3 player, I think |
| 22:45:00 | Bagder | and probably a large ugly one too :-/ |
| 22:45:03 | Unhelpful | so it might be something that people can afford, but it's far, far more than i'd be willing to pay. |
| 22:45:06 | casainho | Unhelpful: look here, for $200: http://www.sparkfun.com/commerce/product_info.php?products_id=8603 |
| 22:45:40 | Unhelpful | ...if it sells for 200USD or 200euro, europe is getting cheated a bit :/ |
| 22:46:07 | * | Llorean can buy a new 8gb for probably ~50 euro |
| 22:46:23 | Llorean | e200v2 that is |
| 22:46:43 | Unhelpful | casainho: ok, maybe affordable... perhaps what i should have said was "competitive" |
| 22:46:47 | Unhelpful | and that, it's clearly not. |
| 22:46:48 | Llorean | Which is more or less equivalent to the "open hardware" player |
| 22:46:51 | casainho | Llorean: eheh - but e200v2 is not documented and controlled by us |
| 22:47:19 | Llorean | casainho: As a user, "documented and controlled by us" matters a lot less than "works and costs $150 less" |
| 22:47:28 | bluebrother | if some major company comes in, how much control will remain for "us" at all? |
| 22:47:46 | Llorean | As Unhelpful said, your project will mainly be of interest to hobbyists, not users. |
| 22:48:12 | casainho | Llorean: well, rockbox is not for users then |
| 22:48:30 | casainho | because rockbox don't come in any commercial player |
| 22:48:33 | Llorean | Rockbox doesn't cost money. |
| 22:48:36 | Unhelpful | rockbox *player* may not be |
| 22:48:37 | bluebrother | I would consider going less in a portable direction with such a project. Less space issues, and most likely cheaper hardware |
| 22:48:57 | Unhelpful | rockbox itself is definitely for users, i was a user first and dev second until a month or so ago :P |
| 22:49:07 | Llorean | bluebrother: Yes, I'd pay some for a multi-codec larger-storage (maybe 2.5" drive bay) player with optical out for use with my home stereo, for example |
| 22:49:15 | Llorean | Or even 3.5" (or USB host) |
| 22:49:19 | bluebrother | so linux isn't for users because it doesn't come with commercial hardware (like a PC)? |
| 22:49:23 | Llorean | Something I could put all my CD-quality music on |
| 22:49:46 | Unhelpful | even a good analog lineout |
| 22:49:50 | casainho | bluebrother: no, you can buy computers with linux, as netbooks, for example |
| 22:50:14 | bluebrother | casainho: well, that's just recently. Were you able buying linux pcs like 5 years ago? |
| 22:50:22 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 22:50:25 | Unhelpful | 24 bits/sample out would be nice, for filtering without aliasing, too... i think we already have 24bps hardware on some targets? |
| 22:50:40 | Llorean | casainho: We have a user-usable installer though. |
| 22:50:42 | casainho | bluebrother: don't know... but rockbox is on the same |
| 22:50:50 | Llorean | casainho: Or do you say "OpenOffice isn't for users because it doesn't come on PCs" too? |
| 22:51:00 | bluebrother | casainho: I disagree. Completely. :) |
| 22:51:06 | Llorean | Rockbox is, in its essence, an application. |
| 22:51:19 | casainho | Llorean: yes, but most people will never hear about rockbox... specially on cheap players |
| 22:51:26 | * | bluebrother would rather call it a firmware, but well ... |
| 22:51:35 | Llorean | casainho: we have tens of thousands of users. Maybe most people won't, but a lot of people do |
| 22:51:53 | Llorean | bluebrother: It's definitely a firmware, but that's more "stuff that's there that's necessary to allow the application to work" |
| 22:51:53 | casainho | Llorean: netbooks comes with linux and openoffice |
| 22:51:57 | bluebrother | but why is that? Because we don't (can't) support every cheap chinese player? |
| 22:52:12 | Llorean | casainho: So to be "for users" people *have* to pay for it? |
| 22:52:59 | casainho | no, to be users the rockbox would come installed on players... untill them I thin most people will never hear or use it |
| 22:53:12 | Llorean | How will people hear of your player? |
| 22:53:37 | casainho | if is good and available |
| 22:53:42 | Llorean | 'available' where? |
| 22:53:48 | casainho | on shops |
| 22:53:52 | Unhelpful | indeed, your player will have far fewer users than rockbox does on any one supported target, until it's manufactured at a competitive price by somebody who will pay to advertise it |
| 22:54:01 | bluebrother | "available" in which amount? In local cheap electronic stores? |
| 22:54:15 | Llorean | People won't buy it if it's $150 more than the Sansa right next to it. |
| 22:54:18 | Llorean | Unless they *already* know about Rockbox. |
| 22:54:19 | casainho | Unhelpful: I hope that happens |
| 22:54:24 | Llorean | In which case, they'll buy the Sansa and put Rockbox on it |
| 22:54:28 | Llorean | Unless they're a hobbyist. |
| 22:54:34 | | Quit yhuang ("Leaving") |
| 22:54:49 | casainho | Llorean: ehe - but sansa is not always available |
| 22:54:54 | casainho | for example V2 |
| 22:55:08 | bluebrother | well, people might buy it if it offers something a sansa can't −− large storage, good ADC and fits into the stereo ;-) |
| 22:55:15 | casainho | Rockbox not working on since since... dont't know how many months |
| 22:55:34 | Llorean | casainho: Yes, but the V2 probably will be available. And they have to read the website to find out why Rockbox is better than the normal firmware, at which point they can order a *much* cheaper player |
| 22:55:54 | Llorean | You're better off offering better *hardware* than trying to use Rockbox to sell expensive equal hardware |
| 22:56:07 | Llorean | Rockbox is only "value added" when you can't use it to add that value to something else that costs less real money |
| 22:56:09 | casainho | Llorean: but if the player is not available on market, unless used :-( |
| 22:56:32 | Llorean | Or refurbished, which the majority of people will find acceptable |
| 22:56:48 | bluebrother | well, you basically have (a) people that know Rockbox and buy a supported hardware, (b) people that only want to play around (like only want to install it for playing doom) −− not of interest to us, (c) people who have a supported player and look for an alternative. |
| 22:57:00 | bluebrother | which of those is likely to buy your hardware? |
| 22:57:15 | casainho | well, I just know that there is no project like this one outside, and I think it can be good for some people |
| 22:57:36 | | Quit _lifeless (Remote closed the connection) |
| 22:58:00 | bluebrother | true. But don't hang your hopes too high −− I'm pretty sure the average user won't be interested in it at all. |
| 22:58:03 | casainho | a and c |
| 22:58:04 | | Join _lifeless [0] (n=lifeless@94.50.176.150) |
| 22:58:25 | bluebrother | casainho: no, (c) not −− they already own a supported hardware. |
| 22:58:27 | casainho | bluebrother: okok |
| 22:58:56 | casainho | okok |
| 23:00 |
| 23:00:52 | | Quit amiconn (Read error: 60 (Operation timed out)) |
| 23:01:44 | casainho | but thinking on average users, rockbox hackers can't help them a lot when thinking on some Ipods and Zune, for example |
| 23:01:45 | | Quit _lifeless (Remote closed the connection) |
| 23:02:09 | | Join _lifeless [0] (n=lifeless@94.50.176.150) |
| 23:02:30 | Unhelpful | casainho: and your player can? help them get rockbox on their zune? or ipod classic? |
| 23:03:26 | casainho | no |
| 23:03:52 | Unhelpful | then what exactly are you trying to say with that statement? |
| 23:03:54 | BigBambi | casainho: Average users are not going to pay over the top for a big player, just because it is open. They just don't care |
| 23:04:10 | casainho | BigBambi: yeah, right. |
| 23:04:38 | casainho | Unhelpful: I wanted to say that on that cases, is bad to not be able to control the hardware |
| 23:05:34 | Unhelpful | a majority of users don't care about that, though. people who fuss over niche features, or audio quality, or the rights to control their device, are a *very* small market. |
| 23:06:25 | | Quit petur (Remote closed the connection) |
| 23:07:22 | Llorean | Unhelpful: Actually, audio quality is a pretty decently sized market. |
| 23:07:28 | Llorean | But you don't actually have to deliver *good* audio quality. |
| 23:07:39 | Llorean | You just have to avoid audible noise and give them bass tone controls |
| 23:07:52 | Llorean | Oh, and *say* you have some sort of copyrighted audio enhancement. |
| 23:08:13 | bluebrother | copyrighted audio enhancements = parametric eq? ;-) |
| 23:08:35 | bertrik | parametric eq *technology* :P |
| 23:09:14 | bluebrother | qt (quiet technology) technology :P |
| 23:09:58 | Unhelpful | needs more BiCaps, BassEnhance Technology |
| 23:10:33 | Llorean | We should name one of our features that. |
| 23:10:44 | Llorean | Just pick an EQ curve people will like, and add an On/Off "SoundEnhance Technology" |
| 23:11:06 | Llorean | By "people will like" I mean "lots of bass" mostly |
| 23:11:20 | bluebrother | RockEnhance Technology |
| 23:12:00 | Llorean | Yes! Perfect. |
| 23:12:22 | Unhelpful | bluebrother: that sounds like something that would be plugged in an email with a subject like "g3t a bigger PEN15 2day! l@@K!" |
| 23:12:56 | kugel | Llorean, bluebrother: we already have Crossfeed ;) |
| 23:13:15 | | Join toffe82 [0] (n=chatzill@adsl-75-12-168-240.dsl.frs2ca.sbcglobal.net) |
| 23:13:26 | bluebrother | R0c3 3nHA|/|c3 Technology |
| 23:13:47 | Llorean | kugel: Crossfeed is more like trying to reproduce real-world effects though. |
| 23:13:51 | bluebrother | hmm, just call it S.P.A.M :) |
| 23:13:53 | Llorean | Kinda like "concert hall" DSP transforms |
| 23:14:16 | kugel | I think it qualifies as RockEnhance Technology :) |
| 23:14:44 | Unhelpful | ...could we consider *having* a generic impulse response DSP filter? ;) |
| 23:15:34 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
| 23:15:50 | | Quit pixelma (Read error: 110 (Connection timed out)) |
| 23:16:05 | | Join webguest [0] (n=46ead929@gateway/web/cgi-irc/labb.contactor.se/x-96933073822b135b) |
| 23:16:14 | Unhelpful | and i mean for rather largeish filter sizes, and possibly requiring playback stop to steal audio buffer when turning it on or changing the filter |
| 23:16:18 | | Join pixelma [0] (n=pixelma@rockbox/staff/pixelma) |
| 23:16:39 | | Nick webguest is now known as helpme (n=46ead929@gateway/web/cgi-irc/labb.contactor.se/x-96933073822b135b) |
| 23:17:00 | Llorean | Unhelpful: I don't even know what the phrase "impulse response" means in reference to DSP filters. I can make an educated guess, but it seems safer to just ask. |
| 23:17:10 | * | helpme wants to know what this is about just to be sure |
| 23:17:30 | Zoxc | how much does rockbox utilize DSP and hardware decoders? :) |
| 23:17:52 | | Quit helpme (Client Quit) |
| 23:18:08 | Unhelpful | Llorean: you can capture the response of a listening environment to a predetermined signal, and use that to generate a filter for reproducing the "sound" of that space. |
| 23:18:18 | Llorean | Zoxc: There usually aren't hardware decoders except on players where they're the only way to decode because the core CPU is too slow (Archoses) |
| 23:18:25 | Unhelpful | it's a non-fixed-function version of "concert hall sound" filter, basically. |
| 23:18:30 | T0paz | it would make more sense to implement a IIR fake reverb |
| 23:18:33 | Llorean | Unhelpful: Okay, that's what I was guessing. |
| 23:18:59 | T0paz | (in terms of memory usage, anyway) |
| 23:19:03 | | Quit MethoS (Remote closed the connection) |
| 23:19:14 | soap | Personally I think DRC is the audio changing feature most needed... |
| 23:19:22 | Unhelpful | DRC? |
| 23:19:26 | Unhelpful | nevermind. |
| 23:19:27 | bertrik | Llorean, the impulse response of a filter is basically a unique fingerprint of a filter and it's quite easy to use it to transform a signal with it (although computationally expensive) |
| 23:19:31 | T0paz | digital room correction |
| 23:19:37 | T0paz | have you ever got DRC to work? |
| 23:19:39 | Zoxc | it wouldn't work too good for earphones? :/ |
| 23:19:45 | Unhelpful | dynamic range compression, i got, actually. |
| 23:19:59 | | Quit bluebrother (Nick collision from services.) |
| 23:20:04 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 23:20:05 | T0paz | that'd be more useful ;) |
| 23:20:07 | Unhelpful | bertrik: you need four channels to simulate stereo room + stereo listener |
| 23:20:41 | casainho | can someone please look and say if there is any problem with that partition info? : http://www.flickr.com/photos/43558168@N00/3222964531/sizes/o/ |
| 23:20:54 | Llorean | Dynamic Range Compression would be kinda nice. |
| 23:21:14 | T0paz | i can't believe car radios still don't have it |
| 23:21:38 | Unhelpful | T0paz: some have "adjust volume based on road/cabin noise, or velocity" |
| 23:21:51 | T0paz | i guess that helps |
| 23:22:05 | bertrik | Unhelpful, maybe we could sample ambient noise and adjust dynamic range accordingly |
| 23:22:12 | T0paz | but listening to uncompressed classical music is usually a waste of time |
| 23:22:21 | soap | Yes, Unhelpful, sorry for vague acronyms. Dynamic range compression would be mojo helpful. |
| 23:22:29 | Unhelpful | bertrik: the dynamic range, rather than simply the volume? now *that* is an interesting idea! |
| 23:22:48 | Unhelpful | and we can abbrev it as dDRC :D |
| 23:22:53 | soap | GM's auto-volume function simply increases volume with speed. Don't know how Ford's works. |
| 23:23:09 | Unhelpful | since it's dynamic Dynamic Range Control, after all ;) |
| 23:23:32 | Unhelpful | soap: our buick is by speed. the effect is more distracting than helpful. |
| 23:30:00 | rasher | kugel: If you need to change the button combinations, I'd say simply change them in english.lang |
| 23:30:08 | | Nick tchan1 is now known as tchan (n=tchan@c-67-173-9-133.hsd1.il.comcast.net) |
| 23:30:57 | Unhelpful | would apps/plugins/lib/gcc-support.c be the right place to add the mem function wrappers? it seems appropriate, they're basically to "support" gcc's use of mem* functions for things like struct assignment. |
| 23:31:33 | rasher | soap: stopped a client - running 2 now. |
| 23:31:57 | soap | ty |
| 23:36:40 | | Join rphillips [0] (n=rphillip@unaffiliated/rphillips) |
| 23:37:26 | | Quit agaffney (Read error: 104 (Connection reset by peer)) |
| 23:37:44 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
| 23:38:25 | kugel | rasher: Yes, but what about the other langs? |
| 23:38:39 | kugel | will they be wrong, or invalidate automatically? |
| 23:38:52 | rasher | kugel: They'll get told to update when the source string changes |
| 23:39:05 | rasher | (which happens when english.lang is changed) |
| 23:39:07 | kugel | ah ok, so no worries. thanks :) |
| 23:41:39 | | Quit bluebrother ("leaving") |
| 23:41:56 | amiconn | jhMikeS: Using SWI wouldn't need anything in the plugin/codec api. Just an appropriate UIE() code path, and a little stub in the core, pluginlib, and codeclib each |
| 23:42:54 | amiconn | That stub wouldn't return 0 as before, but trigger the software interrupt instead |
| 23:43:11 | | Join lowlight [0] (n=ad58bb86@gateway/web/cgi-irc/labb.contactor.se/x-dd10f7e6a1fe64a0) |
| 23:43:59 | casainho | I am getting this error: "fat_mount() - Couldn't read BPB (error code 1)" −− what this means? |
| 23:45:05 | | Quit lowlight (Client Quit) |
| 23:45:28 | | Join low_light [0] (n=ad58bb86@gateway/web/cgi-irc/labb.contactor.se/x-48ec641dd4020a5a) |
| 23:46:56 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 23:51:09 | low_light | Bagder: can you add the Philips HDD1630 to the build table (normal, boot, & sim) |
| 23:51:22 | Bagder | I'll be happy to! |
| 23:51:53 | | Quit gnomonic (Read error: 60 (Operation timed out)) |
| 23:53:23 | *** | Saving seen data "./dancer.seen" |
| 23:54:32 | low_light | Anyone want to volunteer to make a hdd1630 manual? |
| 23:56:39 | low_light | It could probable start as a copy of the H10 (5GB) since it's largely the same. |
| 23:58:13 | low_light | I think working radio and a manual are the last things needed to make this a supported port. |
icon identifies that the person is a core developer (has commit access).