00:03:22 | | Join Massa [0] (n=Massa1@p549E857C.dip0.t-ipconnect.de) |
00:04:47 | | Join JazzBone [0] (n=JB@cc829402-a.groni1.gr.home.nl) |
00:05:11 | Massa | Hi everybody! |
00:06:41 | idanm | good night everyone |
00:09:40 | Massa | does someone know what happened to forums.rockbox.org? |
00:10:23 | idanm | they are dead for now... |
00:10:34 | | Quit idanm () |
00:10:44 | Massa | what happened? |
00:10:46 | | Quit JazzBone ("Leaving") |
00:11:04 | Massa | (and when will i be available again? |
00:11:12 | Moos | the administarator isn't here |
00:11:25 | Moos | you need to wait from MisticJeff |
00:11:45 | Moos | we can't tell when the site will relive again |
00:11:47 | | Join einhirn [0] (i=Miranda@szgt-d9b8e8f8.pool.mediaWays.net) |
00:11:50 | | Join ts-x [0] (n=43823b46@labb.contactor.se) |
00:12:07 | Massa | was it discussed already this day? |
00:12:21 | Bagder | Massa: MisticJeff is not here very often |
00:12:23 | | Quit mirak (Remote closed the connection) |
00:12:28 | Bagder | so mentioning it here doesn't do much good |
00:12:39 | Moos | absolutly |
00:12:41 | Massa | BTW, is MisticJeff also the admin of forums.rockbox.org? |
00:12:47 | Bagder | yes |
00:13:18 | ts-x | Hey for anyone working on the H3xx wps flickering issue, I think I found something that might help (and maybe you are already aware of?) |
00:13:35 | Massa | I thought he's "only" responsible for www.misticiriver.net... |
00:13:44 | Moos | both of them |
00:13:54 | Massa | ts-x: Isn't the flickering already fixed in the latest CVS version? |
00:14:09 | ts-x | Not entirely |
00:14:24 | ts-x | But what I've found is that it's only the %x images that are flickering |
00:14:51 | ts-x | Preloaded and conditionaly displayed bitmaps are not flickering |
00:15:05 | ts-x | I tried the exact same image both ways and found this to be true |
00:15:29 | Moos | good night @ all |
00:15:37 | | Quit Moos ("Glory to Rockbox") |
00:15:56 | Massa | I'm not very experienced in WPS, but isn't %x for preloaded images? |
00:16:25 | ts-x | %x loads and displays immediately |
00:16:25 | Massa | Moos: good night! |
00:18:33 | Massa | so only %xl preloads images? |
00:18:55 | ts-x | Yes |
00:19:17 | ts-x | I just loaded Rockbox for the first time on Friday and kind of stumbled upon this during the wps creation process |
00:19:47 | Massa | Hmm, when you look e.g. in engineer2 wps, all images will be preloaded with %xl |
00:19:49 | | Join tarn [0] (n=irc@tor/session/x-3d6ef1891163788f) |
00:20:08 | Massa | (at least in the version I use ;) - and it still flickers... |
00:20:24 | ts-x | The background is %x |
00:20:37 | ts-x | Image 'a' |
00:21:24 | Massa | You're right - and you changed it so it's preloaded? |
00:21:32 | Massa | And it did not flicker any more? |
00:21:40 | | Quit tarn () |
00:22:16 | ts-x | I just tested engineer as well, just the background is flickering. Everything else is ok. |
00:22:58 | ts-x | Let me change it and test... |
00:23:17 | dropandho | that would be dope to fix that bug! |
00:25:30 | Massa | I didn't test the latest CVS changes, is it still flickering? |
00:26:54 | | Quit Kohlriba ("Leaving") |
00:27:12 | | Join chiller_ [0] (i=staale@kristoffersen.ws) |
00:27:19 | | Quit chiller (Read error: 104 (Connection reset by peer)) |
00:27:28 | | Nick chiller_ is now known as chiller (i=staale@kristoffersen.ws) |
00:30:40 | | Quit chiller (Read error: 104 (Connection reset by peer)) |
00:32:11 | | Join chiller [0] (i=staale@kristoffersen.ws) |
00:39:47 | ts-x | Not having much luck with engineer since not preloading the background seems to cause it to overlap everything else |
00:40:16 | Massa | And removing it would help? |
00:44:21 | ts-x | I just did that - it significantly reduces flickering but it still flickers when pausing and changing tracks |
00:45:01 | ts-x | What's strange is that the wps I'm creating doesn't flicker on pausing or track changes |
00:45:37 | Massa | Yeah, that's really strange... |
00:46:09 | Massa | I'll leave now and go to bed... |
00:46:12 | Massa | Good night! |
00:46:22 | ts-x | Seems to indicate that multiple factors are contributing the flickering |
00:46:25 | ts-x | Good night |
00:46:37 | ts-x | Well if nothing else maybe this information will help one of the devs... |
00:47:30 | | Quit PaulJ (".") |
00:52:55 | | Quit Massa ("ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050915]") |
00:53:54 | | Join Jungti1234 [0] (n=jungti12@58.77.81.144) |
01:00 |
01:07:03 | | Quit San||Away (Read error: 110 (Connection timed out)) |
01:10:25 | | Quit saa[b_r]ider (Read error: 104 (Connection reset by peer)) |
01:10:55 | | Quit ts-x ("CGI:IRC (EOF)") |
01:11:17 | | Quit ratpack91 ("Azureus 2.3.0.6") |
01:13:23 | *** | Saving seen data "./dancer.seen" |
01:15:32 | | Quit Bger () |
01:26:32 | | Quit gromit` (Remote closed the connection) |
01:29:15 | | Quit Dima202 ("Leaving") |
01:30:54 | | Quit ender` (Read error: 113 (No route to host)) |
02:00 |
02:21:29 | | Quit einhirn (Read error: 110 (Connection timed out)) |
02:26:53 | | Join actionshrimp [0] (n=NNSCRIPT@host86-136-104-122.range86-136.btcentralplus.com) |
02:46:50 | | Join San [0] (n=sanitari@213-202-130-199.bas502.dsl.esat.net) |
02:57:11 | | Quit tvelocity ("Leaving") |
03:00 |
03:09:18 | | Quit Jungti1234 ("bye") |
03:13:26 | *** | Saving seen data "./dancer.seen" |
03:37:53 | | Quit San (Read error: 110 (Connection timed out)) |
03:43:08 | | Join amiconn_ [0] (n=jens@p54BD45CD.dip.t-dialin.net) |
04:00 |
04:01:16 | | Quit amiconn (Read error: 110 (Connection timed out)) |
04:01:17 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD45CD.dip.t-dialin.net) |
04:02:22 | | Quit actionshrimp ("a bird in the bush is worth two in your house") |
04:06:26 | | Quit ehntoo ("Leaving") |
04:06:47 | | Join ehntoo [0] (n=ehntoo@24-177-166-0.dhcp.mrqt.mi.charter.com) |
04:19:38 | | Quit TCK (Read error: 104 (Connection reset by peer)) |
04:31:15 | | Join Midgey34 [0] (n=Midgey34@c-24-11-55-125.hsd1.mi.comcast.net) |
04:42:17 | | Join Jungti1234 [0] (n=jungti12@58.77.81.144) |
04:43:21 | Jungti1234 | hi |
04:48:49 | dropandho | hey man...what up?! |
04:52:25 | Jungti1234 | what up? |
04:53:45 | | Quit Jungti1234 ("bye") |
05:00 |
05:04:01 | | Join Rob2222_ [0] (n=Miranda@ACB60B8C.ipt.aol.com) |
05:10:35 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
05:13:14 | | Part Midgey34 |
05:13:31 | *** | Saving seen data "./dancer.seen" |
05:14:45 | | Join San [0] (n=sanitari@A-102-53.cust.iol.ie) |
05:19:39 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
05:28:00 | | Quit ehntoo ("Leaving") |
05:28:01 | | Quit San (Read error: 104 (Connection reset by peer)) |
05:36:59 | | Join gursikh [0] (n=gursikh@adsl-209-30-245-110.dsl.hstntx.swbell.net) |
05:38:24 | gursikh | Hello |
05:40:25 | | Quit ReKleSS (kornbluth.freenode.net irc.freenode.net) |
05:40:25 | NSplit | kornbluth.freenode.net irc.freenode.net |
05:40:30 | NHeal | kornbluth.freenode.net irc.freenode.net |
05:40:30 | NJoin | ReKleSS [0] (n=ReKleSS@c220-237-136-11.mckinn1.vic.optusnet.com.au) |
05:44:09 | Paul_The_Nerd | Hello |
05:45:01 | gursikh | This forums have been down for some time, Is this intentional? |
05:45:13 | dropandho | not that i am aware of |
05:45:34 | dropandho | apparently Jeff, from misticriver, hosts the forums |
05:45:54 | dropandho | i have reported it to him on IM today, but haven't received any word back from him |
05:46:16 | dropandho | i hope someone else has some word on it |
05:46:31 | | Join webguest24 [0] (n=c87ec44a@labb.contactor.se) |
05:46:48 | gursikh | This morning (14 hours ago) before work it was down, so it's been quite some time |
05:47:10 | dropandho | yeah, it has been a while |
05:47:15 | | Quit webguest24 (Client Quit) |
05:47:20 | dropandho | haven't caught Linus on here- to report it to him |
05:47:37 | dropandho | any ideas what to do next? |
05:47:59 | gursikh | Is there any other contact for Jeff? |
05:48:44 | | Join Midgey34 [0] (n=Midgey34@c-24-11-55-125.hsd1.mi.comcast.net) |
05:49:16 | dropandho | jeff@misticriver.net |
05:49:21 | dropandho | u wanna hit him up? |
05:49:35 | gursikh | he has not responded via AIM ? |
05:49:51 | dropandho | correct...he has not written back |
05:50:17 | gursikh | via AIM or Y! messengers? |
05:50:17 | dropandho | i cant ping the forum address either |
05:50:20 | dropandho | AIM |
05:50:37 | dropandho | it said he was "active" also |
05:51:20 | gursikh | he has both, Let me attempt yahoo. |
05:53:23 | gursikh | Is there additional contact Infomation for Linus? |
05:54:17 | dropandho | linus@haxxNO.SPAM.se |
05:54:33 | dropandho | off of the site |
05:54:40 | gursikh | yeah, i got that one. |
06:00 |
06:01:33 | | Quit Paul_The_Nerd ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
06:03:59 | dropandho | any luck? |
06:04:09 | gursikh | none |
06:04:54 | dropandho | bummer |
06:05:00 | gursikh | he just put on his away message on aim after i IMMED him. |
06:05:00 | dropandho | i need to head out now for bed |
06:05:16 | dropandho | darn |
06:05:32 | dropandho | welp, im off now |
06:05:38 | dropandho | hope something comes up |
06:05:54 | gursikh | yes |
06:05:54 | dropandho | u email linus and jeff? |
06:06:12 | gursikh | Yup |
06:06:29 | dropandho | great- we have it covered |
06:06:31 | dropandho | thanks man |
06:06:34 | dropandho | have a good night |
06:07:28 | | Quit dropandho () |
06:17:43 | | Quit Nibbler (Read error: 110 (Connection timed out)) |
06:21:39 | | Quit mikearthur (Connection timed out) |
06:21:51 | | Join mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk) |
06:24:21 | | Join Nibbler [0] (n=sven@e181087182.adsl.alicedsl.de) |
06:36:48 | | Quit mikearthur (Read error: 104 (Connection reset by peer)) |
06:40:44 | | Quit gursikh (Remote closed the connection) |
07:00 |
07:13:35 | *** | Saving seen data "./dancer.seen" |
07:17:22 | | Part Midgey34 |
07:19:30 | | Quit RotAtoR () |
07:27:21 | | Join San [0] (n=sanitari@213-202-135-222.bas502.dsl.esat.net) |
07:47:57 | | Join Jungti1234 [0] (n=jungti12@58.77.81.144) |
07:59:53 | | Join saa[b_r]ider [0] (n=saab_rid@221.216.54.167) |
08:00 |
08:04:23 | Jungti1234 | hoo |
08:17:48 | | Join Bger [0] (n=Bager@83.222.160.88) |
08:19:20 | Jungti1234 | hi Bger |
08:19:26 | Bger | hi, Jungti1234 :) |
08:34:47 | | Quit San (Read error: 104 (Connection reset by peer)) |
08:34:47 | | Quit saa[b_r]ider (Read error: 104 (Connection reset by peer)) |
08:36:16 | | Join ender` [0] (i=ychat@84.52.165.220) |
08:50:07 | | Join Acksaw [0] (i=Acksaw@spc1-stok5-4-0-cust5.bagu.broadband.ntl.com) |
09:00 |
09:03:38 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
09:04:38 | | Quit Acksaw () |
09:04:58 | Bger | wow, we have 3 independend buttons on h300 (main unit) : ON (aka play/pause), MODE (aka A-B) and REC |
09:05:21 | Bger | s/independend/independenT |
09:09:34 | | Join LinusN [0] (n=linus@labb.contactor.se) |
09:10:01 | Jungti1234 | hi Linus |
09:11:11 | | Quit Rob2222_ () |
09:12:37 | LinusN | hey ho |
09:13:37 | *** | Saving seen data "./dancer.seen" |
09:15:43 | XavierGr | Hi LinusN! |
09:16:37 | LinusN | hi |
09:17:54 | XavierGr | LinusN: Theoritically, can I start a new thread within a plugin? |
09:18:17 | XavierGr | (but current plugin continue to run) |
09:18:37 | XavierGr | like having a sub thread at the time the current plugin runs. |
09:20:00 | XavierGr | I know I can start a thread in a tsr plugin but then I exit the plugin (it runs in the background) so I am not sure if I can. |
09:22:51 | LinusN | XavierGr: yes you can |
09:23:01 | XavierGr | interesting. |
09:23:20 | XavierGr | I quite finished the new version of the jpeg filescroller. |
09:24:24 | XavierGr | In order to have as more entries as you can, I decided that filenames must be written in a file and a pointer array would hold their seek positions in the file. |
09:24:49 | XavierGr | That is nice until sorting comes into play. |
09:25:06 | LinusN | how do you create the file? |
09:25:15 | XavierGr | To sort ~850 entries with qsort an interval of 6-7 seconds is needed. |
09:25:54 | XavierGr | you mean how I write the entries in the file? |
09:26:21 | XavierGr | (I create the file with rb->open) then I scan the folder and filter jpeg files |
09:26:38 | XavierGr | for each entry I write down to the file the name of the jpg. |
09:26:47 | LinusN | ah ok |
09:26:57 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
09:27:36 | XavierGr | thing is that when I try to sort the compare function must open read 2 position get the names close the file and then compare the 2 entries. |
09:27:58 | XavierGr | for a small number of files this is quite easy and fast but if you have a big list then.... |
09:30:36 | XavierGr | so I had the idea of letting the user see the jpeg of his choice and then run a different transpaerent thread for sorting. |
09:31:56 | preglow | w00t, my player locked up |
09:31:57 | XavierGr | also for the iriver targets I made a small interface to check if playback occurs to try to fetch plugin memory instead of the audio buffer. |
09:32:10 | XavierGr | your iPod nano? |
09:32:35 | preglow | of course not |
09:32:45 | XavierGr | iHP? |
09:32:49 | preglow | that never locks up!! |
09:32:52 | preglow | yeah, ihp |
09:32:58 | preglow | when trying to start playback right after using usb |
09:33:00 | preglow | plain locked |
09:33:05 | preglow | wouldn't turn off no how |
09:33:12 | XavierGr | reset :) |
09:33:16 | preglow | yes, of course |
09:33:16 | | Join Zagor [0] (n=bjst@pdpc/supporter/sustaining/Zagor) |
09:34:18 | XavierGr | Does anyone know if the grayscale needs the same memory on all targets? Eg. iriver needs ~86kB what about archos models? |
09:34:40 | XavierGr | make that 8kB I think |
09:34:58 | B4gder | it most definately is not the same amount |
09:36:11 | XavierGr | we can easily determine that with a splash in th jpeg viewer. (at least the method I used) anyone willing to help me find it? |
09:37:01 | amiconn | You can't splash() while grayscale is running |
09:37:20 | XavierGr | well I splash right before. |
09:37:26 | amiconn | However, the amount of mem is easy to calculate; the formula is given in the grayscale lib sources |
09:37:41 | XavierGr | gray_init outputs the size needed with an argument |
09:38:43 | amiconn | apps/plugins/lib/gray_core.c, line 106ff |
09:41:02 | XavierGr | what's bitpatterns? |
09:44:38 | XavierGr | anyway I am asking this to see if Archos targets are capable of viewing while playing (at least a very small pic < 5kB) but as I see it with current plugin memory on archos this is not possible, am I right on this? |
09:45:30 | XavierGr | grayscale cannot fit in the archos plugin memory, I think. |
09:45:33 | Bger | can someone help me in understanding the following |
09:45:35 | Bger | @@ -166,9 +166,12 @@ |
09:45:43 | Bger | in a diff file ? |
09:46:01 | XavierGr | lines and offsets to apply the patch |
09:46:11 | Bger | yes, but... |
09:46:34 | Bger | what does the ",9" and ",12" mean ? |
09:46:51 | XavierGr | dunno :( |
09:46:59 | B4gder | why does it matter? |
09:47:09 | ze | Bger: count the lines |
09:47:45 | Bger | B4gder: because i'm trying to edit a diff file |
09:47:58 | B4gder | then that line won't matter much |
09:48:02 | amiconn | XavierGr: Yes you're right. On Archos it's possible to fit unbuffered grayscale with <33 shades in plugin memory with small plugins (e.g. mandelbrot), but not with full depth and the jpeg plugin takling almost all plugin memory for itself |
09:48:08 | B4gder | patch only uses that as a hint |
09:48:17 | Bger | aha |
09:48:33 | ze | Bger: i think the 1st is the number of lines that the specified chunk has before the patch, and the 2nd is the number of lines in that chunk after patching |
09:48:46 | Bger | then what does the "unexpected end of patch" or simillar mean ? |
09:49:03 | B4gder | it means patch didn't like the format of the patch |
09:49:08 | ze | and i think patch does expect it to be right |
09:49:35 | Bger | heh, B4gder ... |
09:49:45 | XavierGr | amiconn: Thanks then I will remove this option for archos with low plugin memory. |
09:51:24 | Bger | so if i edit a diff file and remove a number of different lines, should i change these values as well ? |
09:52:09 | B4gder | I would advice against hand editing a diff file |
09:52:53 | XavierGr | except if it is rather small change (E.g on the same line) |
09:54:05 | Bger | B4gder then what u do when u've changed many files but u want to make a diff of only 5-6 ? |
09:54:27 | | Join b0br [0] (n=c15421fd@labb.contactor.se) |
09:54:34 | ze | just diff those files? |
09:54:36 | B4gder | then I diff only those |
09:54:37 | Bger | also, there are some very little diffs (like whitespace) ? |
09:54:47 | B4gder | then use an option that ignores whitespace |
09:54:53 | Bger | heh |
09:55:07 | Bger | which is ? |
09:55:11 | B4gder | -b and -B |
09:55:18 | Bger | 10x |
09:55:25 | B4gder | or possibly -w ;-) |
09:55:43 | Bger | does the cvs diff support these ? |
09:55:44 | B4gder | and -E |
09:55:46 | * | B4gder grins |
09:55:57 | B4gder | it supports -B and -b at least |
09:56:07 | * | Bger goes to RTFM |
09:56:32 | B4gder | and to make a single patch, you can just concatenate any number of single-file diffs |
09:57:02 | B4gder | diff files built this planet |
09:57:06 | Bger | but cvs diff does it afaics ... or i'm wrong |
09:57:47 | Bger | (concatenating) |
09:58:06 | B4gder | yes it does, but I mean in case you use multiple command line invokes |
09:58:18 | Bger | ahap... 10x :) |
10:00 |
10:00:18 | XavierGr | I hate when I am diffing from CVS and I have a new file. |
10:00:28 | XavierGr | I just can't make it to add it. |
10:00:36 | | Join Vlad0man [0] (n=Vladoman@p54A7FD0E.dip.t-dialin.net) |
10:00:40 | Bger | someone told there is a command for doing it |
10:00:48 | Bger | iirc markun |
10:00:54 | XavierGr | Instead i do single diff of 2 identical cvs'es (the other has the changes) |
10:01:43 | | Quit _Vladoman (Read error: 110 (Connection timed out)) |
10:02:19 | markun | yes, install cvs tools. Then: cvsdo add 'file' |
10:02:34 | markun | and make the patch with cvs diff -uN 'files' |
10:03:52 | XavierGr | God I am an as*hole!!!! |
10:04:37 | XavierGr | markun I suppose that I don't need cvs acces for this right? |
10:04:48 | markun | not with cvsdo |
10:04:48 | Bger | yep |
10:05:14 | XavierGr | ok thanks. |
10:06:22 | Bger | heh i don't see such ebuild ... (cvs tools or sth similar) |
10:06:35 | | Part b0br |
10:07:20 | Bger | B4gder cvs diff supports all three -b -B -w |
10:08:53 | linuxstb | preglow: When did you last compile and install the bootloader on your Nano? The current CVS doesn't load the original firmware any more for me. |
10:09:30 | preglow | linuxstb: aeons ago |
10:09:48 | preglow | linuxstb: it doesn't here either |
10:09:51 | preglow | linuxstb: it just hangs |
10:10:23 | linuxstb | OK. I'm thinking of changing it anyway, so instead of having the apple OS in the boot partition, it loads it from the disk. This should speed up booting a little. |
10:10:47 | preglow | oh, you mean dumping it to a file first? |
10:11:03 | linuxstb | Yes - you have to do that as part of building the bootloader anyway. |
10:12:35 | XavierGr | OMFG Sorting the list from the file will need 18 seconds. |
10:12:59 | XavierGr | (for 850 files) |
10:13:14 | B4gder | XavierGr: 18 seconds to sort 850 names? |
10:13:19 | linuxstb | Wow, I've just tested it with a 512KB "dummy" firmware file, and the boot time on my iPod decreased by about 4 seconds. |
10:13:31 | XavierGr | yes. but the names are sorted in a file |
10:13:55 | B4gder | XavierGr: you mean you don't read the file, only move them around within the file? |
10:15:02 | XavierGr | No, the file remains unchanged, I just move the pointers that hold the seek position of each name. The strings are never loaded into memory (except 2 strings each time in the comapre function) |
10:15:22 | XavierGr | Maybe I can do that a little faster, but not much... |
10:15:32 | B4gder | that's what the playlist code does |
10:15:36 | B4gder | it is _waaaaay_ faster |
10:15:43 | XavierGr | A different thread will make it run at least transparent. |
10:16:02 | amiconn | XavierGr: Directly sorting a file will probably be way slower onm Ondio |
10:16:19 | B4gder | oh well, it doesn't always sort them but anyway |
10:16:38 | XavierGr | is it that I open and close the file inside the compare? I think i can just leave open the file and close it in the end of the sorting process. |
10:16:39 | B4gder | I guess that's the reason |
10:17:03 | B4gder | XavierGr: how do you do the sort in the first place? qsort() ? |
10:17:05 | linuxstb | XavierGr: Why don't you store the list of files in memory, then sort, then write to disk - at least if it is possible to do so, which on the iriver I expect it would be 99% of the time. |
10:17:09 | XavierGr | amiconn: we need to do some tests after I finish this. |
10:17:36 | XavierGr | B4gder: yes I use qsort. |
10:18:14 | XavierGr | linuxstb: Storing in memory 1000 * 20 names will eat all my plugin memory buffer, which I need to hold for the jpeg in order not to stop playback. |
10:18:36 | linuxstb | Yes, but you can write them to disk _after_ sorting them. |
10:18:58 | XavierGr | hmm and then flash that space eh? |
10:19:01 | linuxstb | I'm assuming you load the file list before you load any images. |
10:19:10 | XavierGr | yes |
10:19:28 | linuxstb | Yes, and then you can free that space and use it for the images. |
10:19:59 | XavierGr | sounds neat, I could try that. |
10:20:12 | | Join _FireFly_ [0] (n=icechat5@pd95b7c08.dip0.t-ipconnect.de) |
10:20:28 | XavierGr | Hi _FireFly_. |
10:20:44 | XavierGr | _FireFly_: and we were talking about sorting :) |
10:24:52 | preglow | think i'll need to upgrade my bootloader soon |
10:24:58 | preglow | now for finding a linux pc where i can do it |
10:26:30 | linuxstb | preglow: If I remove the 5.5MB Apple firmware from my boot partition, then my Ipod will boot to the file browser in about 4 seconds. |
10:26:42 | linuxstb | It was about 7-8 seconds with it. |
10:26:48 | XavierGr | I will be damned. Moving the open, close file functions outside of compare functins dropped the sorting time from 18,5 seconds down to 3,5 seconds!!! Isn't this great? |
10:27:59 | _FireFly_ | XavierGr ,9 |
10:28:01 | _FireFly_ | ,9 |
10:28:04 | _FireFly_ | ;) |
10:28:17 | preglow | linuxstb: how the hell can it be so much faster |
10:28:18 | preglow | ? |
10:28:54 | linuxstb | The flash bootloader is obviously very slow at loading the boot partition. It will also have to calculate and verify a checksum before executing it. |
10:29:47 | linuxstb | But the good thing is that it doesn't do any check on the minimum size - I'm writing a 84KB boot partition and it's working perfectly. |
10:31:08 | linuxstb | So I'm definitely in favour of putting the apple_os.bin file on the fat32 partition. What do you think? |
10:31:32 | linuxstb | It probably has less of an effect on your Nano, but I'm sure you will still notice a speed-up. |
10:31:58 | | Join San||Away [0] (n=sanitari@213-202-158-64.bas503.dsl.esat.net) |
10:32:59 | linuxstb | You can test it by creating a dummy 512 byte file (e.g. dummy.bin), and then create a boot partition using "ipod_fw -g nano -o rockboot.bin -l dummy.bin bootloader.bin" |
10:33:22 | | Join saa[b_r]ider [0] (n=saab_rid@221.216.54.236) |
10:44:08 | preglow | hrmph |
10:44:08 | preglow | well |
10:44:14 | preglow | i'm going to start working on a linux box soon |
10:48:01 | linuxstb | Do you think we should try and fix loading the apple firmware via the boot partition, or just abandon that method and always load it from a file? |
10:48:19 | preglow | loading from a file sounds just dandy to me |
10:48:23 | preglow | if you need to make that file anyway |
10:48:24 | preglow | which you do |
10:48:39 | linuxstb | OK then. I'm happy to to shave 4 seconds off my boot time to Rockbox. |
10:49:34 | preglow | but okiedokie |
10:49:42 | preglow | why the hell doesn't this work on your ipod |
10:50:17 | linuxstb | I've tried the new button driver, and it's not as good as I would have hoped. I added a loop in the bootloader that reads the key state and displays it, but it still doesn't always recognise a key that is pressed before the bootloader starts. |
10:50:41 | linuxstb | But I think it could be used to poll the button status if we wanted to write a polling button driver. |
10:51:18 | linuxstb | The code that's there only checks the 5 real buttons - it doesn't give a status for the scrollwheel. But hopefully that can be added. |
10:51:24 | preglow | hmm |
10:51:30 | preglow | do we really want a polling driver? |
10:51:39 | preglow | if you ask me, an interrupt driven one is better |
10:51:48 | preglow | you only poll when you need to, and polling interval issues are gone |
10:52:40 | linuxstb | Of course - an interrupt driven driver will be better. |
10:53:03 | preglow | hmm, i think i'll introduce the sleep loop again |
10:53:10 | preglow | to see if the tick timer is really working |
10:53:40 | linuxstb | OK. Let me know if you want me to do any more tests. |
10:54:22 | linuxstb | I'll try and make the bootloader changes later today. |
10:55:58 | linuxstb | Anyone got any news about the forums? I hope it's not a serious problem. |
10:56:06 | XavierGr | what is working currently on rockbox for ipods? |
10:56:22 | preglow | we'll see |
10:56:26 | preglow | XavierGr: i am |
10:56:31 | linuxstb | XavierGr: It boots up into the file browser, but there is currently no button driver. |
10:56:34 | preglow | a lot of forums have been hacket lately |
10:56:35 | preglow | hacked |
10:56:45 | preglow | ahh, what, not who :-) |
10:56:49 | linuxstb | :) |
10:56:50 | | Join tucoz [0] (n=martin@hornved.ii.uib.no) |
10:56:58 | XavierGr | linuxstb: And how do you turn it off? :D |
10:57:17 | linuxstb | You never turn the ipod off... |
10:57:32 | linuxstb | But you press a key combination for a hardware-controlled reboot. |
10:57:45 | linuxstb | This works even if Rockbox has crashed. |
10:57:46 | preglow | woot, works even with that loop now |
10:57:47 | XavierGr | also what do you think about audio on iPod. Will it be easy now that we have iriver targets working on that aspect? |
10:58:05 | preglow | audio on ipod is going to need a lot of work |
10:58:13 | preglow | to get it running on two cores, at least |
10:58:32 | preglow | linuxstb: but okay, what's the status on ipod button mappings? |
10:58:42 | XavierGr | it has a different DAC too, right? |
10:58:48 | preglow | yes |
11:00 |
11:00:02 | linuxstb | Those are pretty much finalised - see button.h. In addition to the five buttons specific to the ipod, there is the generic BUTTON_LEFT and BUTTON_RIGHT |
11:00:36 | tucoz | sorry for the off-topic, anyone familiar with dvd regions? I can play region 1 dvd's in linux, but when I try to play it in windows it tells me I only have 4 more region changes left. Is this shifting done in sw or the dvd-player hw? |
11:00:51 | linuxstb | Both IIRC. |
11:00:54 | tucoz | oh |
11:01:07 | linuxstb | The DVD-ROM can have region settings, and so can the DVD playing software. |
11:01:11 | tucoz | but linux doesn't care? |
11:02:03 | linuxstb | I think it cares about the DVD-ROM settings (it can't affect them), so it sounds like it is just a software issue with your Windows player. |
11:02:26 | linuxstb | You can try a free Windows DVD player such as VLC - http://www.videolan.org/vlc |
11:03:00 | tucoz | linuxstb, ok. good. thanks. Then the dvd-rom is probably region free, but the player-sw is not. |
11:03:06 | linuxstb | Yes, sounds that way. |
11:03:15 | tucoz | thanks |
11:03:40 | preglow | but ok, first, find out why it doesn't work with you |
11:03:57 | preglow | what approach should we take to that? debug stuff before commit, or commit then debug? :) |
11:04:24 | linuxstb | I would say commit then debug. But commit in small stages if that's possible. |
11:04:32 | preglow | sure |
11:05:09 | tucoz | linuxstb, are you in london btw? |
11:05:20 | linuxstb | tucoz: Yes. |
11:05:23 | | Quit San||Away (Read error: 110 (Connection timed out)) |
11:06:00 | tucoz | linuxstb, looks like the end of the world over there. |
11:06:12 | Slasheri | Hmm, i think now the tagcache building should work on archos too :) And simple searches works now also |
11:06:22 | tucoz | http://img.aftonbladet.se/nyheter/0512/12/londoncalling.jpg |
11:07:42 | tucoz | Slasheri, cool. |
11:08:22 | Slasheri | It creates one temporary file when building the cache and then parses that file into 5 separate files with one master lookup table |
11:08:48 | Slasheri | then it should be possible on some platforms load that structure into ram also |
11:08:49 | tucoz | Slasheri, when adding or removing files to the player, will the tagcache rebuild the enitre db or just the add/remove the changes? |
11:09:08 | Slasheri | tucoz: no, it can add files without completely rebuilding it |
11:09:24 | tucoz | oh, that sounds good |
11:09:34 | linuxstb | Is that part working yet? |
11:09:53 | Slasheri | with dircache that rebuilding is automatic on boot, and without it manual start of database check is required |
11:10:23 | Slasheri | linuxstb: building works and update worked too some time ago (but i just changed the structure a little), so it should be work quite well |
11:11:24 | tucoz | I like the morse code input. Never thought that I would be able to learn morse, but it is actually a really good input method. |
11:11:30 | preglow | tucoz: nice pic |
11:11:41 | Slasheri | tucoz: hehe =) |
11:12:01 | tucoz | preglow, it looks manipulated, but according to the news-article it is not. |
11:12:08 | preglow | just what london needs, more smog |
11:12:10 | amiconn | XavierGr: Building and sorting the list beforehand sounds good, however, the drawback is that you can't do it in the background (not a major concern imho) |
11:12:13 | tucoz | hehe |
11:13:40 | *** | Saving seen data "./dancer.seen" |
11:15:20 | tucoz | I think, if I would ever use the database is that it is built just the way Slasheri has done. I never get used to running a host-program to set up the database. |
11:15:46 | tucoz | as I tend to remove and add stuff all the time, and do not have java on my computer :) |
11:15:57 | B4gder | well, the java version is overbloated |
11:16:04 | B4gder | imo |
11:16:19 | XavierGr | amiconn: There are many things that I have to plan if I do that. 1) I must split the remaining plugin buffer into 2 parts. (fortunately I can predict where to split) 1 buffer for the pointer array and one for the filenames. |
11:16:23 | tucoz | B4gder, well the perl script is probably nicer. |
11:16:29 | | Join Membrillo [0] (n=sam_kill@CPE-144-131-87-124.nsw.bigpond.net.au) |
11:16:36 | | Join Polo_o [0] (n=polo_o@82-69-160-166.dsl.in-addr.zen.co.uk) |
11:16:39 | B4gder | I think this not only because I wrote the perl version |
11:16:42 | preglow | the target way is nice in that it supports everything rockbox does |
11:16:52 | XavierGr | amiconn: Then when the list is sorted into memory, I will have to change the pointer array values with the seek points of the file list. |
11:17:00 | B4gder | "the proper way" would be to offer host host and target to do it |
11:17:00 | preglow | and automatically |
11:17:05 | preglow | yep |
11:17:05 | B4gder | both |
11:17:10 | XavierGr | then I can discard the data for the jpeg buffer. |
11:17:12 | preglow | but in this case i'd really like to use the same code |
11:17:17 | B4gder | preglow: indeed |
11:17:21 | tucoz | B4gder, no. But the fact that I need a full JRE to build the database is not that nice. |
11:17:24 | preglow | i wonder if it's possible to make get_metadata work for host as well |
11:17:26 | B4gder | and that's why there's a start for db code in C in CVS |
11:17:28 | preglow | that would be just dandy |
11:17:38 | linuxstb | IIUC, Slasheri mentioned that it was faster to build the database on the iriver than on a PC. |
11:17:40 | B4gder | preglow: that would be the best approach |
11:17:54 | tucoz | really, hehe that is amazing |
11:17:54 | B4gder | linuxstb: his code is faster than the current tools on PC, sure |
11:18:02 | B4gder | blame the crc mania |
11:18:08 | B4gder | which I doubt Slasheri uses |
11:18:17 | B4gder | so his code can't do the runtimdb |
11:18:17 | linuxstb | But I would expect the bottleneck to be the disk accesses, not the CPU. |
11:18:28 | linuxstb | (apart from CRC of course) |
11:19:09 | B4gder | well, I can't see how the target can be even close to host, speedwise, if they'd do the same thing |
11:19:30 | B4gder | since both CPU and disk are waaay faster on host |
11:19:33 | tucoz | I see, so title, album, artist is not good enough for the runtimedb? |
11:19:35 | B4gder | and amounts of ram |
11:19:41 | B4gder | tucoz: nopes |
11:19:48 | tucoz | Why is that? |
11:19:53 | B4gder | read up |
11:19:56 | tucoz | sure |
11:20:15 | B4gder | because HCl wanted it to survive changed tags |
11:20:20 | B4gder | for example |
11:20:45 | tucoz | I get it |
11:21:02 | B4gder | personally I think it is overkill |
11:21:10 | tucoz | It is the actual track that is the key here, not the meta-data. |
11:21:14 | B4gder | yes |
11:21:29 | B4gder | and that's why it does CRC on a chunk of the audio data |
11:21:38 | B4gder | to use as key |
11:21:45 | tucoz | I understand |
11:22:24 | tucoz | Hmm, of course that has it's benefits but might be a little overkill yes. |
11:22:56 | tucoz | I think the audioscrobbler way is good enough for me. |
11:23:17 | Slasheri | in fact that crc code is not a solution for the runtimedb.. |
11:23:17 | XavierGr | what to choose for my big char array buffer, unsigned char, or simple char? |
11:23:18 | preglow | which is? |
11:23:28 | Slasheri | it only calculates the first 32 KiB of data or something like that |
11:23:28 | B4gder | Slasheri: why not? |
11:23:50 | B4gder | "only" 32kb |
11:23:54 | Slasheri | so it's more than likely there will be more than one identical song the db sees |
11:24:02 | B4gder | I doubt that |
11:24:05 | Bger | ok, new version of the h300 lcd remote buttons patch is on the patchtracker |
11:24:14 | B4gder | but I don't like that CRC approach anyway |
11:24:38 | linuxstb | XavierGr: It depends what the functions using that buffer are expecting. What are you storing in that buffer? |
11:24:40 | tucoz | preglow, I believe audioscrobbler just records the artist-title, and adds to the db if the track has been played more than 50% or 2.5 minutes (whichever comes first) |
11:24:53 | XavierGr | filenames |
11:25:25 | Slasheri | B4gder: for example wav files without any tag entries and similar mixes at the beginning.. |
11:25:31 | | Join mirak [0] (n=mirak@AAubervilliers-152-1-68-243.w86-198.abo.wanadoo.fr) |
11:25:34 | linuxstb | Then you should use the same type as the string functions (strncmp, strlen etc) - i.e. char |
11:25:34 | Slasheri | then db would see those as the same song |
11:25:40 | B4gder | Slasheri: the db tools don't even work with wav files ;-) |
11:25:46 | Slasheri | ah, hehe :D |
11:25:54 | B4gder | tucoz: audioscrobbler is more naive than we can be |
11:25:57 | XavierGr | linuxstb: ok thanks |
11:27:09 | B4gder | Slasheri: still, using that lame CRC is more likely to find the song than you are without it |
11:27:31 | tucoz | B4gder, ok |
11:27:36 | B4gder | given the premises |
11:27:42 | B4gder | but I think we should lower the goals |
11:29:00 | | Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) |
11:29:04 | preglow | hmm |
11:29:24 | linuxstb | B4gder: Are you suggesting we don't use a CRC at all? |
11:29:25 | | Quit yngwi (Client Quit) |
11:29:55 | B4gder | I haven't fully thought about it properly to have a final suggestion, but I think I lean towards dropping the CRC yes |
11:30:50 | linuxstb | The only alternatives I can think of is to use the path and filename (which can change) or the tags (which can be missing). |
11:31:15 | B4gder | I know |
11:31:22 | Slasheri | B4gder: Hmm, what will the current db do, if i move the song to another folder. Will it still keep the runtime data and find the song in future if the tagdb is rebuilt? |
11:31:23 | linuxstb | It's not uncommon for someone to re-organise the files on their player. So at least the paths will change. |
11:31:39 | B4gder | Slasheri: yes, I think that's the plan |
11:31:48 | Slasheri | It could be possible to add the crc or something similar identification to a separate tag index file |
11:31:53 | Slasheri | ok |
11:37:20 | tucoz | B4gder, did you have a look at the LaTeX stuff? |
11:39:39 | | Join DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
11:41:10 | preglow | linuxstb: btw, i don't remember if i disable the cop in my bootloader |
11:41:24 | preglow | linuxstb: if that is so, it's a small wonder it doesn't work with you |
11:43:05 | | Join Delazon [0] (n=chatzill@h83n2fls34o981.telia.com) |
11:44:54 | | Quit Membrillo () |
11:45:50 | Delazon | Thanx boys for the release of rockbox for H3xx!!! |
11:46:12 | _FireFly_ | Delazon: there isn't yet an release for h1xx and h3xx yet |
11:46:14 | Bger | Delazon there's no *release* |
11:46:27 | _FireFly_ | these are only testing builds :) |
11:46:47 | _FireFly_ | because not all functions are implemented or working correctly |
11:48:02 | linuxstb | preglow: I'm running the CVS bootloader at the moment - I think it does wake up the cop |
11:48:17 | preglow | try wrwapping the wakeup with an if 0 |
11:48:20 | preglow | that's what i have here |
11:48:53 | preglow | i don't really know what we're waking it up to |
11:48:56 | preglow | so i just let it sleep |
11:49:10 | * | XavierGr *sighs* and imagines the day that he will see an iHP Icon on the Download Rockbox page.... |
11:49:12 | mirak | is it possible to put mp3 in an ogg container ? |
11:49:31 | linuxstb | preglow: OK, trying now. |
11:49:32 | amiconn | XavierGr: If you sort the file list in-memory, you can drop the pointer array too after writing the file. Just write the file sorted, then you can calculate the seek position |
11:50:56 | Delazon | ok, i mean releasing a testbuild... i tested it and im elightend. It will be great when it?s finsished.... |
11:51:05 | Delazon | One question? |
11:51:09 | linuxstb | preglow: Success :) |
11:51:15 | Bger | Delazon just ask |
11:51:18 | linuxstb | Backlight faded after about 3 seconds. |
11:51:43 | Delazon | Will the user interface come in color or will it be in black and white all the time? |
11:51:58 | mirak | anyone could send me a H300 V3 firmware ? I can't patch it on linux, I don't know what I am doing wrong |
11:52:03 | linuxstb | Delazon: It is currently black and light-blue. |
11:52:20 | LinusN | mirak: what happens? |
11:52:30 | linuxstb | Delazon: But yes, Rockbox can be made in as many colours as you want - it just needs a developer to work on it. |
11:52:38 | Delazon | Yes, you guy?s marks my words ;) |
11:52:46 | Delazon | I mean monochrome then ;) |
11:53:35 | tucoz | Delazon, it will be in color eventually |
11:54:31 | Delazon | i switched back to iRiver fw for now... im a big radio listener, but when it?s released with full features i will swtich again. :D It was fun to test it. |
11:54:59 | Delazon | And this function WPS... i like it alot... |
11:55:05 | Bger | LinusN what has to be done before having working radio on h300 ? |
11:55:22 | LinusN | the i2c communication with the radio |
11:55:25 | Delazon | Big chans to do your on stuff fairly easy. |
11:55:34 | LinusN | i believe it uses different pins |
11:55:44 | Bger | aha... |
11:56:03 | Delazon | how manydevelopers are tou on this project? |
11:57:38 | XavierGr | Reminds me that my radio patch stills sits idle that enables mutlipreset list handling... |
11:58:24 | | Quit DJDD__ (Read error: 110 (Connection timed out)) |
11:58:35 | tucoz | Delazon, I don't know how many active developers there are, but the credits list more than a hundred. (all of them are of course not active) |
11:58:47 | XavierGr | amiconn: No, because if I don't hold the array with the seek possitions I will have to loop when I use a read_line(). (if I have the seek position I will just seek there first and read only 1 line) |
11:59:09 | Delazon | cool many devs then :) many to thnx later on then i guess ;) |
11:59:18 | amiconn | I thought you will use fixed field leghts... |
11:59:47 | XavierGr | amiconn: I think it is better to avoid that for various reasons. |
11:59:50 | preglow | linuxstb: i thought as much |
11:59:50 | amiconn | Then seeking becomes icredibly simple. |
12:00 |
12:00:01 | preglow | linuxstb: what's the default backlight time? |
12:00:35 | Delazon | can i come with a suggestion? |
12:00:42 | preglow | linuxstb: i'll let the if 0 stay in crt0.S when i commit |
12:00:42 | XavierGr | amiconn: If I hold the seek positions it becomes simple too. I will just loose entries * sizeof(int) bytes from memory |
12:00:50 | tucoz | Delazon, sure |
12:01:25 | LinusN | the h300 lcd doesn't like dma... |
12:01:32 | preglow | linuxstb: hooray |
12:01:42 | amiconn | preglow: 4 seconds iirc |
12:01:54 | preglow | ok, so the tick timer is probably off |
12:02:01 | preglow | no surprise |
12:02:13 | XavierGr | oh I have another problem: the range o an unsigned int is 0-65535 what if I need to go beyond that? Is it right to have longs? |
12:02:27 | preglow | sure |
12:02:40 | preglow | why shouldn't that be ok? |
12:02:41 | Delazon | when i use the player and the display shuts down or going in to sleep. To wake it upp you have to push a button. I would be glad if this push would result in the display woke up without the button push would for an example paus the musik or go in to the browser mode or change the volume... as it is in the iRiver FW. |
12:02:51 | LinusN | XavierGr: int is 32-bit on all current rockbox platforms |
12:03:05 | XavierGr | which means up to? |
12:03:18 | preglow | 4 billion |
12:03:19 | preglow | more than |
12:03:31 | XavierGr | ~4 millions? |
12:03:40 | amiconn | int *can* be 16bit, but we don't need to care |
12:03:50 | XavierGr | oh isn't this great! |
12:03:51 | LinusN | Delazon: you want the first push to only enable the lcd? |
12:03:55 | amiconn | There can't be more than 65536 files in a FAT directory |
12:04:00 | tucoz | Delazon, I like that idea as well. I normally use the record button for that, but I think it would be better if the first key press would wake up the lcd. |
12:04:02 | Delazon | Yes exatly :D |
12:04:02 | merbanan | 2raised by 32 for unsigned |
12:04:18 | preglow | LinusN: can you imagine any reason why i wouldn not want to use interrupts when implementing button driver? |
12:04:28 | LinusN | preglow: no |
12:04:40 | amiconn | ...and even 65536 files are only possible if none of them has long names |
12:05:47 | XavierGr | amiconn: seek position can be larger than 65535. |
12:05:56 | amiconn | Ah, yes |
12:06:06 | amiconn | Should be a long then |
12:06:34 | XavierGr | but Linus said that an int is considered 32 bit |
12:06:41 | XavierGr | no? |
12:07:18 | preglow | int is sometimes considered 32 bits |
12:07:20 | preglow | most often, perhaps |
12:07:22 | preglow | but it can be 16 |
12:07:26 | preglow | if you need more than 16, use long |
12:07:38 | XavierGr | so how would I know? |
12:07:42 | preglow | you don't |
12:07:45 | preglow | there are no guarantees |
12:07:58 | preglow | you also have int32_t, of course |
12:08:03 | preglow | which is always guaranteed to be 32 bits |
12:08:12 | preglow | but those aren't recommended for use in rockbox, for some reason |
12:08:14 | | Join muesli- [0] (n=muesli_t@141.71.4.180) |
12:08:31 | XavierGr | hmm long is double the bytes of an int, yes? |
12:08:35 | XavierGr | 8bytes? |
12:08:37 | preglow | 4 |
12:08:42 | preglow | long == int for most pplatforms |
12:08:54 | | Quit muesli- (Client Quit) |
12:09:16 | XavierGr | so I don't need to change sizeof(int) to sizeof (long int) right? |
12:11:42 | | Join Bger_ [0] (n=Bager@83.222.160.88) |
12:12:13 | | Quit Bger (Nick collision from services.) |
12:12:20 | | Nick Bger_ is now known as Bger (n=Bager@83.222.160.88) |
12:12:59 | | Join webguest54 [0] (n=5087d10e@labb.contactor.se) |
12:13:07 | Bger | Delazon |
12:13:13 | Bger | use Rec button |
12:13:21 | Bger | for only lighting the LCD |
12:13:54 | webguest54 | is the db scale (which I like), realtive to line out, and if so is line out taken before amplification or after ? |
12:14:18 | Bger | while on this topic, is there any reason for the rec button doesn't have any function ? |
12:14:39 | preglow | what's the declaration specs for a naked function, again |
12:14:40 | preglow | ? |
12:14:57 | LinusN | Bger: no |
12:15:23 | preglow | webguest54: relative to line out? it is relative to max level, regardless of output |
12:15:47 | | Join webguest58 [0] (n=5087d10e@labb.contactor.se) |
12:15:48 | | Quit webguest54 (Client Quit) |
12:15:53 | webguest58 | ugghh |
12:15:55 | Bger | XavierGr u should use sizeof(long int) if u use long int var ... |
12:16:17 | linuxstb | preglow: What's a "naked function" ? |
12:16:43 | preglow | linuxstb: a function without any wrapping code added by the compiler, afaik |
12:16:55 | preglow | linuxstb: like implicit return instruction, i want to use my own return instruction |
12:17:05 | Bger | hm, one more question |
12:17:16 | preglow | arm gets pretty fancy with its exception handler return methods |
12:17:36 | Bger | what about making some button (like ON/play) to light the screen even when the hold button is turned on ? |
12:17:55 | webguest58 | preglow:, thanks for the db info, now, is line out pre or post amplifier ? |
12:18:01 | preglow | Bger: i wouldn't want to waste my battery for the backlight when my hold is on |
12:18:07 | preglow | webguest58: post |
12:18:17 | preglow | webguest58: only outputs that are pre-amp is optical out |
12:18:17 | Bger | preglow even on nano ? |
12:18:28 | preglow | Bger: why even on nano? |
12:18:41 | | Nick Lynx_awy is now known as Lynx_ (n=lynx@tina-10-4.genetik.uni-koeln.de) |
12:18:42 | Bger | hm, i don't know whether nano has hold button |
12:18:54 | preglow | it does |
12:18:55 | Bger | but it has color LCD |
12:19:01 | preglow | it does |
12:19:06 | webguest58 | so to achieve best line out output the volime should be set to max ? |
12:19:15 | Bger | and u cant see the display with backlight off ... |
12:19:16 | preglow | but if i enable hold, it is for a reason: i keep it in my pocket, and buttons might be pressed all the time |
12:19:20 | preglow | which means the backlight might be constantly on |
12:19:24 | preglow | i don't want that |
12:20:11 | Bger | hm, my GSM brings the backlight on when i press the "call" button and i like this ... |
12:21:16 | Bger | i mean even when the keypad is locked |
12:21:59 | * | Bger whispers "new option" and goes to the corner |
12:22:45 | Jungti1234 | hey guys |
12:23:31 | Bger | yes, Jungti1234 |
12:23:35 | Jungti1234 | Where is Rockbox option saved? |
12:23:51 | Bger | on the hard disk |
12:24:01 | Jungti1234 | hmm.. |
12:24:03 | Bger | but in one sector out of the file system |
12:24:17 | Jungti1234 | where? |
12:24:30 | | Part webguest58 |
12:24:49 | LinusN | sector 62 |
12:25:30 | Jungti1234 | How do I do to delete it? |
12:25:42 | Delazon | ok thanx for your answers on the lcd matter... |
12:25:49 | Bger | Jungti1234 : if you have problems with your settings, you can reset them with pressing "rec" key while booting rockbox |
12:25:54 | Bger | or from the menu |
12:26:22 | Bger | Manage settings->reset settings |
12:26:33 | Jungti1234 | ah thanks |
12:28:42 | * | Bger remembers one of the first days of rb on h300, when he enabled the dircache and the unit self powered off right after booting because of the button driver problems... |
12:29:13 | | Part LinusN |
12:32:35 | preglow | why would i get an interrupt from the ide controller? |
12:34:29 | linuxstb | Mmm. I guess they haven't been disabled. I have no idea what the four cryptic lines in ata_init do. |
12:35:15 | | Part tucoz ("Leaving") |
12:37:25 | | Join webguest97 [0] (n=d5bd9d85@labb.contactor.se) |
12:37:38 | preglow | no, but anyway |
12:37:42 | preglow | why would i get it? |
12:37:52 | preglow | if i'm expecting data, i guess i should know about it |
12:37:54 | preglow | having requested it and all |
12:38:04 | preglow | then again, there's the latency, of course |
12:38:33 | webguest97 | would it be possible to attach a different screen to the h-1x0 player via the remote output? |
12:38:42 | linuxstb | preglow: So when are you getting the interrupt? |
12:39:01 | webguest97 | i mean is the resolution given by the player or by the remote itself? |
12:40:16 | preglow | linuxstb: i don't know if i'm getting it |
12:40:25 | preglow | linuxstb: i'm just wondering to what degree i'm going to bother with it it all |
12:40:28 | preglow | it at all |
12:42:17 | | Quit DJDD_ ("Trillian (http://www.ceruleanstudios.com") |
12:43:15 | linuxstb | Do you know what IPL does? |
12:43:23 | preglow | not in the least |
12:44:24 | | Join San||Away [0] (n=sanitari@213-202-153-202.bas503.dsl.esat.net) |
12:45:33 | | Quit webguest97 ("CGI:IRC (EOF)") |
12:46:50 | linuxstb | preglow: If we wanted to cheat with the timing of the ticker interrupt, we could update the current_tick variable by using the value in the RTC variable we are currently using to simulate the current_tick. |
12:46:59 | linuxstb | I don't know how accurate the timer needs to be for other purposes. |
12:48:04 | preglow | well, yeah, we could |
12:48:10 | preglow | but i'd rather do it properly first |
12:48:13 | preglow | then we'll see |
12:48:16 | mirak | hem, how do I make the tools now ? |
12:48:21 | mirak | something have changed ? |
12:48:32 | preglow | you type 'make' in your build dir |
12:48:48 | mirak | preglow: after running a full configure ? |
12:49:05 | preglow | yea |
12:49:24 | mirak | what devel option change ? |
12:49:27 | | Part Polo_o |
12:49:28 | mirak | debuging ? |
12:50:21 | | Join Polo_o [0] (n=polo_o@82-69-160-166.dsl.in-addr.zen.co.uk) |
12:51:51 | linuxstb | preglow: So you don't think it will be a problem to get the timer tick accurate? |
12:52:41 | preglow | linuxstb: the answer to that question depends a lot on how tricky cpu freq change is |
12:53:07 | preglow | but no, let's just try this approach first |
12:53:11 | preglow | i'll see about doing some commiting now |
12:54:59 | linuxstb | Do you update the current_tick variable yet, or have you left that the way it is? |
12:59:42 | preglow | i update it |
13:00 |
13:00:37 | | Join Rob2222 [0] (n=Miranda@ACB60B8C.ipt.aol.com) |
13:02:35 | | Quit _FireFly_ ("IceChat - Its whips the llama's butt") |
13:03:56 | XavierGr | in rockbox: char = 2bytes, long int = 4bytes. Please correct me if I am wrong. |
13:04:27 | B4gder | wrong |
13:04:32 | B4gder | char = 1 byte |
13:04:38 | mirak | how does the lcd screen is represented in memory ? is it just an offset that you set and wich is located into ram, or does it have it's own ram ? |
13:04:57 | B4gder | mirak: we have a framebuffer that represents what the LCD looks like |
13:05:06 | B4gder | mirak: lcd_update() writes that framebuffer to the actual hw |
13:05:26 | mirak | B4gder: the buffer size depends of the device it's been compiled on |
13:05:29 | mirak | ? |
13:05:31 | B4gder | yes |
13:05:53 | mirak | wich file is it defined ? |
13:05:57 | B4gder | and even how the frame buffer is layed out |
13:06:07 | B4gder | check firmware/drivers |
13:06:11 | B4gder | and the lcd*.c files |
13:06:12 | mirak | thanks |
13:09:28 | XavierGr | B4gder: and what about char* and long int*? |
13:09:36 | B4gder | 32 bits |
13:09:59 | XavierGr | so 4bytes both. |
13:10:06 | B4gder | yes |
13:10:21 | B4gder | but you should use sizeof() of course, if your code relies on the size |
13:10:32 | XavierGr | yes of course |
13:10:37 | XavierGr | ^course |
13:11:50 | XavierGr | I have a plugin memory orgie right now. I have to set 3 buffers, at least in the end only 1 will be left. |
13:13:41 | *** | Saving seen data "./dancer.seen" |
13:14:52 | | Quit Delazon ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
13:15:59 | * | B4gder debugs code booting from flash without any kind of hw attached... tedious and painful are words that pop up |
13:16:11 | B4gder | debug-hw I mean |
13:20:11 | mirak | what does it mean when there is only a line with (void)data; |
13:20:12 | mirak | ? |
13:20:24 | B4gder | that the variable isn't used |
13:20:27 | linuxstb | It's used to stop the compiler complaining. |
13:20:41 | mirak | so that's a dummy method |
13:21:00 | mirak | /* TODO: Implement lcd_blit() */ |
13:21:05 | mirak | I gues it is :) |
13:21:18 | B4gder | its not a "method" |
13:21:22 | B4gder | it is a variable |
13:21:34 | linuxstb | That's probably misleading - I don't think that function is on the to-do list. It probably won't be needed for colour LCDs. |
13:23:43 | Bger | B4gder could you see patch No 1378064 ? i think it's ok ... |
13:23:53 | Bger | (sokoban h300 updates) |
13:24:08 | B4gder | no time atm |
13:24:14 | Jungti1234 | hmm |
13:24:26 | Bger | okay :( |
13:25:13 | | Join webguest37 [0] (n=5087d10e@labb.contactor.se) |
13:25:28 | webguest37 | Febs: are you around ? |
13:25:57 | Jungti1234 | bad australian |
13:25:59 | webguest37 | uggh, should open my eyes and look right −−->> |
13:26:35 | webguest37 | however |
13:26:44 | Jungti1234 | Do they do racism yet? |
13:26:45 | mirak | B4gder: color is limited to 16bits ? |
13:26:50 | * | webguest37 does magical dance to summon Febs |
13:26:50 | B4gder | yes, atm |
13:29:29 | | Part webguest37 |
13:31:22 | saa[b_r]ider | custom H300 LCD colors :) http://www.misticriver.net/photos/albums/userpics/12162/Custom%20LCD%20colors.jpg |
13:31:49 | saa[b_r]ider | (this is an actual screendump, not from a simulator) |
13:32:57 | B4gder | I still wait for a background image and alfa blended text on top ;-) |
13:33:38 | preglow | ugh |
13:33:42 | preglow | crt0.S is becoming a royal mess |
13:34:12 | | Join mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk) |
13:34:36 | B4gder | how come? |
13:34:45 | mirak | B4gder: what is the reason to use 16bits instead of the 18 ? |
13:34:48 | preglow | well |
13:34:50 | preglow | some general arm code |
13:34:53 | preglow | some PP specific code |
13:34:57 | preglow | some code that only goes in the bootloader |
13:35:12 | B4gder | mirak: why use 18bits when most of the UI only uses two colors? |
13:35:42 | mirak | B4gder: why do you answer that ? |
13:35:43 | B4gder | apart from the apparent reason that of course 16bits is much faster than 18 |
13:35:49 | mirak | I want to to know what are the technical reasons |
13:35:51 | B4gder | mirak: ? |
13:35:57 | B4gder | no there aren't |
13:36:08 | mirak | ok |
13:36:16 | | Quit Bger ("Don't squeeze the BitchX") |
13:36:23 | mirak | so just changing the lcd depth would make it ? |
13:36:33 | B4gder | no |
13:36:41 | B4gder | you need to fix the code too |
13:37:04 | | Join Bger [0] (n=Bager@83.222.160.88) |
13:38:01 | B4gder | like most things in Rockbox it can be extended to become better if you just feel for it |
13:38:12 | B4gder | and have the skill |
13:44:14 | preglow | linuxstb: but ok, so far, i won't enable interrupts in bootloader |
13:45:28 | amiconn | I don't think 18 bit support for H300 would be wise, as 16bit is kinda slow already... |
13:45:34 | preglow | idneed |
13:45:51 | B4gder | only for some special mode if so |
13:45:59 | B4gder | like jpeg viewer mode or similar |
13:46:19 | amiconn | I'd rather want to avoid LCD mode switching |
13:46:24 | B4gder | if you happen to have a jpeg with only blue shades or something ;-) |
13:47:03 | B4gder | we have different "modes"already with the greyscale lib |
13:47:45 | B4gder | but I don't think of 18bit as particularly important |
13:48:07 | amiconn | The grayscale lib doesn't switch the LCD mode, it works on top of that |
13:48:25 | B4gder | yes, but it is a different graphic mode |
13:49:12 | mirak | #define _RGBPACK(r, g, b) ( ((((r) * 31 + 127) / 255) << 11) \ |
13:49:23 | mirak | wouldn't it be faster to just use shifts ? |
13:49:50 | mirak | plus mask and a or to mix all colors |
13:49:53 | mirak | a mask |
13:50:40 | amiconn | mirak: Shifts are imprecise |
13:50:49 | mirak | amiconn: what do you mean ? |
13:50:54 | amiconn | Plus, this #define is evaluated at build time |
13:50:57 | preglow | hmmm |
13:50:58 | preglow | what the hell |
13:51:00 | preglow | how can this work |
13:51:08 | preglow | ahh, right, forget me |
13:51:41 | amiconn | mirak: I mean that the conversion between bit depths can't be done with shifts only. It wouldn't be precise |
13:52:02 | mirak | amiconn: explain that |
13:52:10 | mirak | please :) |
13:52:13 | preglow | linuxstb: for consistency, we might want to have the bootloader remap memory as well, but i don't know how the apple firmware, or even linux, will take to suddenly run at address 0x0 |
13:52:49 | mirak | amiconn: the color passed to the argument are between 0 and 255 ? |
13:52:55 | amiconn | yes |
13:53:25 | mirak | ok te method try to rescale to a 5bits ? |
13:53:27 | mirak | for exemple |
13:53:59 | mirak | amiconn: ? |
13:54:14 | mirak | a 5 bits intervals for red and blue |
13:55:17 | mirak | chunking just the low bits should do it for me |
13:55:35 | linuxstb | preglow: Are you saying you map the DRAM to address 0x0 ? |
13:55:46 | preglow | yep |
13:56:07 | linuxstb | Mmm. That will make rolo-ing the Apple firmware or Linux tricky. |
13:56:13 | preglow | why? |
13:56:15 | linuxstb | Unless it's easy to map it back. |
13:56:16 | preglow | ahh |
13:56:18 | preglow | it is |
13:56:22 | preglow | that is |
13:56:24 | preglow | i have no idea how |
13:56:27 | linuxstb | :) |
13:56:33 | preglow | or rather, how, but not what to write |
13:56:45 | linuxstb | I assume the IRAM stays where it is? |
13:56:48 | preglow | it's just a couple of registers |
13:56:50 | preglow | iram stays |
13:56:52 | preglow | everything stays |
13:56:58 | preglow | but sdram, and flash, obviously |
13:57:01 | preglow | which we can't access after this |
13:58:09 | linuxstb | But I assume that the rolo function (which is in iram already) can change it? |
13:58:39 | linuxstb | Or the bootloader could change it back before executing Linux or the Apple firmware? |
13:59:48 | preglow | sure, just need to find out how |
14:00 |
14:00:09 | preglow | this is the same way of doing things ipl does |
14:00:17 | preglow | there is another mecanism for pp5020, it seems |
14:00:22 | preglow | but not for pp5002 |
14:00:31 | preglow | and this way is consistent with how other arms do it |
14:00:36 | preglow | so we can share some code |
14:00:59 | linuxstb | I am happy to forget about the pp5002 for now - a lucky owner of such a device can solve those problems. |
14:01:11 | mirak | amiconn: wouldn't this be enough ? (((r) >> 3 ) << 11 ) & (((g) >> 2 ) << 5 ) & ((b) >> 3 ) |
14:01:38 | preglow | linuxstb: well, now at least this part is working |
14:01:46 | preglow | linuxstb: and besides, i never could get the other method to work |
14:01:57 | preglow | linuxstb: ipl people haven't researched it too much, since they don't use it |
14:02:17 | mirak | I mean if the color is from 0 to 255 on 8 bits, if you want to reduce to 6 or 5 bits, you are forced to lose precision in the color. |
14:02:22 | linuxstb | mirak: As amiconn said, the shifts are inprecise - they always round down |
14:02:55 | mirak | linuxstb: ok I see |
14:03:01 | preglow | arghhh |
14:03:04 | preglow | now it doesn't work anymore :/( |
14:03:09 | linuxstb | And it's a macro that's designed to be use at compile-time, so the speed doesn't matter. |
14:03:17 | mirak | linuxstb: I wasn't figuring the rounding down |
14:03:39 | Bger | hm, guys, anything other than unix2dos and dos2unix ? |
14:03:51 | linuxstb | iconv or recode |
14:04:03 | linuxstb | (I'm not sure about iconv....) |
14:04:16 | linuxstb | (in fact, forget i mentioned it...) |
14:05:07 | Bger | 10x :) |
14:05:07 | B4gder | Bger: to do what? |
14:05:15 | Bger | just to ask you about iconv ... |
14:05:16 | preglow | ahah |
14:05:25 | preglow | i just built a rockbox that rebooted on start |
14:05:38 | Bger | B4gder i want to convert one patch from dos to unix eol format |
14:07:15 | * | B4gder uses tr for that |
14:09:00 | Bger | hm, good idea |
14:09:41 | B4gder | I actually have a perl script too, but that's mostly for windows-versions of diff that produces the drive letter and backward slashes in the diff -u output |
14:10:10 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
14:10:13 | | Join muesli- [0] (n=muesli_t@141.71.4.218) |
14:10:20 | | Quit linuxstb (Nick collision from services.) |
14:10:29 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
14:10:34 | Bger | aha:) |
14:10:34 | XavierGr | GOD!!!!! I am gonna rip my hairs out!!!! |
14:10:56 | Bger | this snow.c patch is awful ... |
14:11:02 | XavierGr | I can't make the pointers work |
14:11:44 | | Join dropandho [0] (n=dropandh@cpe-24-193-36-91.nyc.res.rr.com) |
14:12:01 | dropandho | hey all |
14:12:08 | dropandho | any news regarding the forums? |
14:12:20 | B4gder | Jeff is not here |
14:12:37 | dropandho | got it |
14:12:46 | dropandho | there have been some attempts to reach out to him |
14:12:53 | dropandho | so i was hoping something came of that |
14:13:02 | XavierGr | I have 2 char* pointers how can the one pointer the other? Or one of 2 must be **pt? |
14:13:04 | B4gder | not to my knowledge |
14:13:32 | B4gder | XavierGr: I don't understand the question |
14:13:32 | dropandho | darn |
14:14:39 | Bger | XavierGr if you have char *pt1,*pt2; |
14:14:53 | Bger | then u just make pt2=pt1; and it's done |
14:16:25 | preglow | hahaha |
14:16:39 | preglow | now, why did i disable backup files in vim... |
14:16:41 | XavierGr | I will describe it better. I have 2 buffers. 1) The first holds all the strings (char *names) 2) (Let's name that str_pt) The second has the places where each string starts in "names". I want every time names get another element to be pointed by str_pt. |
14:17:10 | XavierGr | preglow: dont tell me? |
14:17:30 | XavierGr | you lost your work? |
14:17:37 | preglow | nah |
14:17:39 | preglow | just a tiny bit |
14:17:44 | preglow | will be back in a jiffy |
14:17:47 | Bger | XavierGr so you need an array of pointers to char iiuc |
14:18:10 | XavierGr | yes |
14:18:23 | Bger | like char *str_pt[MAX_NAMES]; |
14:18:40 | Bger | str_pt[i]=names[j] etc ... |
14:19:01 | XavierGr | no because I can't be sure how many I will have |
14:19:16 | XavierGr | so I use a buffer for that too |
14:19:52 | B4gder | you need a max value anyway |
14:19:52 | | Join DjDeaf [0] (i=DjDeaf@87.68.156.125.cable.012.net.il) |
14:20:24 | DjDeaf | hello |
14:20:30 | Bger | XavierGr : as u already know, rb doesn't have dynamic memory allocation |
14:20:40 | XavierGr | Bagder: Yes but at least I will get that value during runtime. |
14:20:44 | Bger | so, whether u want or not, u must assume some limit |
14:21:04 | XavierGr | The limit comes when the code is running |
14:21:13 | DjDeaf | hi i have a problem can abyone help me? |
14:21:22 | Bger | DjDeaf just ask |
14:21:30 | DjDeaf | ive installed rockbox |
14:21:36 | DjDeaf | on h340 |
14:21:41 | Bger | noone can help you if (s)he doesn't know what's the problem |
14:21:42 | XavierGr | but let me think it over again. |
14:21:55 | DjDeaf | and when im accessing the menu |
14:22:08 | DjDeaf | i cant see it , the text is blank |
14:22:09 | Bger | XavierGr if the limit comes runtime, then u want dynamic memory alloc. .. |
14:22:24 | Bger | DjDeaf any language ? |
14:22:26 | Bger | set |
14:22:31 | Bger | different from english ? |
14:22:36 | Bger | or any font set ? |
14:22:40 | DjDeaf | maybe i didnt notice |
14:22:45 | DjDeaf | its in the originalk theme |
14:22:52 | Bger | hm |
14:23:14 | preglow | ok, commited exceptions |
14:23:16 | Bger | i suggest u to stop and start the unit and hold the "rec" button while it's booting |
14:23:35 | Bger | but not too early, otherwise u'll start the iriver fw |
14:23:40 | | Quit dropandho () |
14:23:51 | DjDeaf | ok i did it |
14:24:00 | Bger | B4gder am i right in using tr -d "\r" < dos_formatted_file > unix_formatted_file |
14:24:07 | DjDeaf | oh here, it works |
14:24:12 | DjDeaf | thanks :) |
14:24:26 | Bger | DjDeaf np ... this resets all settings, it was added recently |
14:24:36 | DjDeaf | and another tiny question, it there video on images option on rockbox? |
14:24:42 | DjDeaf | or |
14:24:50 | Bger | video : not |
14:25:19 | Bger | images also, but they will come in a more short period |
14:25:49 | XavierGr | Bger: Excuse me but when I run a plugin I have a big chunk of memory available to do anything I like. Maybe it is called dynamic memory allocation, but anyway rockbox lets me to do anything I like with that left memory in the end. |
14:26:16 | Bger | XavierGr it has statical limit, so it's statical |
14:26:40 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
14:26:45 | | Quit linuxstb (Nick collision from services.) |
14:26:48 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
14:26:54 | XavierGr | statical? |
14:26:59 | preglow | linuxstb: care to test what's in cvs now? |
14:27:05 | linuxstb | XavierGr: you could store your strings starting from the start of the buffer, and the array can work back from the end. |
14:27:11 | Bger | u can use all this memory to make an array and after that use this array in the way u want |
14:27:22 | preglow | here filebrowser starts, but then just stands there looking silly |
14:27:36 | Bger | yep, something like the linuxstb's note |
14:27:43 | linuxstb | preglow: Hasn't it always done that? :) |
14:27:44 | preglow | but then again, i've got some further changes |
14:27:58 | preglow | linuxstb: perhaps, i've forgotten how it behaves in cvs, heh |
14:28:32 | XavierGr | guys I think I fixed what I wanted, one of the char pointers had to be char **str_pt |
14:28:35 | preglow | linuxstb: but anywho, as long as it doesn't lock up |
14:28:48 | linuxstb | preglow: I'm testing now. |
14:28:48 | Bger | XavierGr ... i don't think so |
14:28:50 | XavierGr | It is just annoying that I haven;t clearly understand how pointers work. |
14:28:55 | Bger | do u initialize the pointers ? |
14:29:10 | Bger | see, before you use any pointer, u must initialize it |
14:29:21 | XavierGr | yes |
14:29:32 | Bger | so, how do u initialize it ? |
14:29:54 | XavierGr | these pointers get always a start address from the end memory of plugin buffer. |
14:30:06 | Bger | char **str_pt; means pointer to pointer to char |
14:30:12 | XavierGr | (different according to my use) |
14:30:22 | XavierGr | yes |
14:30:26 | Bger | so u must assign something to str_pt |
14:30:32 | XavierGr | that's what I wanted after all, it is just that I am not sure about it. |
14:30:52 | mirak | linuxstb: ok, I will insist a bit ^^. For me the precision doesn't matter. What the actual thing is doing is considering that the colors below and above in fixed interval can be assimilated to that color. But in reality the colors truncated with a right shift are considered to be a subset of a base color. For exemple with what you are doing with 6 bits for a taint, the color 0 have a subset of colors of 2 colors {000 001 |
14:30:52 | mirak | } while the color 100 have a subset of {010,011,100,101} |
14:30:56 | Bger | i mean, str_pt must point to free memory |
14:31:00 | XavierGr | yes I assign a position from the other buffer |
14:31:11 | Bger | ok |
14:31:53 | XavierGr | I must read a very good tutorial about pointers which covers all strange situations. |
14:31:54 | mirak | truncation is the way to go for colors |
14:33:16 | mirak | imho. It was this approach wich was used on Atari ste when they extended the color range |
14:33:17 | linuxstb | preglow: Your CVS changes make no difference to how Rockbox behaves :). Which is a success I think. |
14:33:36 | Bger | XavierGr : really, it's simple |
14:33:37 | preglow | linuxstb: indeed, then i shall queue forth a new set of changes |
14:33:48 | preglow | linuxstb: btw, what to do about the yield issue? :/ |
14:33:55 | mirak | linuxstb: very intersting ;D |
14:34:05 | Bger | u just must know that the pointer is a var that points to other var |
14:34:14 | | Join amar [0] (n=502c706b@labb.contactor.se) |
14:34:31 | Bger | and u must give the pointer a valid address |
14:35:41 | XavierGr | Bger: I know that, but sometimes I get confused by the indirection. |
14:36:28 | Bger | then u just need more practice |
14:36:29 | Bger | ;) |
14:36:41 | mirak | 0,8 should be considered as 0 and not 1 for the same reason that the color 255 will not be rounded up, because it's just impossible to go above 255. |
14:36:43 | linuxstb | mirak: I don't really have any views about that macro - amiconn wrote it. But I think it may have something to do with making the reverse operation possible (i.e. rgb565 to rgb888). If you do the reverse operation by simply shifting, then you don't get pure white any more. |
14:37:29 | linuxstb | But as I say, I'm not the person you should be talking to. |
14:39:24 | mirak | linuxstb: that's the inevitable boundary effect |
14:39:33 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-129-115.pools.arcor-ip.net) |
14:40:02 | | Join Mmmm [0] (n=54433cd7@labb.contactor.se) |
14:40:05 | mirak | do you know how the screen manage colros internaly ? |
14:40:20 | mirak | does it use one byte per colors, or is packed ? |
14:40:38 | mirak | to save bits |
14:41:07 | | Quit Mmmm (Client Quit) |
14:41:11 | B4gder | it is packed |
14:41:19 | B4gder | the framebuffer uses lcd native format |
14:41:48 | | Join Mmmm [0] (n=54433cd7@labb.contactor.se) |
14:41:51 | B4gder | afaik |
14:42:02 | mirak | B4gder: ok so you can control the depth of the lcd screen ? |
14:42:10 | B4gder | ? |
14:42:25 | | Quit Mmmm (Client Quit) |
14:42:43 | mirak | the screen uses 18 bits colors, rockbox 16 bits, something doesn't match :) |
14:42:55 | B4gder | the LCD is programmable |
14:43:00 | | Part Sando |
14:43:02 | B4gder | rockbox sets it in 16bit mode |
14:43:05 | B4gder | voila |
14:43:09 | | Join Sando [0] (n=lolsteam@techgaming.net) |
14:43:12 | mirak | ok thank you |
14:43:22 | mirak | B4gder: is there some docs about that ? |
14:43:31 | B4gder | the source code and the lcd datasheet |
14:44:52 | mirak | this reminds me my atari days, where programming was very close from the hardware |
14:45:26 | * | B4gder never left that :-) |
14:45:29 | linuxstb | mirak: I believe the LCD controller uses 18bpp internally, but it can work in a 16bpp where the missing two bits are just set to (I think) 1. |
14:45:45 | linuxstb | (i.e. the least significant red and blue bits) |
14:45:58 | linuxstb | As B4gder said, the lcd datasheet describes it. |
14:46:13 | mirak | k |
14:46:22 | | Quit San||Away (Read error: 104 (Connection reset by peer)) |
14:47:09 | XavierGr | Are we sure that iriver uses 18 bit colors? |
14:47:17 | XavierGr | maybe they use 16 too. :D |
14:47:19 | mirak | how was it possible to find wich system adress were coresponding to this or that device ? |
14:47:37 | XavierGr | Who can tell? |
14:47:44 | B4gder | XavierGr: we're not sure no, I doubt anyone cares enough to figure it out |
14:47:56 | B4gder | mirak: hard work |
14:48:26 | XavierGr | Then they say that their product shows 18bit colours so.... it could get them into trouble if not. |
14:48:28 | mirak | XavierGr: yep, anyway since the screen resolution is around 5 times less than traditional screens resolution with a 24 bits depth, I don't think that any image converted to that resolution can display that much color nuances |
14:48:59 | mirak | so yes 16bits colors is not much of loss probably |
14:49:12 | B4gder | I think you should be able to tell |
14:49:17 | linuxstb | Anyone heard anything more from the person working on the iFP790 port? He doesn't seem to have updated the wiki or his website since his initial announcement. |
14:49:20 | B4gder | if you make a pic with a gradient blue only |
14:50:37 | XavierGr | I will make the same discussion then: Does human eye has a measurable colour range? |
14:51:09 | XavierGr | (The range is known, I think) |
14:51:17 | XavierGr | but how manu increments? |
14:51:26 | g33 | i have a suggestion for filebrowsing... dunno how easy it is to implement though.. |
14:51:38 | mirak | XavierGr: that's subjective and depend of persons |
14:52:02 | mirak | XavierGr: there is probably a physiological limit |
14:52:05 | preglow | B4gder: just doing MY_ADDR; on a volatile address will read it, yes? |
14:52:26 | XavierGr | mirak: yes that's what I am talking about. |
14:52:50 | linuxstb | preglow: Yes - look at how current_tick is defined and used. |
14:53:10 | mirak | XavierGr: I think 24 bits is below that limit, but enough |
14:53:10 | XavierGr | Is there any plan to use 64bits for displays? |
14:53:15 | mirak | lol |
14:53:26 | preglow | ok, here comes timer |
14:53:30 | g33 | you know sometimes the idiot who ripped an album put the artist name and album name in the file name, so when you list the files in a folder all you see is 15 "eric clapton - from the cra.." and have to wait and scroll every file to find the right song |
14:53:30 | preglow | linuxstb: please test |
14:53:34 | linuxstb | Sure. |
14:54:02 | mirak | g33: I have seen idiots that put album and artist into the artist id3 tag |
14:54:45 | g33 | man i should spend one day and just sort out all my mp3s |
14:54:54 | mirak | g33: I have done that |
14:55:16 | g33 | maybe i can pay some polish kid to do it for me! :D |
14:55:29 | mirak | at the begining I was puting artist - album - track - title in the name, because it was easier for P2P |
14:55:38 | linuxstb | g33: There are tools to have retag and rename MP3s |
14:55:44 | linuxstb | s/have/help/ |
14:55:53 | g33 | yeah but i dont always trust em automatic tools |
14:55:54 | mirak | I use easytag on linux |
14:56:00 | g33 | im not on linux |
14:56:04 | mirak | g33: that's semy manual |
14:56:09 | g33 | im l33t so i use xp home :) |
14:56:30 | mirak | I have seen that some uses musical signatures to identify songs |
14:57:00 | mirak | it means that two mp3 encoded with different bitrates by different persons can have the same signature |
14:57:05 | linuxstb | preglow: That's perfect - the backlight now fades. |
14:57:15 | mirak | even if they don't match bit for bit |
14:57:20 | preglow | ok, button driver next! |
14:58:51 | markun | g33: with 'mmv' you can rename files very easy under linux. |
14:59:06 | g33 | [13:56] <g33> im l33t so i use xp home :) |
14:59:08 | markun | Ah, NOT on linux :) |
15:00 |
15:00:02 | g33 | im learning c++.. maybe one day ill write my own tool.. |
15:00:11 | g33 | eta 2009 :P |
15:00:42 | | Join webguest11 [0] (n=5087d10e@labb.contactor.se) |
15:06:10 | | Part webguest11 |
15:06:28 | Cassandra | I had a look at the button code in ipodlinux. It looked kind of scary. |
15:06:35 | Cassandra | And interupt driven. |
15:06:53 | preglow | yeah, it did |
15:07:06 | preglow | but i'm going to have a crack at it now, or so help me god! |
15:07:12 | preglow | i like being melodramatic |
15:07:15 | Cassandra | Good luck with that. |
15:07:28 | preglow | at least we have interrupts now |
15:07:29 | Cassandra | I kind of got distracted by the Secret Project. |
15:07:31 | preglow | which isn't a bad start |
15:07:47 | preglow | the wha? |
15:07:54 | Cassandra | The bear bones of which is now implemented. It's looking good. I may have a first release in a few days. |
15:08:20 | Cassandra | It's a wxWidgets program. |
15:08:26 | Cassandra | Erm, "bare" bones. |
15:08:31 | preglow | hahaha |
15:08:39 | preglow | it'd be cooler if it contained bear bones |
15:09:02 | preglow | wasn't it you who was going to implement the sims with wxwidgets? |
15:09:42 | Cassandra | Someone suggested it was, that, but no. |
15:10:04 | Cassandra | Although that might be an interesting project at some point. |
15:10:17 | Cassandra | However, I regard the sim as low priority. |
15:10:27 | g33 | hey how about making the iriver to a digital soundcard? you connect the iriver to computer with usb, and then it works as a usb soundcard and you can use the digital output from the computer? :D |
15:10:38 | preglow | yup, but i think using something like sdl would be wiser for that |
15:10:43 | preglow | we don't exactly need widgets for sims |
15:11:22 | preglow | but that would be a cool project |
15:11:22 | Cassandra | g33: Can't be done, I'm afraid. All the computer sees is a disk. |
15:11:34 | preglow | would eliminate the need for multiple targets, and would probably result in a better simulator |
15:11:50 | Cassandra | preglow, on the other hand it would mean polluting the sim with C++. |
15:11:55 | preglow | Cassandra: oh? |
15:12:01 | preglow | sdl is c |
15:12:10 | Cassandra | wxW is C++, sadly. |
15:12:18 | preglow | ahh, yes |
15:12:19 | preglow | that it is |
15:12:21 | preglow | but again |
15:12:24 | preglow | sdl would be better |
15:12:25 | g33 | ohwell.. usb sound card is only $20 anways |
15:12:27 | preglow | since it's got sound drivers as well |
15:12:32 | Cassandra | Part of whats been taking time on this project has been learning C++. |
15:13:05 | Cassandra | Sounds like a more sensible choice, yes. |
15:13:16 | | Join PaulJ [0] (n=PaulJ@vpn-3177.gwdg.de) |
15:13:45 | *** | Saving seen data "./dancer.seen" |
15:14:11 | mirak | amiconn: are you around ? |
15:14:16 | | Quit Jungti1234 ("bye") |
15:16:12 | | Join tucoz [0] (n=martin@hornved.ii.uib.no) |
15:16:31 | tucoz | Cassandra, are you here? |
15:17:04 | | Join LinusN [0] (n=linus@labb.contactor.se) |
15:17:57 | preglow | linuxstb: btw, did you try the new ipl bootloader? |
15:18:08 | XavierGr | I will be damned now sorting 850 files droped to 68 ticks |
15:18:10 | | Join Febs [0] (i=Febs@dhcp64-134-210-83.hfwsf.sjc.wayport.net) |
15:18:20 | XavierGr | Previous was 618 ticks for the same list! |
15:18:24 | XavierGr | Incredible |
15:18:56 | XavierGr | Now I have a killer jpeg viewer, optimised as hell. |
15:19:02 | LinusN | nice |
15:19:24 | XavierGr | I think 1 second for 850 files is a good deal. |
15:19:35 | * | preglow points to the dct functions, which are surprisingly asm free, just to spoil the fun |
15:19:49 | B4gder | XavierGr: and it does color on h3x0 ? B-] |
15:19:50 | mirak | XavierGr: can we see that ? |
15:20:31 | XavierGr | Bagder: Unfortunately I am too idiot to understand the jpeg code to do that. |
15:20:44 | * | LinusN drops the dct functions in preglow's lap |
15:20:51 | linuxstb | preglow: No, it needs yet another version of gcc installing. |
15:21:01 | XavierGr | mirak: Of course I will put some more memory failsafe code and I will upload it to the tracker. |
15:21:23 | preglow | linuxstb: eh? |
15:21:24 | Cassandra | tucoz, hello, yes. |
15:21:32 | * | preglow looks at the viper in his lap with disgust |
15:21:52 | tucoz | Cassandra, if you find some time. Would you like to have a look at the latex docs? It is organized like the 2.4 docs atm. |
15:22:35 | Cassandra | OK. |
15:22:47 | Cassandra | Not sure when I'll have time though. |
15:23:45 | tucoz | Cassandra, not that this is looking that good. It is only the writer2latex output, that I split into chapter files and made compilable :) http://www.student.uib.no/~st08541/rockbox/rockbox.pdf |
15:24:35 | preglow | linuxstb: do you have any idea why the ipl button code for 4g and up seems to use both the mini and 4g interrupts? |
15:25:09 | * | Bger spots an old code in playlist_viewer.c |
15:25:14 | linuxstb | I think the "mini" interrupt is needed for the hold switch |
15:25:58 | linuxstb | And forget what I said about needing a different compiler for the new ipl bootloader - I was thinking about podzilla2 |
15:26:24 | preglow | why the hell would one need a different compiler for compiling a program? |
15:26:24 | linuxstb | That needs an arm-uclinux- toolchain and libraries |
15:27:10 | tucoz | Cassandra, this zip includes the LaTex build system. It should be quite easy to make it look prettier from here. Make the chapters (parts) more organized. The file structure is what is important right now I think. http://www.student.uib.no/~st08541/rockbox/manual.zip |
15:27:11 | | Quit VikraMarkA_ ("Leaving") |
15:27:31 | preglow | okiedoke |
15:27:34 | preglow | time for food |
15:27:34 | Cassandra | tucoz: I've had a quick look, and it looks like a very good start. You seem to be missing the appendices and introductory blurb. |
15:27:58 | tucoz | Cassandra, yes, but the files are there |
15:28:29 | Cassandra | Cool. Just having a peek inside the archive now. |
15:28:37 | tucoz | I didn't bother to make the appendeces compile, but the text is there in appendix.tex |
15:29:14 | tucoz | Cassandra, I think some of the text needs some attention as well, as some features have changed since 2.4. |
15:29:23 | Cassandra | How clean is the generated code? |
15:29:35 | tucoz | Cassandra, and of course the tables. The generated code looks like **** |
15:29:48 | Cassandra | tucoz: Yeah, it needs a lot of attention in fact. |
15:29:57 | tucoz | And I generated it with the -clean flag |
15:30:08 | Cassandra | *nod* very sensible. |
15:30:09 | tucoz | the generated docs is here http://www.student.uib.no/~st08541/rockbox/rockbox-manual-2.4.zip |
15:30:28 | Cassandra | For a first shot, I think it looks better than I'd have expected. |
15:30:59 | tucoz | Yes, me too. But as you see, e.g. the tables need some major work. |
15:31:28 | tucoz | But, it should serve as a starter at least. |
15:32:52 | mirak | linuxstb: just a question, what would be the point of converting from 16 to 24 ? |
15:32:52 | preglow | i think it should do nicely for a starter |
15:33:22 | Cassandra | Code is nice and clean too. |
15:33:30 | | Join perplexity [0] (n=joust@217.165.110.88) |
15:33:30 | tucoz | (and of course fix the references, as I didn't fix all of them) |
15:33:31 | linuxstb | mirak: There probably isn't any point any more - but the first colour version of the Simulator worked in 24-bit |
15:33:31 | B4gder | mirak: for screendumps for example |
15:33:35 | Cassandra | I think that's a very good starting point, tucoz. |
15:33:41 | tucoz | Cassandra, :) nice |
15:33:44 | linuxstb | B4gder: The screendump also uses rgb565 |
15:33:44 | mirak | ok |
15:33:55 | B4gder | bmps can do 565? |
15:33:59 | linuxstb | Yep. |
15:34:02 | B4gder | ok |
15:34:06 | linuxstb | We write a 16-bit bitmap. |
15:34:09 | * | B4gder learned something |
15:34:31 | mirak | linuxstb: I was reading the datasheets and it seems you can pass directly 18bits and it does the conversion in hardware on the lcd side |
15:34:46 | mirak | from 18 to 16 bits |
15:34:53 | tucoz | Cassandra, ok, now you know where they are. I don't think I work on that before we could send changes as patches. |
15:35:02 | Febs | tucoz, FYI, everything in the WikiManual (at least everything that I wrote) started from version 2.4 of the manual if it existed there in the first place. |
15:35:10 | linuxstb | mirak: I thought it was the other way around - you write 16-bits and the hardware converts it to 18-bits. |
15:35:12 | B4gder | mirak: why would you want to do that? |
15:35:55 | mirak | linuxstb: it can do that too, wait a minute :) |
15:35:58 | tucoz | Febs: good. I think the wiki will serve as a good source of copy and paste for now :) |
15:36:26 | mirak | B4gder: to not to do the conversion in software mode |
15:36:27 | Febs | Great. That was always my intention as I updated the 2.4 sections and put them in the WikiManual. |
15:36:42 | linuxstb | mirak: What are you trying to achieve? Do you want to make the h300 lcd work in 18-bit mode? |
15:36:44 | B4gder | mirak: you'd have to write a lot more data, which is bad |
15:36:49 | Febs | I need to get LaTex installed on my computer so that I can see what you've done. |
15:37:06 | tucoz | Febs, you could look at the pdf? |
15:37:20 | Febs | Link? |
15:37:27 | tucoz | http://www.student.uib.no/~st08541/rockbox/rockbox.pdf |
15:38:06 | mirak | B4gder: yep |
15:38:09 | tucoz | Febs, that is mostly generated code from the writer2latex command, which I have cleaned up and made to compile. |
15:38:34 | mirak | linuxstb: no not really, I am figure out how it works globally, so sometime I fix on some details |
15:39:18 | mirak | maybe there is some docs about rockbox interfaces ? |
15:39:42 | B4gder | mirak: nope, none that are any recent |
15:39:53 | linuxstb | There's a good "graphics API" wiki page that amiconn keeps up to date. |
15:39:58 | B4gder | true |
15:39:58 | tucoz | Febs, you can find the other sources in that directory. That is, the writer2latex output (which won't compile) and the latex sources. |
15:40:04 | mirak | LinusN: ok I will read that |
15:40:36 | Febs | tucoz, looks like a great start. |
15:41:15 | tucoz | Febs, at least under the hood :) |
15:41:58 | Febs | Hey, you must start somewhere! |
15:42:47 | tucoz | yes, that is true. Now to agree on what to put in cvs, and start merging the docs from the wiki with this. |
15:42:49 | * | Febs is now installing XEmTeX. |
15:43:02 | tucoz | Febs, are you using windows? |
15:43:06 | Febs | Yes. |
15:43:24 | tucoz | Ok, is that a good LaTeX system? |
15:43:29 | | Quit muesli- ("ich will Kühe!!!") |
15:43:36 | mirak | I guess it's possible to call the file browser from an application ? |
15:43:50 | Lynx_ | just got my h340! |
15:43:56 | mirak | dman that's not easy |
15:43:59 | mirak | damn |
15:44:11 | tucoz | I have only used MiKTex under windows |
15:44:15 | Febs | tucoz, having never used any LaTeX system, I have no basis for comparison. |
15:44:27 | tucoz | Ok, probably good enough |
15:47:15 | | Join webguest27 [0] (n=c13354c1@labb.contactor.se) |
15:47:19 | Lynx_ | argh, why in the world would they put a paper sticker on the display that tears on removal |
15:47:47 | saa[b_r]ider | Lynx: wow, the one with the pixeled dancers on it? |
15:48:34 | * | webguest27 thanks every develloper here for all the Rockbox works !!! |
15:48:36 | mirak | extensions are usable on the simulator ? |
15:48:39 | Lynx_ | saa[b_r]ider: yes |
15:49:09 | saa[b_r]ider | you're a bit late to the party :D |
15:49:29 | mirak | invalid ELF header |
15:49:35 | mirak | when I try to run an extension |
15:49:40 | webguest27 | anyone here now if we can replace the doble plater 40go HD of h140 by a 80 go one? |
15:49:42 | Lynx_ | hmm, it seems i didn't get any remote with it :( |
15:49:54 | saa[b_r]ider | lynx: is this your first DAP, or did you have another one before it? |
15:50:05 | webguest27 | seems Toshiba made 80 doble plater HD now |
15:50:10 | Lynx_ | saa[b_r]ider: had an archos until last week |
15:50:27 | saa[b_r]ider | (the LCD remote is optional, only comes with the non-LCD one) |
15:50:41 | webguest27 | iHP- 180, that would be the best music device : |
15:50:43 | Lynx_ | saa[b_r]ider: it didn't come with any remote |
15:50:52 | webguest27 | :] |
15:50:56 | Lynx_ | saa[b_r]ider: unless i haven't found i yet. but it's not listed on the box |
15:51:13 | webguest27 | anyone know?, please |
15:51:14 | saa[b_r]ider | webguest: they announced it a while ago, but afaik it's still not available |
15:51:48 | webguest27 | but when it will be possible to by, will it be compatible with h140 one? |
15:52:15 | saa[b_r]ider | lynx: to be honest, I never used that remote. I only connected it cause the the standard headphones are short |
15:52:15 | webguest27 | I love my hp140 and don't want to change it |
15:52:22 | linuxstb | mirak: Are you trying to use a plugin compiled for the target on the simulator? You need to use the simulator versions - they are installed when you do a "make install" in your simulator build directory. |
15:53:13 | Lynx_ | saa[b_r]ider: a remote was the only thing i was missing on the archos. i thought there would be one with this iriver because you told me some time ago, but they seemed to have changed this. |
15:53:22 | | Join tvelocity [0] (n=tony@84.254.13.74) |
15:53:27 | saa[b_r]ider | webguest: check the MR forums, or check the specs on toshiba's site. techincaly, it should fit if the dimentions in the specs are correct |
15:53:56 | webguest27 | but I heard 2 differents size for it |
15:54:33 | webguest27 | and don't know wich is a good one :( |
15:55:16 | saa[b_r]ider | lynx: well my H340 came with it... but changes did happen. my H340 came with the non-windowed case. newer H340s came with the windowed case (which I had to buy my self, together with the LCD remote) |
15:55:34 | Lynx_ | saa[b_r]ider: ok, i have a newer one then |
15:55:49 | linuxstb | webguest27: The h140 has a Toshiba MK4004GAH - I am sure you can find the dimensions of that drive on the web and compare it with the one you want to buy. |
15:55:53 | saa[b_r]ider | webguest: beleive me, a lot of people are waiting for it... including me |
15:56:31 | webguest27 | linuxstb: afaike isn't the iriver size problem, but the 80go HD one |
15:56:43 | mirak | linuxstb: yes I am dumb |
15:56:45 | mirak | lol |
15:56:50 | saa[b_r]ider | lynx: you got the windowed case? |
15:56:52 | webguest27 | :) |
15:57:00 | Lynx_ | saa[b_r]ider: yes |
15:57:30 | Lynx_ | saa[b_r]ider: maybe i can buy the non-lcd remote off someone who has it and does not need it like you |
15:57:31 | Bger | saa[b_r]ider btw if you're using the h300 lcd remote, i've updated the button patch |
15:57:36 | webguest27 | saa[b_r]ider: you want it too :), did you see if we can upgrade or no yet? |
15:58:18 | saa[b_r]ider | I would suggest that you get a t-dimention skin, or rock.. I forget the name, always confused me with rockbox |
15:58:37 | saa[b_r]ider | Bger: the button.diff patch? |
15:58:42 | Bger | yes, the same |
15:58:43 | mirak | saa[b_r]ider: I have the windowed case, it's a bit large |
15:59:18 | Bger | now the remote behaves much more like the buttons on the main unit |
15:59:30 | webguest27 | saa[b_r]ider: but apparently Toshiba said 2 differents size for the same product, and I don't know which one is good :( |
15:59:47 | saa[b_r]ider | webguest: it's not out yet, so I still don't know. we'll have to wait :) |
16:00 |
16:00:36 | webguest27 | ok thanks for help me a bit |
16:00:42 | webguest27 | I'll wait |
16:00:49 | webguest27 | in hoping it will fit |
16:00:57 | webguest27 | 80go O.O |
16:01:06 | saa[b_r]ider | bger: yesterday I used the remote_type.patch, to scroll through menus you have to use right and left. |
16:01:23 | Bger | saa[b_r]ider yes, i know |
16:01:29 | saa[b_r]ider | when I tried to patch using button.diff I think nothing happened |
16:01:47 | Bger | hm, see, u can't use the 2 patches at the same time |
16:01:48 | saa[b_r]ider | so how does the new patch work? |
16:01:51 | Bger | do u have 2 remotes ? |
16:01:55 | webguest27 | ciao everyone |
16:02:02 | | Quit webguest27 ("CGI:IRC") |
16:02:07 | saa[b_r]ider | I didn't use them at the same time |
16:02:11 | saa[b_r]ider | compiled twice |
16:02:16 | Bger | i mean, h100's one and h300's one |
16:02:24 | saa[b_r]ider | nope, only the H300 |
16:02:39 | Bger | then u don't need to change settings |
16:03:30 | saa[b_r]ider | so if I patched a new build with button.diff, how are the buttons now? |
16:03:34 | Bger | with the new version u scroll with up/down |
16:03:38 | saa[b_r]ider | nice |
16:03:45 | Bger | and enter with left/right |
16:03:52 | Bger | in menus, in browser ... |
16:03:55 | saa[b_r]ider | what about the +10 and -10? |
16:04:02 | Bger | page up/page down |
16:04:04 | mirak | is there a way to slow down the simulator ? |
16:04:10 | mirak | plugins display nothing |
16:04:10 | saa[b_r]ider | cooool! |
16:04:13 | mirak | or to fast |
16:04:26 | Bger | mirak put a sleep :) |
16:04:43 | linuxstb | mirak: Which sim are you using? |
16:04:56 | linuxstb | (i.e. x11 or win32) |
16:05:00 | mirak | X |
16:05:02 | mirak | 11 |
16:05:06 | Bger | *exit/enter with left/right* |
16:05:07 | linuxstb | For the h300? |
16:05:10 | mirak | yes |
16:05:18 | linuxstb | That doesn't work... |
16:05:25 | linuxstb | No-one has added colour support to the x11 sim yet. |
16:05:35 | mirak | ok |
16:05:46 | saa[b_r]ider | Bger: I think I'll have a go at it today. last night I changed the colors in lcd.h, but they still need tweaking |
16:05:48 | mirak | the cube displays something |
16:05:49 | mirak | but bad |
16:05:56 | linuxstb | But if you have Wine installed and a windows cross-compiler, you can use the win32 sim. |
16:06:15 | Bger | hehe |
16:06:18 | | Part tucoz ("Leaving") |
16:06:18 | linuxstb | Which Linux distribution are you using? |
16:06:19 | mirak | I don't have win32 cross compiler |
16:06:23 | mirak | I use ubuntu |
16:06:29 | B4gder | then you can have it |
16:06:30 | mirak | on x86 |
16:06:42 | mirak | well I must built it |
16:06:50 | mirak | I don't want to do that no |
16:06:51 | mirak | now |
16:06:52 | linuxstb | Nope - there is a Debian package. |
16:06:56 | B4gder | we use the debian package fine |
16:07:00 | B4gder | mingw32 |
16:07:02 | mirak | ok great |
16:07:17 | linuxstb | I use it as well to build the windows sim (and other things) |
16:07:35 | B4gder | but of course we'd also appreciate a fix for the x11 sim! |
16:07:44 | linuxstb | Maybe the fix is to port it to SDL |
16:07:53 | B4gder | yes, I would agree to that |
16:08:14 | linuxstb | Does the windows sim use cygwin or is it a native windows app? |
16:08:48 | linuxstb | Obviously it doesn't use cygwin.... |
16:09:03 | linuxstb | Otherwise mingw32 wouldn't work. |
16:09:05 | saa[b_r]ider | lynx: btw, the windowed case scratches your H300 after a while, that's why I suggested the skin |
16:09:24 | saa[b_r]ider | plus it's bulky |
16:09:54 | Lynx_ | saa[b_r]ider: yes, i usually don't use those things |
16:10:14 | Lynx_ | saa[b_r]ider: how much is the lcd remote? |
16:10:39 | Bger | Lynx_ i suggest u to contact someone in korea... |
16:10:51 | Bger | or buy the h100 lcd remote |
16:11:07 | Bger | i bought my this way: through Kylera @ MR |
16:11:39 | saa[b_r]ider | I'm in china, and I asked a korean classmate to get it for me during our spring break :) |
16:12:07 | amiconn | mirak: Now I'm here (sort of) |
16:12:20 | Lynx_ | Bger: is it cheaper in korea? its 20 euro at amazon |
16:12:26 | saa[b_r]ider | I've gotten so used to it, I barely take out my H340 out of my bag. I just use the remote |
16:12:40 | Bger | Lynx_ ? 20 eu for *h300* lcd remote ? |
16:12:45 | Lynx_ | ah, not that's the no lcd one |
16:12:57 | saa[b_r]ider | no one wants that :) |
16:13:09 | Lynx_ | saa[b_r]ider: i don't really care, i just want any remote |
16:13:22 | Bger | this is a robbery for non-lcd :) |
16:13:24 | mirak | amiconn: it was about the precision thing |
16:13:29 | amiconn | B4gder: Standard 16 bit BMP is actually 15 bit RGB555, but you can do all sorts of 16 bit RGB, i.e. RGB565, RGB664 etc. by using the bitfield feature of BMP |
16:13:33 | saa[b_r]ider | lynx: did you check if they still have the LCD remote in MR's on-line shop? |
16:13:44 | Lynx_ | saa[b_r]ider: MR? |
16:13:52 | Bger | misticriver |
16:13:54 | saa[b_r]ider | misticriver.net |
16:14:11 | saa[b_r]ider | your new friend for everything iRiver :D |
16:14:14 | mirak | amiconn: what I was saying is the truncation was the way to go, because, the extra bits are just a subset of the base color |
16:14:23 | amiconn | No, that's wrong |
16:14:59 | amiconn | By having less bits per colour you're getting fewer levels, so you have to round. |
16:15:06 | Lynx_ | saa[b_r]ider: didn't know they have a shop... There's one for 50 euro currently at ebay. that's a lot of money for a remote |
16:15:23 | Lynx_ | saa[b_r]ider: i'll buy your non-lcd remote for 5 eur ;) |
16:15:37 | amiconn | The rounding should happen towards the nearest destination level, and in addition, black always stays black and white always stays white |
16:15:38 | mirak | amiconn: For me the precision doesn't matter. What the actual thing is doing is considering that the colors below and above in fixed interval can be assimilated to that color. But in reality the colors truncated with a right shift are considered to be a subset of a base color. For exemple with what you are doing with 6 bits for a taint, the color 0 have a subset of colors of 2 colors {000 001} while the color 100 have a |
16:15:38 | mirak | subset of {010,011,100,101} |
16:15:46 | | Join Hooligan [0] (i=Hooligan@Node111-61-52-66.1dial.com) |
16:16:10 | saa[b_r]ider | lynx: sure, and i'll charge you 45 euros for shipping :) |
16:16:32 | Lynx_ | saa[b_r]ider: heh, do you live on the moon? ;) |
16:16:45 | amiconn | mirak: Yes, and you can't achieve that with right shifting |
16:17:06 | saa[b_r]ider | close, china :D |
16:17:24 | amiconn | The point is that the lowest and the highest interval have half the width of all others |
16:17:27 | mirak | amiconn: what I am saying is that 0 should also have a 4 colors subset |
16:17:39 | amiconn | That would be plain wrong |
16:18:20 | saa[b_r]ider | lynx: US$ 61 at misticaudio, and backordered! don't know how much that is in euro |
16:18:40 | | Join muesli- [0] (n=muesli_t@141.71.4.188) |
16:18:46 | mirak | amiconn: this doesn't matter, because no matter what, 4 taint of green in 8 bit per taint mode will be assimilated to the same color in 6 bit mode. |
16:18:50 | Lynx_ | saa[b_r]ider: yes, i saw that. i don't think i will buy one for that price |
16:19:14 | | Join b0br [0] (n=3ef54246@labb.contactor.se) |
16:19:33 | mirak | with what you are doing the color 0 will have 2 and the highest will have 6. Well whatever, but that's not even |
16:19:44 | amiconn | No. |
16:20:03 | * | saa[b_r]ider checking iriver china online shop |
16:20:09 | amiconn | I spread evenly, the bottom and top intervals both have half the width of the rest |
16:20:21 | mirak | what I am saying is that if you go from 4 nuances −−-> the same nuance, truncating the lowest bytes is enough and not less accurate than doing a rounding |
16:20:24 | amiconn | That's why I calculate /255, not /256 |
16:20:41 | amiconn | It is less accurate |
16:21:36 | mirak | since colors are linear it's not |
16:21:53 | amiconn | The error is bigger |
16:22:15 | amiconn | If you always round down, the change in brightness can be 0, -1, -2 or -3 |
16:22:22 | saa[b_r]ider | lynx: not available... I'm hoping one day I can use my non-LCD remote as a modded car remote or something (over ambitios) |
16:22:42 | mirak | amiconn: explain the numbers |
16:22:59 | linuxstb | mirak: You are dividing by four and trucating. |
16:23:23 | amiconn | However, if you *round* the change is +1, 0, -1, -2 (or +2, +1 ,0, -1 depending how you treat the "border values") |
16:23:52 | | Quit B4gder ("time to say moo") |
16:24:05 | amiconn | The number mean the error when representing the old values (full scale) with the new ones (reduced scale) |
16:24:09 | mirak | for me the reason it doesnt matter is that the difference between 0,5 and 1,5 is still one |
16:24:34 | mirak | the error is still 4 no matter what you do |
16:24:40 | amiconn | It's not only the difference that matters, but also the absolute value |
16:24:45 | mirak | hem not 4 , 1 |
16:24:50 | amiconn | Nope |
16:25:10 | mirak | well I don't think that we can perceive a visual difference |
16:25:44 | amiconn | If you just truncate, the pictures will end up too dark in the dark parts, and too bright in the bright parts |
16:26:22 | amiconn | If you make a simple drawing on a paper (with few levels) or a spreadsheet, you'll see what I mean |
16:26:22 | preglow | linuxstb: just tested with the yield uncommented again, works just dandy |
16:26:41 | | Quit muesli- ("ich will Kühe!!!") |
16:26:45 | linuxstb | So what changed? |
16:27:11 | preglow | the fun thing about not understanding the error in the first place, is that i don't care :) |
16:27:16 | amiconn | It took me quite a while to figure this out, we implementing the conversion functions in the grayscale lib´rary |
16:27:27 | mirak | amiconn: I agree with darkness thing, but not with brightness :) |
16:27:27 | amiconn | s/we/when/ |
16:27:32 | linuxstb | preglow: hehe. Let's just hope it doesn't return. |
16:27:32 | preglow | i'd appreciate it if you tried it too |
16:27:40 | linuxstb | OK. |
16:28:34 | amiconn | mirak: The difference is that with truncation, you map 256->64, with rounding down. The correct mapping is 255->63, with proper rounding and half-sized upper and lower interval |
16:29:04 | mirak | why 256 ? |
16:29:11 | linuxstb | preglow: Yes, it seems happy. |
16:29:38 | amiconn | If you put together a spreadsheet, you'll also see that *not* all intermediate intervals contain 4 source values, some will contain 5 |
16:29:50 | | Join adiamas [0] (n=adiamas@12.109.187.2) |
16:30:09 | amiconn | mirak: Because that's how truncation works. Just that you'll hever see the topmost value |
16:30:36 | mirak | amiconn: you can't have a value of 256 |
16:30:39 | mirak | what do you mean |
16:30:47 | mirak | it's between 0 and 255 |
16:31:06 | amiconn | [16:30:09] <amiconn> mirak: Because that's how truncation works. Just that you'll hever see the topmost value <== |
16:31:53 | mirak | with truncation 0, 1, 2, 3, gives 0 and 251 253 254 255 gives 63 with 63 that should be the same than the 251 |
16:32:25 | mirak | 251 color, though there is some weird thing in 16bit mode in the datasheet of the lcd screen |
16:32:29 | linuxstb | preglow: I don't know if you've tested, but the line scrolling works fine in the file browser - I have a test directory starting with A with a very long name that scrolls nicely. |
16:32:41 | saa[b_r]ider | bger: any known bugs with the H300 remote patch? |
16:32:47 | mirak | remove "251 color," |
16:33:09 | preglow | linuxstb: cool, will test |
16:33:22 | mirak | amiconn: from what I understand, colors 253 254 and 255 are lost and can't be obtained in 16bit mode |
16:33:43 | mirak | well not exactly but well .. |
16:33:56 | amar | silly question, is there anywhare specidic you have to go to decaler a global variable/setting |
16:34:01 | linuxstb | preglow: I wish you hadn't made the backlight timeout work... |
16:34:17 | preglow | linuxstb: i find the lcd pretty readable even without it |
16:35:14 | linuxstb | Mine needs a light shining directly onto it, and I haven't got one. |
16:35:19 | mirak | amiconn: well nevermind, that's not that much of a problem anyway exept it needs a bit more computation |
16:35:25 | linuxstb | I've just changed the default setting in settings.c though. |
16:35:36 | preglow | mine is completely readable without light |
16:35:53 | preglow | hmm |
16:35:56 | preglow | scrolling doesn't work here |
16:36:00 | preglow | ahh, right |
16:36:03 | preglow | it needs to be selected... |
16:36:09 | linuxstb | Yep. |
16:36:10 | preglow | better make it a dir, then |
16:36:50 | preglow | colour lcds where you can't see without backlight seems really annoying... |
16:37:15 | linuxstb | I have trouble reading the h140's screen without a light as well. Maybe it's just me. |
16:37:23 | preglow | no, that's not just you |
16:37:25 | linuxstb | Or my dark house. |
16:37:25 | preglow | it sucks |
16:37:45 | preglow | hah |
16:37:47 | preglow | works just dandy |
16:37:48 | mirak | preglow: I can't see anything without backlight on the H300 |
16:38:00 | preglow | mirak: the h300 has a very sucky lcd in that regard |
16:38:19 | mirak | don't know why it's sucky |
16:38:27 | preglow | but okies |
16:38:30 | preglow | now for buttons |
16:38:34 | mirak | preglow: that's the only way to have black black |
16:38:35 | amiconn | Most colour LCDs are like that |
16:39:48 | saa[b_r]ider | the H300 LCD shows pretty well without backlight in direct sunlight |
16:40:22 | saa[b_r]ider | so if you're outdoors, you could save some battery power if you kept the LCD off... |
16:40:57 | mirak | yes it would be better to put the lcd off |
16:41:12 | mirak | that's not what you meant I think |
16:41:16 | saa[b_r]ider | I think the reason the H300 LCD doesn't show well without back light because there's a thick piece of glass |
16:41:32 | saa[b_r]ider | I ment the back light |
16:42:01 | mirak | actually, for me it would be the same to have the screen turned off than having just the backlight off |
16:42:14 | | Join San||Away [0] (n=sanitari@213-202-144-96.bas502.dsl.esat.net) |
16:42:19 | mirak | I wouldn't have noticed it was on if you didn't told it to me |
16:42:52 | saa[b_r]ider | unless you were under sulight :) |
16:43:21 | mirak | iriver firmware turn it off isn't it ? |
16:43:37 | saa[b_r]ider | I've always wanted the LCD to stay on with the backlight off, thinking that it would be as clear as with color-screen mobile phones |
16:43:43 | saa[b_r]ider | yeah |
16:45:04 | mirak | I still have a nokia 3310 |
16:45:33 | saa[b_r]ider | :) |
16:45:40 | mirak | the battery is dead |
16:45:43 | saa[b_r]ider | did the model numbers go that low :D |
16:46:50 | saa[b_r]ider | I have my faithful SE T68i as my backup phone... had to use it a few days ago when i dropped my current phone in a glass of water by accident :| |
16:47:35 | mirak | admit it was a beer |
16:47:38 | mirak | just admit it |
16:47:39 | mirak | :) |
16:48:37 | | Quit adiamas ("Chatzilla 0.9.69 [Firefox 1.5/2005111116]") |
16:48:43 | saa[b_r]ider | hahaha.... actually, it was the iron refiller, with water and toothpaste inside it (from when I opened my H340 to insert an inSkin) |
16:49:09 | saa[b_r]ider | :D |
16:49:27 | saa[b_r]ider | I bet you could never have guessed ;) |
16:49:49 | preglow | linuxstb: does the ipod control pads differ between generations? i thought they all had the same basic functionalty |
16:50:35 | preglow | hah, rockbox.ipod is 300k, rockbox.iriver is 250k |
16:50:42 | preglow | we really should play around with using thumb code |
16:51:08 | linuxstb | Yes - especially for code in iram. |
16:51:17 | preglow | hmm |
16:51:25 | preglow | it's usually the other way around |
16:51:27 | preglow | especially for code in ra |
16:51:28 | preglow | m |
16:51:35 | linuxstb | I know - but I mean to save space in iram. |
16:51:48 | preglow | well, we wont use too much iram for code, hopefully |
16:52:01 | preglow | though the ipod code cache is just as bad as motorolas |
16:52:27 | preglow | i wonder if we can configure it to never cache data |
16:52:37 | preglow | we'll need to do some tests, obviously |
16:52:38 | mirak | what exactly is ffmpeg ? Is it an interface or codecs etcetera ? |
16:52:43 | preglow | mirak: it's a codec library |
16:52:55 | mirak | you used that for ogg mp3 etcetera ? |
16:52:57 | linuxstb | The ipod control pads are (I think) the same for all the PP5020 models - apart from the mini. |
16:53:20 | linuxstb | mirak: No. But we use the ffmpeg and shorten decoders from it. |
16:53:22 | preglow | what's different for the mini? |
16:53:29 | preglow | flac and shorten decoders |
16:53:44 | linuxstb | Yes, that. |
16:54:30 | linuxstb | preglow: All I know is what's in the kernel's keyboard.c file |
16:54:46 | mirak | linuxstb: hem ffmpeg is a codec in itself ? |
16:55:10 | linuxstb | mirak: ffmpeg is a high level library for decoding and encoding audio and video. It consists of libavcodec (the codecs themselves) and libavformat (for the container formats) |
16:55:11 | | Join hshah [0] (n=hshah@shahassociates.plus.com) |
16:55:31 | preglow | linuxstb: i was just thinking about the need for several IPOD_*_PAD defines |
16:55:37 | preglow | linuxstb: when they're all basically the same |
16:55:38 | linuxstb | mirak: It does far too much for it to be of general use in Rockbox. |
16:55:54 | linuxstb | preglow: Yes, I've thought about that. An IPOD_4G_PAD is probably enough. |
16:56:06 | preglow | linuxstb: what about IPOD_PAD ? |
16:56:36 | linuxstb | The earlier PP5002-based models are possibly different - I haven't looked at the code for those. |
16:56:39 | preglow | they alle have the same buttons, don't they? |
16:56:52 | linuxstb | Yes, but at least the drivers will be different. |
16:56:57 | preglow | yes they will |
16:57:15 | preglow | but this way all plugins and such don't have to do the full string off checks for IPOD_*_PAD |
16:57:33 | preglow | but okies, we'll see |
16:57:36 | linuxstb | The H100/H300 is the same - they look the same to the application, but have different drivers. |
16:58:03 | preglow | hmm, true |
16:58:09 | linuxstb | So it could be worth having something like IPOD_PAD and CONFIG_IPOD_PAD |
16:58:27 | linuxstb | Or in fact, just have IPOD_PAD contain different (non-zero) values |
16:58:45 | preglow | and btw, we should probably drop all the PP5020 prefixes we use now |
16:58:53 | preglow | it's kind of redundant in rockbox |
16:59:14 | preglow | at least for the ones in pp5020.h |
16:59:49 | linuxstb | Yep, that would make sense. |
16:59:53 | preglow | should i stuff opto_i2c_init in i2c-pp5020.c as well? |
17:00 |
17:00:27 | preglow | i don't really know what it does, so i have no idea, i just see 'i2c' in its name |
17:00:27 | linuxstb | No, I think that code belongs in button_init() |
17:00:33 | preglow | okay |
17:00:54 | linuxstb | But I guess it doesn't really matter. |
17:01:03 | | Quit Zagor ("Client exiting") |
17:01:41 | | Join muesli- [0] (n=muesli_t@141.71.4.220) |
17:05:23 | mirak | hem what does it mean when it's said that rockbox doesn't do dynamic memory allocation ? |
17:05:44 | linuxstb | There is no malloc() |
17:06:03 | linuxstb | (apart from a very restricted implementation used by some of the codecs - but that's an exception) |
17:06:17 | | Quit muesli- ("ich will Kühe!!!") |
17:06:55 | mirak | so how can you know what memory you can use ? |
17:07:11 | preglow | man, how i hate ifdefs |
17:07:20 | preglow | you take whatever you need |
17:07:21 | preglow | then use it |
17:07:26 | | Join muesli- [0] (n=muesli_t@141.71.4.220) |
17:07:34 | preglow | if you need 256 bytes, you just do char buf[256]; then use that |
17:07:57 | mirak | ok |
17:08:27 | mirak | what's the difference with the malloc then ? |
17:08:34 | XavierGr | Question: What #if would you recommend for the file scroller plugin? It is based on plugin memory needs. |
17:08:34 | preglow | linuxstb: btw, you changed the backlight timer, yes? does it seem accurate on longer times? |
17:08:44 | mirak | (I am mostly do java actually, so that's a bit far for me now) |
17:09:00 | preglow | mirak: the difference is that we don't need to keep a lot of memory free so you can use malloc |
17:09:36 | mirak | ok, don't know what malloc is doing exactly |
17:09:36 | | Quit edx (Read error: 104 (Connection reset by peer)) |
17:09:49 | preglow | mirak: malloc finds a large enough space of free memory, then lets you use that |
17:10:03 | preglow | mirak: that memory can't be used any place else in rockbox, so we need a large free pool of memory |
17:10:23 | preglow | mirak: wasting space like that is bad in rockbox, since we need all the memory we can get for the file buffer |
17:10:25 | linuxstb | preglow: No, changing the default in settings.c doesn't work unless I reset the settings... |
17:10:26 | mirak | but malloc doesn't take what you say him to take only ? |
17:10:43 | mirak | ok nevermind |
17:10:44 | mirak | lol |
17:10:46 | | Quit hshah ("Leaving") |
17:11:05 | preglow | mirak: yes, but since we never know how much memory people are going to need, we have to reserve rather a lot of space |
17:11:17 | linuxstb | mirak: malloc() also has a corresponding free() function - it's the free() function that's the main troublemaker. |
17:11:47 | preglow | bah, i should get keys working |
17:11:47 | linuxstb | So it's probably more informative to say that Rockbox doesn't have free(). |
17:12:00 | | Quit San||Away (Read error: 110 (Connection timed out)) |
17:12:05 | preglow | we should write a faq entry on this |
17:12:23 | mirak | linuxstb: so how the space allocated is given back ? |
17:12:33 | linuxstb | It never is. That's the point. |
17:12:46 | mirak | mmm |
17:13:07 | amiconn | malloc() on a platform like rockbox has some drawbacks: (1) it needs a memory pool for allocation, which can't be used otherwise. We want to use most RAM for buffering, so that would be a waste. |
17:13:47 | *** | Saving seen data "./dancer.seen" |
17:14:08 | PaulJ | can someone explain to me what exactly the crossfadeoptions "fade in delay" and "fade out delay" mean? (this is missing in the wikimanual) |
17:14:09 | amiconn | (2) error handling would become more complex, because a malloc() can fail. It would also be more confusing for the user, why a feature works one time, but not the other, even with proper error messages |
17:14:29 | mirak | when you declare a new variable, a char buf[256]; how can you know it will not give the memory adress of an existing programm ? |
17:14:30 | XavierGr | plugin_get_buffer is a nice example of "like" memory allocation in rockbox. |
17:14:43 | XavierGr | as linuxstb taught me. |
17:14:53 | amiconn | (3) On platforms without a MMU, we would also run into memory fragmentation problems with a true malloc() implementation |
17:14:56 | mirak | ok |
17:14:58 | linuxstb | mirak: Rockbox is just a single program - the compiler takes care of allocating the static buffers. |
17:15:05 | Slasheri | in fact it could be possible to do malloc quite working but then we would need to implement a function like p = refresh(p); that would memmove and relocate the allocated memory |
17:15:35 | mirak | ok so that's still less confusing than assembler then ^^ |
17:15:40 | linuxstb | That sounds like memory handles which need to be de-referenced before accessing. OSes like Symbian use those IIRC |
17:15:51 | * | amiconn really likes assembler |
17:16:31 | amiconn | mirak: Have a look at memcpy_a.S ;) |
17:16:34 | preglow | assembler is nice |
17:16:53 | linuxstb | amiconn: I'm sure you would love the ARM... |
17:16:57 | mirak | ok, so when you exit a plugin, what happens ? |
17:17:20 | preglow | amiconn: nice, shiny risc assembler |
17:17:34 | amiconn | linuxstb: I'm not so sure... |
17:17:37 | amiconn | I'm biased |
17:17:43 | preglow | arm is lovely for assembler |
17:17:47 | preglow | there can be no doubt about it |
17:17:54 | preglow | one of the nicer asm variants i have seen |
17:18:09 | linuxstb | mirak: There is a fixed block of memory (32KB for Archos, 768KB for iriver) assigned for plugins - all the code and data go in there. |
17:19:01 | | Join hshah [0] (n=hshah@shahassociates.plus.com) |
17:19:03 | amiconn | Slasheri: Hmm, the memory handle idea could actually work - if the overhead isn't too big |
17:19:14 | preglow | btw, can't we decrease the 768kb a bit? |
17:19:20 | preglow | 512kb sounds like it should be enough |
17:19:20 | amiconn | I think so |
17:19:25 | amiconn | Yes |
17:19:25 | Slasheri | amiconn: true, especially if the allocated memory chunks are small |
17:19:35 | linuxstb | That would ruin XavierGr's changes to the JPEG viewer though... |
17:19:52 | preglow | does that use plugin space? |
17:20:02 | amiconn | preglow: 512KB/32MB == 32KB/2MB, just by coincidence... |
17:20:05 | preglow | jpeg has heaps of memory left even then |
17:20:22 | preglow | jpeg is only 26kb big, tons and tons of memory left |
17:20:23 | preglow | besides |
17:20:42 | linuxstb | The jpeg viewer currently uses the audio buffer for the actual image buffer - XavierGr is changing it to use the plugin buffer if there is enough room. |
17:20:48 | preglow | yup |
17:21:04 | linuxstb | Plus adding a slideshow type feature IIUC. |
17:21:15 | amiconn | You can get quite far with 512KB (minus 26KB for the plugin) |
17:21:18 | preglow | but i think reserving plugin space just because of features like that is a bit... wrong |
17:21:44 | * | amiconn would like to get down codec ram size as well |
17:21:56 | preglow | i think 512kb sounds nice |
17:22:01 | amiconn | Bad aac ;) |
17:22:06 | preglow | hmm |
17:22:09 | preglow | aac needs work |
17:22:22 | linuxstb | Yes, the codecs also have a huge 512KB malloc buffer which should be reduced or even removed. |
17:22:28 | XavierGr | Even if you change the plugin memory to 512 my change still work |
17:22:48 | XavierGr | It is just that it would fit smaller pictures. |
17:22:48 | linuxstb | Is it still as useful? |
17:23:03 | amiconn | The biggest plugin is rockboy, and even that needs a little less than 400 KB |
17:23:16 | preglow | it would still be useful, but yes |
17:23:31 | preglow | i'd probably love the feature, but i still don't think the needs of just one plugin merits keeping the plugin buffer huge |
17:23:45 | XavierGr | what feature? |
17:23:52 | linuxstb | Your feature. |
17:23:54 | preglow | your jpeg plugin extensions |
17:23:55 | XavierGr | ah |
17:24:08 | XavierGr | it will be still usable if set to 512 |
17:24:27 | preglow | yup |
17:25:00 | XavierGr | 29 kb for plugin + 86kb (I think) for grayscale + (number of entries) * 1 byte |
17:25:05 | XavierGr | the reset for the picture |
17:25:15 | XavierGr | ^rest |
17:26:35 | mirak | so if I declare many times a variable in a block ( a loop for exemple) will it take all the space in ram ? |
17:27:09 | preglow | aac.codec is actually smaller for ipod |
17:27:24 | preglow | mirak: no |
17:27:31 | preglow | mirak: it will just stay one variable |
17:28:01 | | Quit b0br ("CGI:IRC") |
17:28:27 | preglow | linuxstb: what to do about the udelay() calls? use something else or just include that as well? |
17:28:36 | preglow | what does other driver code use for delays? |
17:29:26 | linuxstb | I don't think anything else has delays yet. |
17:29:36 | Slasheri | mirak: you can think that everything inside { } makes the stack one step deeper and variables inside that block are allocated from the stack. However, at the end of }, one level of stack is freed. So for(..) { .. } would increase and decrease the stack on every loop |
17:30:10 | linuxstb | preglow: There are loops for things like "wait_not_busy" which use current_tick to implement a timeout whilst waiting for a hardware register to change. |
17:30:22 | preglow | i need 5 musecs of delay, hehe |
17:30:52 | preglow | thin i'll just stuff udelay in for now |
17:30:56 | mirak | Slasheri: ok |
17:31:43 | linuxstb | preglow: Yes, put udelay somewhere central - maybe an inline function in system.h |
17:32:56 | preglow | ok |
17:32:59 | preglow | i wont yield inside it |
17:33:07 | preglow | so it's just for driver use |
17:36:31 | | Quit Febs () |
17:39:13 | | Join Moos [0] (i=DrMoos@m196.net81-66-159.noos.fr) |
17:39:23 | Lynx_ | so, does the iaudio x5 play all xvid files, or do they have to be of a special size and such? |
17:40:09 | preglow | hahah |
17:40:22 | mirak | damn i am reading xvid decoder |
17:40:23 | preglow | you think it'll full size 640x480 xvids at 25fps? :P |
17:40:45 | preglow | insert 'play' |
17:40:54 | mirak | the H300 ? |
17:40:56 | mirak | :D |
17:41:17 | mirak | 220*174 25fps would be fine yes |
17:41:34 | mirak | though after seeing the cube running, I am wondering if the screen doesn't have to much latency |
17:41:41 | linuxstb | mirak: Which xvid decoder are you looking at? |
17:41:45 | mirak | to use above 10 fps |
17:41:53 | XavierGr | mirak: no kidding. you have an xvid video in rockbox playing? |
17:42:04 | mirak | linuxstb: I apt-get source xvidcore |
17:42:10 | mirak | XavierGr: rofl |
17:42:13 | linuxstb | Does it use floats? |
17:42:21 | mirak | it seems it doesn't |
17:42:26 | mirak | I have seen only int |
17:42:28 | mirak | uint |
17:42:55 | mirak | for interpolation I don't know yet |
17:43:03 | mirak | it's in other files I haven't checked |
17:43:10 | linuxstb | Do you know what license it is released under? |
17:43:28 | mirak | that's on debian so it should be ok |
17:43:43 | | Join lush [0] (n=42993aea@labb.contactor.se) |
17:43:47 | lush | hola guys |
17:43:53 | mirak | This program is free software ; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by |
17:43:54 | mirak | blabla |
17:44:29 | mirak | there is assembly optimisations |
17:44:35 | mirak | not for coldfire ;) |
17:44:40 | | Quit lush (Client Quit) |
17:44:55 | linuxstb | What about ARM? |
17:46:24 | mirak | nope |
17:46:54 | mirak | anyway I don't see why they would use float, most of the time everything is converted to discret stuffs, even for fourier computations |
17:47:02 | linuxstb | Get porting then :) |
17:47:22 | mirak | that's my main motivation |
17:47:23 | mirak | but well |
17:47:28 | mirak | you know :) |
17:48:09 | mirak | I am interested in knowing how mpeg compression works. |
17:48:25 | mirak | that's not from that code that I will learn that I think |
17:48:32 | preglow | haha |
17:48:37 | preglow | i wouldn't want to learn that from the code |
17:48:41 | preglow | mpeg4 isn't that complex |
17:48:42 | mirak | nope |
17:48:50 | preglow | still builds on good old mpeg1/2 methods |
17:48:59 | mirak | I don't know them |
17:49:12 | preglow | a good first step is finding out how jpeg works |
17:49:17 | mirak | I have studied some things related to that in univ though |
17:49:21 | preglow | then after that learning about motion estimation |
17:49:29 | preglow | and entropy coding |
17:49:44 | mirak | that's what I learned. motion estimation for tracking etecetera |
17:49:56 | mirak | c'etait imbaisable |
17:50:01 | mirak | like we say here |
17:50:15 | mirak | (traduction : it was unfuckable) |
17:50:25 | preglow | would most definitely be hard |
17:51:00 | mirak | I got 10 at this exam. it was about fourier transformation and stuffs |
17:51:15 | mirak | my god |
17:51:47 | preglow | ten being how good? |
17:51:55 | | Quit hshah ("Leaving") |
17:53:20 | mirak | 10/20 |
17:53:24 | mirak | not less not more |
17:54:15 | mirak | it could have been worse, I didn't do pure mathematics for 2 years before doing that. |
17:58:23 | preglow | haha |
17:58:29 | mirak | preglow: ! ok I have studied that but we didn't seen how to use that for compression |
17:58:37 | preglow | use what? |
17:58:50 | mirak | hem discret fourier transformation |
17:59:11 | preglow | it's just a matter of removing coefficients that aren't imptant |
17:59:15 | preglow | important! |
17:59:21 | preglow | and coding the result |
17:59:24 | mirak | right ! |
17:59:29 | mirak | I remember |
17:59:35 | mirak | we cut the frequencies |
18:00 |
18:00:00 | mirak | however for me it would have been better to study that for sound |
18:00:20 | mirak | because in 2 dimension that's not very clear what happens |
18:00:47 | mirak | a spectral representation of a sound wave is interpretable |
18:01:09 | mirak | and understandable, while for an image that's really not the case |
18:01:28 | mirak | so you studied that ? |
18:02:10 | preglow | studied and studied |
18:02:14 | preglow | it's more a hobby thing |
18:03:12 | mirak | lol, fourier transform as a hobbi |
18:03:14 | mirak | why not :) |
18:04:34 | preglow | haha |
18:04:35 | preglow | well |
18:04:36 | preglow | a part of it |
18:04:43 | preglow | fourier transform isn't exactly my main area of expertise |
18:07:27 | mirak | what's your dada ? |
18:07:57 | preglow | dada? |
18:08:16 | mirak | your passion |
18:08:28 | mirak | your main domain of expertise |
18:09:18 | preglow | right |
18:09:21 | preglow | god known |
18:09:25 | preglow | sound synthesis, i'd guess |
18:09:31 | preglow | which includes quite a few areas again |
18:09:48 | preglow | more or less anything that has to do with sound |
18:09:57 | mirak | you did the vocal stuff for archos ? |
18:10:02 | preglow | nono |
18:10:07 | mirak | like fart sound ? |
18:10:07 | preglow | that was [idc]dragon |
18:10:26 | mirak | sorry ... :) |
18:13:30 | mirak | I had a module of vocal recognition |
18:13:43 | mirak | I got 17/20 but it was a bit sucky |
18:17:50 | | Join lush [0] (n=42993aea@labb.contactor.se) |
18:17:55 | lush | ello? |
18:18:04 | lush | anybody home/ |
18:18:06 | lush | ? |
18:18:10 | muesli- | nope |
18:18:27 | lush | hey just started using the rockbox fw on my iriver h120 and i frekking love it |
18:18:32 | lush | but it wont play back my wma files |
18:18:37 | | Join NicoFR [0] (n=nico404@rob92-6-82-231-243-63.fbx.proxad.net) |
18:18:44 | lush | it just skips em, and then says codec error |
18:18:56 | lush | any idea as to why? |
18:19:00 | muesli- | it wont in near future..mayb sometime |
18:19:14 | lush | huh? |
18:19:32 | linuxstb | Rockbox doesn't have a WMA decoder. |
18:19:45 | linuxstb | So it can't play wma decoders until someone decides to write one. |
18:20:00 | linuxstb | I mean it can't play wma files... |
18:20:06 | lush | ok i got ya |
18:20:09 | lush | thanks, |
18:20:30 | lush | hey one other question, |
18:20:40 | lush | how do you add plugins to the player? |
18:20:58 | lush | do i dl em and then just, copy them over to the rockbox dir? |
18:21:29 | | Quit XavierGr (Read error: 110 (Connection timed out)) |
18:21:41 | muesli- | copy them where you want |
18:21:47 | muesli- | it doesnt matter |
18:21:51 | lush | nice |
18:22:02 | lush | same for those wps things that are the skins? |
18:22:15 | muesli- | see .rockbox/wps |
18:22:23 | lush | nice |
18:22:27 | lush | thanks for the help |
18:22:34 | muesli- | no worries |
18:22:49 | lush | this stuff is soo much better than default crap |
18:23:07 | muesli- | 100% agree ;) |
18:23:08 | | Quit lush ("CGI:IRC (EOF)") |
18:23:23 | | Join webguest34 [0] (n=52e30123@labb.contactor.se) |
18:23:36 | | Quit webguest34 (Client Quit) |
18:23:51 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
18:29:19 | mirak | exept for video ... |
18:29:21 | mirak | ;D |
18:29:37 | muesli- | time will tell ;) |
18:29:41 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
18:31:41 | preglow | man, button drivers are not my favourite |
18:34:48 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
18:37:12 | preglow | linuxstb: are there any ipod special cases hanging around that you know about? |
18:39:12 | linuxstb | No, I think the current_tick was the last one. |
18:39:29 | linuxstb | What's the problem? |
18:39:36 | preglow | just wondering |
18:39:43 | preglow | i've implemented a small keyboard driver now |
18:39:45 | preglow | and it hangs rockbox |
18:40:54 | linuxstb | Does it crash immediately, or when you press a button? |
18:41:18 | preglow | hangs at logo |
18:41:19 | | Join DrMoos [0] (i=DrMoos@m196.net81-66-159.noos.fr) |
18:41:35 | preglow | got it |
18:41:40 | preglow | was a dead giveaway |
18:41:43 | preglow | i didn't ack the interrupt |
18:42:10 | preglow | now it hangs when i press a button :-) |
18:42:41 | linuxstb | That's progress... |
18:42:55 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
18:43:11 | preglow | yes |
18:44:11 | | Nick DrMoos is now known as Moos (i=DrMoos@m196.net81-66-159.noos.fr) |
18:44:14 | | Join Mmmm [0] (n=3efc4010@labb.contactor.se) |
18:44:27 | preglow | hmm, no |
18:44:32 | preglow | it seems i'm still not acking the interrupt |
18:44:41 | preglow | i must have touched the clickwheel the first time |
18:44:44 | preglow | it behaves just the same |
18:46:12 | amar | whare its the global_settings structure diffined? |
18:46:26 | | Join jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net) |
18:46:37 | jlo | hi |
18:46:43 | preglow | hi |
18:48:11 | | Quit muesli- ("ich will Kühe!!!") |
18:50:15 | jlo | preglow : I did some test with Reaktor (I used soft this weekend because I have only harware at the office !), simulating crossfeed, now can you and markun tell me which music you'd like to test so I can do some recordings with/without |
18:53:39 | * | preglow kicks markun |
18:53:42 | | Join San [0] (n=sanitari@A-72-3.cust.iol.ie) |
18:55:17 | jlo | I'll come back later |
18:55:20 | | Quit jlo () |
18:57:25 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
19:00 |
19:00:23 | | Join Mmmm_ [0] (n=3efc4010@labb.contactor.se) |
19:00:38 | mirak | preglow: a keyboard driver on usb host ? |
19:00:38 | | Quit Mmmm ("CGI:IRC (EOF)") |
19:00:59 | | Quit NicoFR () |
19:02:03 | preglow | mirak: eh? |
19:02:17 | | Join akaidiot [0] (n=nope@c-ad45e255.363-1-64736c11.cust.bredbandsbolaget.se) |
19:02:44 | | Join Mmmm [0] (n=3efc4010@labb.contactor.se) |
19:04:10 | preglow | i would kill for a data sheet |
19:04:24 | preglow | http://www.portalplayer.com/company/info-form.htm |
19:04:27 | preglow | someone try that :-) |
19:07:01 | mirak | <preglow> i've implemented a small keyboard driver now |
19:07:03 | | Join XavierGr [0] (n=XavierGr@ppp13-adsl-1.ath.forthnet.gr) |
19:07:11 | mirak | ? |
19:07:32 | | Join ender1 [0] (i=ychat@84.52.165.220) |
19:07:47 | mirak | rockbox is better than ipod linux ? |
19:07:55 | XavierGr | which is faster: memmove or memcpy? |
19:08:20 | preglow | mirak: i'm talking about ipod |
19:08:27 | preglow | mirak: depends what you want |
19:08:32 | preglow | XavierGr: memcpy for now |
19:08:41 | preglow | if you don't need memmoves functionality, use memcpy |
19:08:50 | XavierGr | okay then it should be my preffered choice. |
19:09:11 | | Join edx [0] (i=edx@p54A861F0.dip.t-dialin.net) |
19:09:23 | XavierGr | also on the jpeg viewer I saw that: #define MEMCPY(d,s,c) rb->memcpy(d,s,c) |
19:09:41 | XavierGr | is that an optimization, should I use it that way or call with the rb api pointer? |
19:10:02 | XavierGr | or it is just an alias? |
19:10:07 | mirak | preglow: don't probably ipodlinux is less cryptic |
19:10:17 | mirak | since we are maybe more used to linux |
19:10:19 | mirak | don't know |
19:10:46 | mirak | but well if rockbox is faster anyway |
19:11:00 | preglow | nothing says it is |
19:11:08 | preglow | rockbox and linux are two different approaches |
19:11:11 | preglow | it depends what you want |
19:11:18 | mirak | Rockbox's version is a lot smaller and faster, while IpodLinux's is bigger and slower but very well known, very well tested and offers a multitude of more services and features. |
19:11:24 | mirak | http://www.rockbox.org/twiki/bin/view/Main/IpodLinux |
19:12:57 | mirak | well actually for me the main difficulty with rockbox is that it's not clear what are syscalls usable from user programs, what is not etecetera |
19:13:26 | mirak | but that just me, and I am starting |
19:13:50 | *** | Saving seen data "./dancer.seen" |
19:15:04 | | Quit ender` (Read error: 110 (Connection timed out)) |
19:16:38 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
19:17:08 | | Join Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) |
19:17:25 | preglow | most things are usuable from user programs in rockbox? |
19:17:30 | preglow | s/?/./ |
19:19:58 | preglow | hah! |
19:20:02 | preglow | it no longer hangs! |
19:20:31 | preglow | i can activate backlight by keypress |
19:20:36 | | Quit akaidiota (Read error: 110 (Connection timed out)) |
19:20:59 | amiconn | XavierGr: (1) We don't have memmove() in rockbox yet. (2) The MEMCPY() macro is just for portability |
19:21:33 | San | hey |
19:21:47 | | Nick San is now known as San||Halo (n=sanitari@A-72-3.cust.iol.ie) |
19:22:00 | | Quit Mmmm_ ("CGI:IRC (EOF)") |
19:22:06 | | Quit Mmmm ("CGI:IRC (EOF)") |
19:22:41 | | Part Polo_o |
19:22:55 | | Join Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com) |
19:26:04 | preglow | linuxstb: you there? |
19:27:20 | | Join petur [0] (i=petur@d54C1B62E.access.telenet.be) |
19:28:18 | preglow | linuxstb: if you are, check out www.pvv.org/~thomj/rockbox/rockbox.ipod, please |
19:28:27 | preglow | seems the hold switch functionality is done in hardware on the ipod |
19:29:45 | | Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) |
19:34:14 | XavierGr | f*cking iriver fw. |
19:35:00 | XavierGr | I try to debug, when my unti hungs and reset it then if I press play iriver fw starts instead of Rockbox, why? |
19:35:21 | XavierGr | It takes ages to reboot when iriver fw starts... grrrr |
19:35:24 | amiconn | preglow: detectable? |
19:36:14 | preglow | amiconn: yes |
19:36:20 | preglow | amiconn: that is, i think so |
19:36:31 | preglow | amiconn: it's a bit strange, switching hold off seems to generate an interrupt |
19:36:36 | preglow | amiconn: but switching on doesn't seem to |
19:37:04 | preglow | i was wrong |
19:37:05 | preglow | both do |
19:38:11 | preglow | strange |
19:38:24 | preglow | ipl installs two keyboard related interrupts, i only use one, and i seem to get all the interrupts i need |
19:38:29 | mirak | preglow: that's what I don't know, I guess documentation will come with time |
19:41:21 | | Join jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net) |
19:42:22 | | Join webguest34 [0] (n=415ce17e@labb.contactor.se) |
19:42:48 | | Join xmixahlx [0] (n=xmixahlx@64.122.111.98) |
19:44:24 | preglow | jlo: so, have you modelled your new crossfeed proposal yet? |
19:45:29 | | Quit edx (Read error: 110 (Connection timed out)) |
19:45:50 | jlo | preglow : yes, if you have reaktor, I can send you the modelling file |
19:47:04 | | Join _FireFly_ [0] (n=FireFly@p54A460EE.dip.t-dialin.net) |
19:47:11 | jlo | I'll put wav files with/without correction on ftp |
19:48:35 | preglow | haven't got reaktor here, i'm afraid |
19:51:07 | jlo | preglow : so I put the schematics (in png) on http://www.ohl.to/iriver/ in the reaktor directory, have a look |
19:53:13 | | Quit webguest34 ("CGI:IRC") |
19:53:32 | preglow | hmm |
19:53:37 | preglow | those filters are second order |
19:53:42 | preglow | i wish you wouldn't use them ;) |
19:54:41 | jlo | preglow : the pb for you is that the filters are shelving , no? |
19:55:13 | preglow | well, yeah, but i was hoping we'd be using first order filters |
19:55:24 | preglow | and using second order filters instead of first order might give different results |
19:55:36 | preglow | i think reaktor has got first order shelving filters as well |
19:55:39 | preglow | in the core modules somewhere |
19:55:47 | preglow | static eq filters or something |
19:55:52 | jlo | preglow : it's first order (6dB/oct) but shelving |
19:55:58 | preglow | oh, they are? |
19:56:01 | preglow | then it's fine |
19:56:07 | | Quit Hooligan () |
19:59:47 | jlo | preglow : I first tested with correlated pink noise to check that no major tonal unbalance occurs, and after with different music tracks, but now I'd like to check also with your files |
20:00 |
20:02:50 | preglow | gimme a sec and i'll se if i've got what markun gave me |
20:02:51 | | Join edx [0] (i=edx@p54A84D09.dip.t-dialin.net) |
20:04:27 | | Join _DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
20:05:10 | jlo | preglow : see http://www.stereo-balance.net/index.php?mod=wiki&w=headplug, he's giving the source of his winamp crossfeed plugin, have you allready looked that one ? |
20:06:04 | | Quit ender1 (Read error: 104 (Connection reset by peer)) |
20:07:14 | preglow | jlo: no i havenæt |
20:07:15 | | Join JazzBone [0] (n=JB@cc829402-a.groni1.gr.home.nl) |
20:07:27 | | Join Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com) |
20:07:52 | | Join zeero [0] (n=nick@fw.cerisent.com) |
20:08:13 | XavierGr | OK The new JPEG plugin viewer is ready. Any testers? (Especially arhos users) I will upload it to the patch tracker soon. |
20:08:23 | | Join ender` [0] (n=ender@84.52.165.220) |
20:09:13 | XavierGr | I manged to do quite well to my tests. 1074 files 75 characters each. (path doesn't matter, only filename) |
20:09:20 | XavierGr | ^It |
20:09:25 | zeero | so, maybe i'm a idiot to not be able to work this out, but i'd like to start helping out with the h300 effort now that i can get it on my player, but in building the sim, when i run ./rockboxui i get something that looks not at all like what i see on my player. also, i can't work out what the keys for a-b and so on are, only up/down/left/right seem to work. am i missing something obvious? |
20:10:04 | XavierGr | Maybe you biuld a simulator for another target. |
20:10:22 | XavierGr | Did you choose your model in coniguration? |
20:10:26 | zeero | XavierGr: i selected the h300 in config |
20:10:51 | XavierGr | what do you use: cygwin, devkit, linux? |
20:11:00 | zeero | linux |
20:14:38 | XavierGr | I can't help you. I use the devkit |
20:15:13 | petur | zeero: do you use w32 (wine) or x11? |
20:18:33 | jlo | preglow : I'll put on the web three anonymous files (original, rb crossfeed, my version, winamp plugin) so you can try with abc/hr soft (http://ff123.net/abchr/abchr.html) the one you prefer. if you and others can use it, I can do it for other tracks |
20:19:09 | preglow | ok |
20:19:48 | | Quit tvelocity ("Leaving") |
20:19:58 | jlo | preglow : I think In |
20:20:00 | petur | Slasheri, are you around? |
20:20:12 | jlo | I think I need an hour or so |
20:20:14 | | Quit DangerousDan (Read error: 110 (Connection timed out)) |
20:20:21 | preglow | jlo: that's ok, i'll still be here then |
20:22:00 | Slasheri | petur: yes, hi |
20:22:19 | petur | got a quick Q about the H1xx backlight dimming |
20:22:24 | petur | yours? |
20:22:34 | Slasheri | hmm, original code yes |
20:23:01 | petur | is that dimming through a timer routine switching on/off? |
20:24:04 | Slasheri | yes, with cpu timer interrupt. So we have a fixed cycle time and then the on and off pulse times are being modified |
20:24:31 | petur | software PWM then... the H1xx has only on/oof, no PWM? |
20:24:33 | zeero | x11 |
20:24:44 | petur | zeero: x11 sim seems broken |
20:24:46 | Slasheri | yep, pure software pwm :) |
20:24:53 | petur | ok thanks. |
20:25:06 | petur | wanted to be sure I understood what I saw |
20:25:06 | Slasheri | it might have pwm on some outputs, but not on that backlight output at least |
20:25:11 | zeero | petur: hrmm, does the wine one work? |
20:25:19 | petur | yes |
20:25:30 | zeero | petur: k, thanks, i'll try building that |
20:25:37 | linuxstb | preglow: I've just tried your build - I can turn the backlight back on... |
20:25:51 | petur | can't help with wine, using W2K here ;) |
20:26:02 | petur | (that's windows2000) |
20:26:12 | petur | but it should work |
20:26:24 | zeero | petur: nod, dang, so i need a cross compiler to do that though huh? |
20:26:46 | linuxstb | Yes - which linux distro are you using? |
20:27:03 | Slasheri | linuxstb: btw, now the tag cache has a stable building routine that should most definately work on archos too and simple artist listing. Seems to work pretty well :) But still many things left to be done.. |
20:27:04 | zeero | linuxstb: redhat el4 |
20:27:21 | zeero | linuxstb: i have a debian box i can use too, but i'd prefer to do it on this one |
20:27:47 | linuxstb | zeero: On Debian, you can just do "apt-get install mingw32" to install the Windows cross-compiler. I've no idea about RH. |
20:28:04 | petur | LinusN: have you tried different backlight PWM values on the pcf50606? Is there a safe range or do they all work? |
20:28:11 | linuxstb | Slasheri: Nice. Are you far away from having something others can try? |
20:28:37 | LinusN | petur: most values flicker |
20:28:39 | | Quit jlo (Read error: 104 (Connection reset by peer)) |
20:28:44 | Slasheri | linuxstb: not very far, but still that code is not very usable. Maybe in one or two weeks :) |
20:28:55 | zeero | linuxstb: k, thanks, i'll poke around a bit and see if there's an rpm somewhere (how i wish apt worked as well for redhat as it did for debian) |
20:28:55 | petur | I wonder how iRiver does it then |
20:29:24 | petur | no harm to try them all? I mean: over-volting the backlight or something? |
20:30:20 | preglow | linuxstb: backlight turns on when you press something, yes= |
20:30:25 | Slasheri | linuxstb: at least the api to the tag cache is now quite simple. For example listing all artists: struct tagcache_search tcs; tcs.type = tag_artist; tagcache_search(&tcs); while (tagcache_get_next(&tcs)) { do_something(tcs.result, tcs.result_len) } tagcache_search_finish(); |
20:30:32 | petur | LinusN: did you play with the frequency as well? |
20:30:39 | linuxstb | preglow: Yes. For the hold switch as well. |
20:30:44 | preglow | linuxstb: excellent |
20:31:01 | petur | reason: want to have a go at configurable backlight |
20:31:07 | linuxstb | So it looks like the hold switch is hardware? |
20:31:12 | preglow | linuxstb: indeed |
20:31:20 | preglow | linuxstb: all i do currently is register and handle the interrupt |
20:31:32 | preglow | linuxstb: no other handling is done by me, and the keys are ignored when hold is on |
20:31:45 | LinusN | petur: yes |
20:32:08 | petur | is 512Hz what iRiver uses or your best pick? |
20:32:18 | LinusN | petur: feel free to experiment |
20:32:18 | linuxstb | preglow: Have you looked at this code? http://opensvn.csie.org/courtc/tools/ipodloader2/keypad.c |
20:32:25 | petur | willco |
20:32:26 | preglow | linuxstb: somewhat |
20:32:29 | LinusN | petur: that's whet the original uses |
20:34:18 | petur | LinusN: you didn't find out how they set the different levels... |
20:34:54 | XavierGr | ok here is the patch for the viewer. Please test or give me your opinion. Thanks. |
20:34:55 | XavierGr | https://sourceforge.net/tracker/?func=detail&aid=1266294&group_id=44306&atid=439120 |
20:35:08 | * | preglow looks forward to getting multicore support going...... |
20:35:12 | LinusN | petur: no |
20:35:22 | petur | ok, thanks |
20:35:23 | preglow | i'm going to need divine intervention or a lot of help |
20:35:58 | Slasheri | linuxstb: i think that in future even an integrated tag editor to the tag cache browser would be really nice :) |
20:36:06 | Cassandra | preglow, scary stuff. |
20:36:19 | preglow | Cassandra: got a bootloader stuffed in your ipod yet, btw? |
20:36:45 | Cassandra | Yep. For some reason it won't boot the original firmware when the Rockbox loader is on. |
20:36:57 | preglow | mine can't boot it any longer either |
20:37:05 | Cassandra | (Oh, and as I minor point, I think we should remove the penguin.) |
20:37:14 | petur | :D |
20:37:26 | preglow | doesn't seem much point in keeping it anymore, no, unless we want it as some absurd "thank you" to the ipl people |
20:37:51 | | Quit Mmmm () |
20:37:55 | Cassandra | Well, I think that it says "Rockbox/iPod Linux bootloader is enough of a nod. |
20:38:06 | amiconn | preglow: I think multicore support is the most interesting part of the ipod port... |
20:38:49 | zeero | petur: so, any idea if/when the x11 version will be fixed, and what's wrong with it? |
20:38:52 | preglow | amiconn: it'll need some thinking |
20:39:07 | petur | zeero: no idea, never used it... |
20:39:13 | preglow | amiconn: i think we will want to dedicate the second core to codecs, but again, there will be nuances that will need resolving |
20:39:20 | preglow | amiconn: i think you should get one to help me along :) |
20:39:24 | Cassandra | Multiprocessor Rockbox. Scary. |
20:39:24 | zeero | petur: okay, thanks |
20:39:34 | petur | you could always fix it ;) |
20:39:42 | Cassandra | I suspect Rockboy is going to need both processors. |
20:39:50 | Cassandra | But we can always not bother with that. |
20:39:53 | amiconn | Nah, no ipod for me, that's for sure |
20:40:35 | preglow | think of all the glorious asm! |
20:40:40 | Cassandra | Why not amiconn? |
20:41:11 | preglow | leaving the n00bs to it is irresponsible :P |
20:41:19 | mirak | preglow: I shoudln't have erased Matlab |
20:41:29 | mirak | (to test compression) |
20:41:33 | mirak | :D |
20:41:34 | preglow | matlab's nice |
20:41:52 | mirak | yes to have a math approach |
20:42:00 | mirak | matrix computing is easy and handy |
20:42:01 | Moos | amiconn: apple allergy like here? :D |
20:42:29 | * | Cassandra thinks the Nano is very pretty. |
20:42:33 | petur | LinusN: sorry to irq again: do you think there would be a problem setting the prescaler to something like 7kHz? |
20:42:40 | preglow | the nano is the prettiest one |
20:42:42 | Cassandra | (Although obviously way too small.) |
20:42:43 | preglow | the rest look worse |
20:42:46 | amiconn | I don't like the design, and many details distract me as well |
20:43:10 | amiconn | ...like the docking connector instead of a standard USB socket, and the worst thing - the touch wheel |
20:43:31 | Cassandra | I quite like the touch wheel. |
20:43:34 | preglow | me too |
20:45:35 | LinusN | petur: try it |
20:45:38 | LinusN | i gotta go |
20:45:42 | | Part LinusN |
20:45:43 | amiconn | The only pro of the Nano is that it's really thin, but that's about it |
20:46:35 | Cassandra | The Nano gives me tech lust. |
20:46:46 | Cassandra | Apple make a 60gb version and I'm so there. ;) |
20:47:41 | preglow | haha |
20:47:46 | preglow | four gig is enough for anyone! |
20:47:59 | amiconn | haha |
20:48:09 | preglow | Cassandra: how many gigs is yours? |
20:48:18 | * | amiconn prefers the expandable storage of the Ondio |
20:48:23 | Cassandra | 2. |
20:48:27 | preglow | mine too |
20:48:32 | preglow | i can't be bothered with memory cards |
20:48:43 | Moos | amiconn: me too, it's why I bought one |
20:48:53 | | Join webguest25 [0] (n=415ce17e@labb.contactor.se) |
20:49:13 | Cassandra | I never know what kind of mood I'm going to be in. I like to have all my music with me. |
20:49:23 | preglow | good point |
20:49:33 | Moos | indeed |
20:49:41 | preglow | but i plan on using my h120 for my main player anyway |
20:49:47 | preglow | and the nano more for small trips and the like |
20:49:50 | zeero | so, what's the right way to create the .rockbox dir for the sim? (make zip and then unzip in the archos dir?) |
20:49:52 | preglow | where the size is nice |
20:49:56 | Cassandra | Also random shuffle is better with your whole collection. Means you listen to stuff you've forgotten about. |
20:50:06 | * | Moos waiting for 80 GO Toshiba HD |
20:50:07 | linuxstb | zerro: "make install" - which I think is just a zip and unzip |
20:50:14 | linuxstb | (sorry, zeero) |
20:50:15 | amiconn | Moos: One day I'll write a file management plugin if no-one does it before. Then there are many new possibilities, like updating rockbox from a memory card, without the computer around... |
20:50:26 | amiconn | ...or copying files from one Ondio to another |
20:50:29 | Moos | O.O |
20:50:38 | zeero | linuxstb: so that puts everything in the archos dir? |
20:50:44 | linuxstb | Yes. |
20:50:49 | Cassandra | What I want is something that will store about 500 albums lossless. |
20:50:50 | zeero | cool, thanks |
20:50:52 | Moos | amiconn: that sounds good |
20:51:01 | Cassandra | (I only own 250 or so, but room to expand is good.) |
20:51:05 | amiconn | An unzip plugin would do for a start |
20:51:21 | zeero | ahh, the wine version seems to work quite nicely :) |
20:51:37 | preglow | someone start porting sims to sdl! |
20:51:56 | Cassandra | Huh? |
20:52:00 | petur | does wine support sound as well? |
20:52:17 | Moos | amiconn: be sure anyone will work on it until you, not a lot of ondio dev :( |
20:52:22 | zeero | petur: checking :) |
20:53:07 | zeero | petur: hrmm, seems like no :( i get a unhandled div by zero |
20:53:14 | Moos | amiconn: is you and [IDC]Dragon, ported Rockbox on Ondios, right? |
20:53:14 | petur | the current w32 sim isn't OK, I wrote a patch (1375787) that fixes this |
20:53:20 | amiconn | petur: It does, at least for me |
20:53:24 | linuxstb | zeero: I think you have to manually enable it by setting ROCKBOX_HAS_SIMSOUND in the autoconf.h |
20:53:28 | amiconn | Moos: yes |
20:53:29 | petur | And that is fixed as well in another patch |
20:53:43 | zeero | linuxstb: ahh, okay, let's try that |
20:54:12 | amar | can anyone tell me where is the global_settings structure is deffined? |
20:54:38 | zeero | linuxstb: do i define it as 1? |
20:54:39 | amar | or is that a very stupid question |
20:54:53 | linuxstb | zeero: Yes, define it as anything. |
20:55:00 | zeero | okay, cool |
20:55:05 | linuxstb | It's just checked using #ifdef |
20:55:08 | amiconn | Moos: [IDC]Dragon figured out most hardware tidbits and added FAT16 support, I wrote the MMC driver and helped debugging FAT16 |
20:55:12 | zeero | ahh, nod |
20:55:43 | linuxstb | amar: apps/settings.h |
20:55:51 | petur | amiconn: the cvs implementation either doesn't play or gives 100% cpu load (Sleep(0) or Sleep(1)) |
20:55:51 | amar | thanks |
20:55:51 | XavierGr | don't try to delete a folder with 2000+ files using rockbox..... |
20:55:53 | amiconn | Many small contributions from other authors of course, like the soft button definitions etc |
20:56:02 | Moos | ok |
20:56:52 | amiconn | Oh, and since it was me who bought the Ondio SP, I had to adjust rockbox to the differences between MAS3587 and MAS3539 |
20:57:06 | amiconn | Now I have both an FM and the SP ... |
20:57:07 | zeero | petur/linuxstd: sound works fine with that def :) |
20:57:44 | preglow | haha |
20:57:50 | preglow | sell one and get a nano! |
20:58:15 | HCl | hows rockbox with the nano? |
20:58:23 | preglow | HCl: it responds to keypresses now... |
20:59:14 | HCl | k |
20:59:51 | | Join mojo [0] (n=mojoski@170.252.248.207) |
21:00 |
21:00:14 | mojo | hey everyone.. Anyone alive? |
21:00:15 | amiconn | preglow: The nano flash access is boooring, as it just uses the standard ata driver ;) |
21:00:28 | mojo | oops, sorry |
21:01:09 | preglow | amiconn: lucky for me, i don't think i enjoy that kind of programming |
21:01:23 | amiconn | Oh, forgot that [IDC]Dragon added philips tuner support, which was then helpful on iriver too |
21:01:42 | preglow | my, i'd love some datasheets about now |
21:02:20 | Moos | amiconn: is there one hardware limitation of MMC capacity? I mean in the future is there one size limit max? |
21:03:24 | Moos | 4go, no? |
21:03:28 | amiconn | Yes |
21:03:43 | Moos | ok |
21:03:46 | amiconn | The current MMC protocol uses byte addressing with a 32 bit address |
21:03:58 | | Quit solexx (Read error: 104 (Connection reset by peer)) |
21:04:25 | Moos | 10 little cards equivalent of my iriver :) |
21:04:33 | amiconn | Afaik, even MMC4.0 doesn't raise the limit, it only defines faster transfer modes (with additional contacts) |
21:04:38 | | Join solexx__ [0] (n=jrschulz@c187206.adsl.hansenet.de) |
21:05:18 | Moos | thanks for he infos |
21:05:31 | * | Moos going to do some food |
21:06:06 | amiconn | In case some future standard allows more than 4GB, and this standard would still support SPI mode, rockbox could be adapted to support it |
21:06:20 | Moos | Cool ! |
21:06:47 | amiconn | The USB->MMC brigde wouldn't understand it, but that's not a big problem on the Ondio. You would just need a card reader to fill the card |
21:07:10 | | Quit San||Halo (Read error: 110 (Connection timed out)) |
21:07:36 | _FireFly_ | amiconn: about unzip i have some functions which can read uncompressed zip-file |
21:08:06 | linuxstb | We definitely need to speed up wps loading somehow. |
21:08:19 | _FireFly_ | linuxstb: ?? |
21:08:47 | _FireFly_ | amiconn: with crc |
21:08:50 | preglow | i thought bmp loading was what took time |
21:08:53 | linuxstb | Loading the 500 tiny bitmaps... |
21:08:58 | linuxstb | That's what I mean. |
21:09:03 | _FireFly_ | linuxstb: ah yes |
21:09:15 | _FireFly_ | mine combined-bitmap support could help |
21:09:17 | _FireFly_ | a bit |
21:09:32 | _FireFly_ | but it isn't very userfriendly :) |
21:09:59 | _FireFly_ | because they need to merge the images together yourself |
21:10:21 | preglow | still |
21:10:26 | preglow | i think that approach is definitely best |
21:10:34 | Slasheri | Hmm, just combine the bitmaps runtime and create a fast binary version of the current wps? |
21:10:49 | preglow | combine bitmaps runtime? |
21:10:52 | preglow | then you need to load them anyway |
21:10:58 | Slasheri | when loading the wps first time |
21:10:59 | linuxstb | The build script could combine the bitmaps into a single file. |
21:11:07 | Slasheri | that's true |
21:11:29 | _FireFly_ | linuxstb: but how to discover the position of the images in the image |
21:11:43 | linuxstb | The build script knows them (it put them there) |
21:11:53 | linuxstb | So the build script would have to modify the wps. |
21:11:58 | _FireFly_ | yepp |
21:12:06 | amiconn | I don't see a problem with all gfx in one image |
21:12:08 | linuxstb | Maybe not a 5 minute job though... |
21:12:37 | linuxstb | amiconn: I agree, but it's more awkward for users to produce them like that. |
21:12:46 | amiconn | In fact, I think editing wps graphics is easier this way, instead of dealing with dozens of tiny bitmaps |
21:13:51 | *** | Saving seen data "./dancer.seen" |
21:14:37 | _FireFly_ | my wps for example has fit all used images in an the image which was the background-image |
21:16:07 | _FireFly_ | the size is 160x25 pixel |
21:16:50 | preglow | linuxstb: i wonder how to handle repeat with an interrupt based driver |
21:16:57 | preglow | linuxstb: i hope the hardware deals with it... |
21:17:14 | | Quit perplexity (Read error: 113 (No route to host)) |
21:17:43 | preglow | might not be that hard anyway, of course, we'll see |
21:19:11 | amiconn | Depending on whether you get an interrupt both for press and release, it might be simple |
21:20:13 | | Quit joshn_454 ("KVIrc 3.2.0 'Realia'") |
21:20:20 | preglow | seems like i only get interrupts for press |
21:20:32 | preglow | lemme check |
21:20:53 | preglow | nope |
21:20:54 | preglow | for release as well |
21:21:10 | preglow | so i could just schedule a tick task to deal with it for me while a key is pressed |
21:21:15 | amiconn | yup |
21:22:01 | amiconn | The button handling wouldn't be all that different from the other platforms, just the button_status variable won't be updated by polling, but by the button interrupt(s) instead |
21:22:21 | amiconn | The button tick could work the same way, just without the button_read() call |
21:22:35 | _FireFly_ | amiconn: the patch for combined bmp support is already on tracker but i must update it do the cvs-change which my wps-image-flicker fix had produced :) |
21:25:11 | _FireFly_ | amiconn: do you want my fns for reading uncompressed zip-files ?? |
21:25:51 | amiconn | No time for zip atm :/ |
21:26:52 | _FireFly_ | hmm ok the only thing which would be hard to implement due the small amount on resources is an uncompression algo |
21:27:17 | preglow | i don't believe that'd take much time |
21:27:23 | preglow | depends on the files we're talking about |
21:27:31 | amiconn | zip |
21:27:34 | preglow | well, yeah |
21:27:36 | preglow | but contents |
21:27:40 | preglow | are we talking about zipping wpses here? |
21:27:45 | amiconn | E.g. |
21:27:52 | amiconn | rockbox.zip |
21:27:56 | preglow | that would be a pretty nice application, actually |
21:27:59 | preglow | having wps contained in one file |
21:28:20 | amiconn | I would like to be able to unzip a rockbox build on target |
21:28:23 | _FireFly_ | i have already an function set which work with uncompressed zip-files |
21:28:31 | preglow | well |
21:28:38 | preglow | there is an unzip library hanging around |
21:28:39 | amiconn | Nothing that needs to be especially fast |
21:28:42 | preglow | which uses zlib |
21:28:47 | preglow | should be very portable |
21:29:02 | amiconn | It should just fit in the archos plugin ram |
21:29:05 | _FireFly_ | preglow: afaik malloc might be needed |
21:29:10 | preglow | _FireFly_: good point |
21:29:29 | _FireFly_ | because you need an bigger buffer for the uncompressed data |
21:29:34 | _FireFly_ | as the compressed one |
21:29:46 | amiconn | I think it should work as a viewer for .zip files, asking for the destination dir to unzip it to |
21:29:56 | _FireFly_ | and my short overlook on zlib it uses malloc |
21:30:22 | _FireFly_ | so only the file-list could be in ram |
21:31:01 | _FireFly_ | and then a spezified amount of compressed data is read from file ,uncompressed and written to the destionation file |
21:31:10 | preglow | amiconn: so, use of mp3 buffer is banished? |
21:31:27 | _FireFly_ | my fn's it reads into an array all files in the zip-file whith the seek-points to the start of the data |
21:31:28 | amiconn | preglow: No, it could be used for data |
21:31:34 | linuxstb | What's "human68k" ? (it's a target for unzip) |
21:31:34 | preglow | then you'll be alright |
21:31:48 | mirak | _FireFly_: what do you do to convert the malloc ? |
21:31:54 | _FireFly_ | only an uncompressen algo is missing |
21:32:07 | _FireFly_ | mirak: i*m doing nothing |
21:32:29 | preglow | linuxstb: i think it's the same as x68000, and old kind of computer from asian country |
21:32:29 | mirak | _FireFly_: ok so if an app uses malloc, how can I adapt it ? |
21:32:42 | preglow | 68k based |
21:32:50 | mirak | atari and amiga |
21:33:12 | preglow | yes, but this was something different |
21:33:21 | mirak | my god there is was only 1 mega of ram |
21:33:25 | mirak | -is |
21:33:26 | preglow | i can't quite remember, it's been yonks since i've even heard the name mentioned |
21:33:31 | | Quit webguest25 ("CGI:IRC") |
21:33:48 | | Join Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com) |
21:34:41 | linuxstb | unzip has m68k assembler optimisations courtesy of that machine. |
21:34:59 | preglow | linuxstb: too bad we can't use them |
21:35:06 | linuxstb | No use at all? |
21:35:08 | preglow | coldfire is a subset of m68k |
21:35:12 | preglow | depends on how it's written |
21:35:58 | | Quit xmixahlx ("blah blah blah") |
21:36:52 | _FireFly_ | if someone have interrest about my read-zip-fns (with crc-check) then the sources can be found here: http://home.arcor.de/s.wezel/read-zip.zip |
21:37:21 | linuxstb | The unzip source code has even more #ifdefs than Rockbox |
21:37:22 | _FireFly_ | it was written to work in rockbox -> only functions used, which are present in rockbox |
21:37:30 | _FireFly_ | linuxstb: yeag |
21:37:34 | _FireFly_ | -g -h |
21:37:57 | _FireFly_ | but i havn't yet written an plugin or such |
21:38:32 | | Part Mmmm |
21:39:20 | | Join Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com) |
21:40:17 | linuxstb | mirak: You have two options for porting an app that uses malloc - either replace all the mallocs by static buffers, or implement your own malloc that allocates from a large static buffer. Either way, remember that you don't have unlimited RAM available - unlike a PC. |
21:40:59 | _FireFly_ | RAM on PC isn't unlimited either but much more then on the targets |
21:41:23 | ze | people oughtta use ram on a PC like they're forced to on small devices :p |
21:41:53 | preglow | indeed |
21:41:57 | preglow | god, i'm tired of bloat |
21:42:01 | | Part mojo |
21:42:20 | _FireFly_ | i think you should only use as much as ram as really needed |
21:43:08 | preglow | now, how to set last_btn properly for an interrupt driven button driver? |
21:43:17 | amiconn | 'small' devices are dependent on the point of view. The ZX81 had 1KB of RAM - including the framebuffer (!) |
21:43:33 | _FireFly_ | wow |
21:43:33 | linuxstb | And I remember a chess game being available for it... |
21:44:17 | preglow | you probably couldn't castle in it, due to memory constraints |
21:44:45 | linuxstb | hehe |
21:46:46 | amiconn | Chess was available for the ZX Spectrum, which had either 16KB or 48KB of RAM |
21:46:56 | amiconn | The even was VoiceChess... |
21:46:59 | amiconn | *There |
21:48:08 | linuxstb | RockChess - where is it? |
21:48:16 | Mmmm | Has anyone noticed an increased ticking noise with the remote possibly since the flicker improvements? |
21:48:56 | preglow | linuxstb: ipl has chess... |
21:49:20 | preglow | it's called (surprise) tuxchess |
21:49:28 | linuxstb | Not iChess? |
21:49:49 | preglow | hehe |
21:50:04 | preglow | how do they choose? |
21:50:15 | preglow | must be half of the development process alone |
21:50:27 | amiconn | ? |
21:50:52 | | Quit JazzBone ("Leaving") |
21:51:26 | linuxstb | Mmm. Seems tuxchess is not GPL - but the author's own "do whatever, as long as you don't make money from it" kind of license. |
21:51:57 | preglow | linuxstb: btw, slowcoder says the new button driver isn't perfect either |
21:52:29 | preglow | how the hell do they survive all these numerical addresses? |
21:53:38 | | Join ender1 [0] (i=ychat@84.52.165.220) |
21:54:40 | linuxstb | Any ideas about how games like Sudoku and Bejewelled could work with the ipod's scrollwheel? |
21:54:42 | mirak | linuxstb: ok. I have read that http://en.wikipedia.org/wiki/Data_compression/JPEG . I am not sure about quantization |
21:54:55 | mirak | I don't understand the equation |
21:55:15 | preglow | linuxstb: plain horizontal scroll with wraparound? |
21:55:21 | preglow | god known |
21:55:27 | preglow | i think i'd like to use button action for bejeweled |
21:57:59 | preglow | hmm |
21:58:05 | * | preglow gets bitten by the strange musepack buzzing |
21:58:12 | linuxstb | Yep, I was thinking of just horizontal scroll with wraparound. It's going to take a lot of work to get all the plugins working. |
21:58:25 | preglow | well, perhaps |
21:58:31 | preglow | with the scroll wheel, yes |
21:58:40 | preglow | but we'll have ordinary up/down/left/right as well |
22:00 |
22:00:55 | | Join [1]ender [0] (i=ychat@84.52.165.220) |
22:02:06 | | Join qwisp11 [0] (n=arnott_c@cpc1-oxfd4-4-0-cust172.oxfd.cable.ntl.com) |
22:02:48 | preglow | linuxstb: so, are we to call it the MENU or UP button? |
22:03:17 | qwisp11 | hi |
22:03:23 | linuxstb | I'm happy with what they are called now - MENU and PLAY |
22:03:27 | * | preglow has a sneaking feeling we'll be struggling with the amount of buttons... |
22:03:45 | linuxstb | It's no worse than the ondio I think. |
22:04:08 | preglow | linuxstb: so you're thinking that the only way of generating UP and DOWN would be with the click wheel? |
22:04:36 | | Join webguest02 [0] (n=3efc4010@labb.contactor.se) |
22:04:42 | linuxstb | I'm thinking we don't have UP and DOWN - we have SCROLL_FWD and SCROLL_BACK |
22:04:56 | linuxstb | Which is left/right or up/down depending on the context |
22:05:17 | Cassandra | Makes life interesting, doesn't it? |
22:05:23 | | Quit ender` (Read error: 110 (Connection timed out)) |
22:06:01 | | Join muesli_- [0] (i=muesli_t@Bc0ae.b.pppool.de) |
22:06:07 | qwisp11 | Could anyone tell me the extension rockboy reads? |
22:06:16 | linuxstb | .gb or .gbc |
22:06:21 | qwisp11 | ok thanks |
22:06:24 | | Quit webguest02 (Client Quit) |
22:06:24 | muesli_- | hi |
22:06:34 | muesli_- | what does rockbox.iriver btw? |
22:06:43 | _FireFly_ | ?? |
22:06:49 | | Join webguest86 [0] (n=45dda986@labb.contactor.se) |
22:06:57 | _FireFly_ | it's the firmware file for the iriver ;) |
22:06:59 | _FireFly_ | of rockbox |
22:07:28 | muesli_- | i mean..does the bootloader access on it to start rockbox? |
22:08:03 | linuxstb | Yes, the bootloader reads that file into memory and then runs it. |
22:08:20 | muesli_- | cheers linuxstb |
22:11:04 | | Quit webguest86 (Client Quit) |
22:11:12 | mirak | in the codecs, is there a distinction from rockbox of the container and the codec itself or is it all handled by the codec ? |
22:11:32 | mirak | the codec programm in rockbox I mean |
22:11:37 | linuxstb | It's all handled by the codec. |
22:11:38 | mirak | I can't be less clear |
22:11:40 | mirak | ok |
22:11:44 | linuxstb | I knew what you meant :) |
22:12:07 | preglow | my, it'll be fun to see if this works |
22:12:11 | preglow | the odds are slim, slim, slim |
22:12:12 | mirak | so in the case there is two channels in a container |
22:12:26 | mirak | preglow: xvid ? |
22:12:33 | preglow | no, ipod button driver |
22:12:37 | preglow | i don't care about video on portables |
22:12:38 | mirak | oh |
22:12:46 | mirak | don't be negative |
22:12:52 | mirak | :) |
22:12:55 | preglow | towards portable video i am negative |
22:12:55 | preglow | haha |
22:12:57 | preglow | it's a waste of time |
22:13:10 | preglow | imho, of course |
22:13:22 | mirak | I used it on various ocasion |
22:13:30 | preglow | but the scary part is i'll probably end up helping if you get some code going |
22:13:31 | mirak | I used it in the train |
22:13:50 | mirak | I am not there yet |
22:14:05 | linuxstb | I'm sure lots of people will help - it's the first step that no-one's taken yet. |
22:14:24 | mirak | for me that's less useless than playing PSP in the metro |
22:14:29 | mirak | I have seen guys doing that |
22:14:38 | mirak | I would puke my breakfast for sure |
22:14:38 | Mmmm | So then...about this ticking... could the flickering improvements have worsened the ticking noise? Does that sound likely? |
22:14:39 | preglow | i'm more keen on reading on the train |
22:14:43 | preglow | and listening to music, of course |
22:14:58 | mirak | sleeping also is nice |
22:14:59 | preglow | but yes, i would of course help optimising it |
22:15:12 | preglow | it's always fun to see what one can get out of limited hardware |
22:15:47 | mirak | I am sure somebody wil have done it before I even start to code |
22:16:30 | mirak | but well anyway I am understanding mpeg compression, I wanted to study that since a long time |
22:17:04 | * | preglow tries out his cowboy style button driver |
22:17:08 | linuxstb | I wonder if Apple will launch a video Nano before we get Rockbox working. |
22:17:20 | | Quit ender1 (Read error: 110 (Connection timed out)) |
22:17:41 | preglow | AHAHAHHA |
22:17:43 | preglow | IT BLOODY WORKS |
22:17:53 | linuxstb | hehe |
22:18:02 | linuxstb | Has it crashed yet? |
22:18:05 | preglow | yes |
22:18:06 | preglow | profusely |
22:18:09 | linuxstb | lol |
22:18:12 | mirak | :) |
22:18:18 | preglow | but this was way, way more than i expected |
22:18:38 | * | petur crosses his fingers as he tries his backlight pwm code |
22:18:45 | linuxstb | So did the file browser actually browse? |
22:18:45 | preglow | rockbox keeps assuring me there's nothing to resume |
22:18:58 | mirak | preglow: you try to run rockbox on ipod ? |
22:19:01 | preglow | i have no up and down |
22:19:03 | preglow | i'll try it now |
22:19:10 | petur | LinusN is right - it flickers :( but it works! |
22:19:35 | mirak | have though of giving max priority to the music thread ? |
22:19:45 | mirak | I have ogg pausing sometime when scrolling |
22:19:48 | preglow | linuxstb: well, i need to redefine some code to make it work first, there is no UP and DOWN for ipod |
22:19:53 | mirak | or pushing a button too long |
22:19:58 | preglow | or have you fixed that in the file browser already? |
22:20:18 | preglow | i have not attempted to make |
22:20:23 | preglow | cliock wheel work |
22:20:32 | | Quit qwisp11 () |
22:20:50 | linuxstb | up/down are mapped to the scroll wheel in the file browser - see apps/tree.h |
22:21:07 | preglow | i haven't got scrool wheel working |
22:21:13 | preglow | hmm |
22:21:36 | preglow | it's a bit flakey as of yet |
22:22:18 | preglow | haha |
22:22:19 | preglow | menu works |
22:22:46 | petur | is it OK to add a setting for LCD backlight for the H300 target? |
22:22:53 | Cassandra | Does sprintf(string, "a%s", string) work OK? |
22:23:08 | linuxstb | Yes - but use snprintf |
22:23:10 | preglow | bookmarks empty |
22:23:22 | | Quit [1]ender (Read error: 104 (Connection reset by peer)) |
22:23:51 | | Quit Mmmm () |
22:24:01 | preglow | context menu works |
22:24:18 | | Join ender` [0] (i=ychat@84.52.165.220) |
22:25:51 | linuxstb | petur: Is that a setting to adjust the brightness? |
22:26:31 | petur | yes |
22:27:08 | linuxstb | Does the contrast setting do anything? |
22:27:15 | petur | not that I know |
22:27:22 | petur | 9TO DO) :) |
22:27:33 | petur | 9 = ( |
22:28:02 | petur | iRiver FW can set the contrast |
22:28:16 | petur | maybe they play with the LCD signal timings |
22:30:06 | petur | linuxstb: contrast for h300 is dummy |
22:30:09 | | Quit akaidiot ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
22:30:40 | | Quit ze (Read error: 110 (Connection timed out)) |
22:31:16 | Cassandra | preglow, doesn't work in wxWidgets. Bleh to them. |
22:31:47 | _FireFly_ | Cassandra: is string an wxString ?? |
22:31:55 | Cassandra | Yep. |
22:32:15 | _FireFly_ | why not use the .Format instance-methode of the class |
22:32:19 | _FireFly_ | or similar |
22:32:34 | Cassandra | And I'm using wxString->Printf, of course (which is equivalent to a vsnprintf, whatever that might be.) |
22:32:39 | petur | would we need backlight fade in/out on the H300 as well? |
22:32:51 | petur | (while I'm at the settings stuff) |
22:33:22 | Lear | cassandra: sounds like you want wxString::Format... |
22:33:37 | _FireFly_ | Cassandra: http://www.wxwidgets.org/manuals/2.4.2/wx368.htm#topic923 |
22:33:50 | muesli_- | petur sure! its fantastic on h100 |
22:34:11 | Cassandra | I just copied to a temp buffer. It's all good. |
22:34:25 | petur | but the PWM only has 16 levels :( unless I also do the Slasheri trick |
22:34:39 | linuxstb | I think Linus said that backlight fading didn't work very well on the h300 when he played with it. |
22:34:43 | _FireFly_ | Cassandra: you should also do following string = "a"+string |
22:35:00 | petur | so hardware PWM for continuous setting and software PWM for fading |
22:35:58 | petur | I think I know what Linus saw: with lower PWM values, you get a bit of flickering if the drive is being accessed. The original FW has this as well |
22:36:15 | petur | if the drive spins down - steady light ;) |
22:36:43 | linuxstb | A nice way to indicate disk activity... |
22:36:52 | _FireFly_ | yeah |
22:36:57 | petur | I would also make this setting available to plugins - flashlight anyone? |
22:37:34 | petur | btw, I already used my H340 as a flashlight once! |
22:37:41 | linuxstb | That's the main use for my ipod at the moment - I find my way to bed with it instead of turning the light on. |
22:38:03 | preglow | ajajahaha |
22:38:06 | Cassandra | Some bugger has been stealing my brackets. |
22:38:07 | preglow | this is just too funny |
22:38:28 | preglow | i've got a feeling we're not clocked too high as of yet |
22:38:39 | linuxstb | No, I don't think so. |
22:38:53 | preglow | i've got click wheel working |
22:38:57 | preglow | but damn, it handles like a dog |
22:39:06 | | Quit paugh ("Leaving") |
22:39:33 | preglow | and a small, small, teensy stroke just keeps it going for seconds |
22:41:21 | preglow | it's a wee bit flakey as of yet too |
22:41:23 | preglow | wanna try it out? |
22:42:20 | preglow | if so: www.pvv.org/~thomj/rockbox/rockbox.ipod |
22:42:52 | | Quit mikearthur (Read error: 104 (Connection reset by peer)) |
22:43:03 | preglow | that's for 4g |
22:43:48 | | Join mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk) |
22:44:56 | | Join Jungti1234 [0] (n=jungti12@58.77.81.144) |
22:45:05 | Jungti1234 | hi |
22:45:44 | | Join actionshrimp [0] (n=NNSCRIPT@host86-136-20-96.range86-136.btcentralplus.com) |
22:48:44 | | Join San [0] (n=sanitari@A-79-176.cust.iol.ie) |
22:49:08 | linuxstb | preglow: It works, but the scrollwheel doesn't seem quite right.... |
22:49:44 | preglow | linuxstb: no, it's completely off the bat |
22:49:50 | preglow | linuxstb: setting time works just nice |
22:50:00 | preglow | so kudos on that driver |
22:50:16 | preglow | scroll wheel works here, but it's hypersensitive |
22:50:18 | preglow | and lagged |
22:50:50 | linuxstb | At last, I've managed to change the font... |
22:51:03 | preglow | to what? :P |
22:51:05 | | Join guillaumh [0] (n=guillaum@4va54-1-81-56-99-20.fbx.proxad.net) |
22:51:13 | preglow | the default is fine like wine here |
22:51:28 | linuxstb | To chicago12 |
22:51:29 | | Part guillaumh ("bye") |
22:52:00 | preglow | my, this things is lagged |
22:52:17 | linuxstb | Is it right that the backlight only comes on when you press action? |
22:52:26 | preglow | it should come on for all buttons |
22:52:28 | preglow | not click wheel |
22:52:31 | preglow | i just hacked that in right now |
22:52:50 | preglow | i can't browse fonts |
22:52:52 | preglow | just doesn't work |
22:53:26 | preglow | but ok |
22:53:32 | preglow | this things seems really, really slow at the moment |
22:53:39 | preglow | perhaps i should try clocking it up a notch |
22:54:08 | linuxstb | It's gone crazy now - moving up and down randomly... |
22:54:20 | linuxstb | Ah, finally it's stopped... |
22:54:30 | preglow | yeah, it can queue a bunch of event |
22:54:31 | preglow | s |
22:54:35 | preglow | and they take aeons to complete |
22:55:13 | petur | must new settings be added at the back? Or keep them where it's logical |
22:55:34 | | Join Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com) |
22:56:41 | preglow | hahaha |
22:56:49 | preglow | clocking the cpu up gives results that are completely nuts |
22:56:59 | preglow | it behaves just like before, just faster |
22:58:17 | petur | echoing... must new settings be added at the back? Or keep them where it's logical |
22:58:38 | preglow | linuxstb: it might seem your fat driver is somewhat off here |
22:58:48 | preglow | it uses lagea mounts of time to find out bookmarks don't exist |
23:00 |
23:00:09 | preglow | lARGE |
23:00:12 | | Part Mmmm |
23:01:46 | | Join akaidiot [0] (n=nope@c-ad45e255.363-1-64736c11.cust.bredbandsbolaget.se) |
23:03:38 | | Join jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net) |
23:03:46 | jlo | hi |
23:04:05 | preglow | hi |
23:04:09 | preglow | you got some tests for me now? |
23:04:11 | preglow | i've gotta go soon |
23:06:47 | | Quit jlo (Read error: 104 (Connection reset by peer)) |
23:08:18 | | Join jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net) |
23:08:51 | | Quit amar ("CGI:IRC") |
23:09:04 | jlo | preglow : I'm uploading now, in some minutes it's ok |
23:12:42 | Lear | petur: preferably add at the back, that way you don't need to bump the config version. |
23:12:54 | linuxstb | preglow: I hope it isn't a problem with the fat driver... |
23:13:04 | petur | OK |
23:13:08 | preglow | well, i'm way out of my league no matter what it is |
23:13:12 | linuxstb | Anyway, it's nice to see that most of Rockbox is working nicely. |
23:13:17 | preglow | indeed |
23:13:23 | preglow | soon only playback remains... |
23:13:32 | | Join muesli- [0] (i=muesli_t@Bc1e2.b.pppool.de) |
23:13:54 | *** | Saving seen data "./dancer.seen" |
23:13:55 | linuxstb | Yep, once we get a reliable button driver, we can look at playback. |
23:14:03 | preglow | i don't want to ://// |
23:14:05 | petur | if I enable backlight fading for H300 as well, I do have a problem (config files of H300 no longer compatible) |
23:14:16 | petur | best to kick out fading at the moment? |
23:14:46 | jlo | preglow : so it's 4 times "starwberry fields" (original, winamp, rb, reaktor anonymously numbered). it's not the best song to do it (quality is not so good) but it's just a trial |
23:15:10 | preglow | don't i need a txt file for the abchr prog? |
23:15:33 | preglow | no idea have i make it |
23:16:34 | preglow | riight |
23:16:59 | jlo | preglow : no, do it yourself, just choose in setup the 4 files, the first will be reference (easy to recognize the original !) |
23:18:08 | jlo | preglow : and after you can compare two by two to gives quality notes |
23:18:19 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]") |
23:18:22 | | Quit San (Read error: 110 (Connection timed out)) |
23:19:39 | preglow | i didn't get this |
23:19:42 | preglow | i only get three slider groups |
23:20:28 | jlo | preglow : after your trials, you save the results and then it will create the text file |
23:21:18 | jlo | you have 3 sliders : 1 compared to 2, 1 to 3, 1 to 4 |
23:22:02 | jlo | 1 is the one called orig wav |
23:22:44 | preglow | btw, is this really the best example track? |
23:22:46 | preglow | sounds pretty mono to me |
23:23:26 | Jungti1234 | http://news.bbc.co.uk/2/hi/in_pictures/4520286.stm |
23:23:50 | Jungti1234 | http://news.bbc.co.uk/2/hi/asia-pacific/4519818.stm |
23:24:35 | jlo | preglow : the beginning is very unbalanced to left so it's very happy with crossfeed (60's songs !) |
23:25:30 | preglow | jlo: there's something wrong withg my rig here, i get mono from everything... |
23:25:33 | Moos | Jungti1234: we fucks him ;) |
23:25:37 | preglow | agaghaga |
23:25:44 | preglow | preglow's special mixer setup |
23:26:29 | | Quit zeero ("Leaving") |
23:26:42 | jlo | preglow : it should be very un-mono ! |
23:27:11 | Moos | Jungti1234: since 11 september lot of arabic and muslim racism |
23:27:28 | preglow | jlo: yes, i fucked up in the mixer matrix here, i've got it correct now |
23:27:38 | preglow | 48 channels get confusing at times |
23:27:56 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
23:29:16 | Jungti1234 | Moos: Isn't the good event. |
23:31:03 | jlo | so preglow, can you hear something now |
23:31:15 | preglow | yes, it's fixed now, but i gotta catch a bus now |
23:31:24 | preglow | so i've got to do the test tomorrow |
23:31:32 | preglow | later, all |
23:31:53 | Moos | we are trust to be arabic and/or muslims, and we fucked all those stupid people, the violence didn't solve any problem |
23:31:57 | Moos | night preglow |
23:32:21 | jlo | ok, take your time, and if you have some ideas about other songs... |
23:32:33 | Jungti1234 | Does Australian hate Korean? |
23:32:36 | jlo | bye |
23:32:40 | preglow | i'd love lucy in the sky with diamonds |
23:32:49 | preglow | jlo: just post links here or sokmething, i'll read the log tomorrow |
23:32:51 | * | preglow runs awayt |
23:32:59 | jlo | ok , |
23:33:24 | Moos | Jungti1234: fortunatly not all australian people are racist ;) |
23:33:47 | Jungti1234 | hmm.. |
23:34:06 | jlo | fine, I'do "lucy" tomorrow, goodbye |
23:34:07 | Jungti1234 | Don't look like so to me. |
23:34:12 | | Part jlo |
23:34:21 | Moos | Jungti1234: ? |
23:34:32 | Jungti1234 | They look like 'A mad dog'. |
23:35:25 | Moos | this kind of people is international, you can found they around the worls, fortunatly just a minority of people |
23:35:31 | Moos | *world |
23:36:00 | Jungti1234 | They spoke 'Disappear in this land if is not Australian'. |
23:36:26 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-130.snbrca.adelphia.net) |
23:36:50 | Moos | yes for exemple we had those kind of vocabulary in France too, around the world, but they are minoritary |
23:37:34 | | Quit muesli- (Read error: 110 (Connection timed out)) |
23:37:44 | Jungti1234 | I can't understand it. |
23:37:50 | Moos | the stupidity don't have color or nationality |
23:38:14 | Moos | sounds like you are'nt stupid so ;) |
23:38:28 | Jungti1234 | All humans are equal. |
23:38:36 | Moos | yes they are |
23:38:48 | Bagder | but some are more equal! |
23:38:58 | * | Bagder animal farms |
23:39:03 | Jungti1234 | hahaha.. |
23:39:04 | Moos | :) |
23:39:19 | Jungti1234 | I go to have breakfast. |
23:39:47 | Moos | have a good breakfast, and don't hold your heart about this |
23:39:58 | | Join webguest15 [0] (n=52e30123@labb.contactor.se) |
23:40:01 | Moos | those behaviours are antiguos |
23:40:23 | Moos | and they will be again for long time unfortunatly |
23:40:51 | | Quit webguest15 (Client Quit) |
23:41:29 | _FireFly_ | someone on this channel as mentioned that the image-flicker fix had the ticking getting louder |
23:41:37 | _FireFly_ | he was right |
23:42:01 | Moos | oops :) |
23:42:02 | _FireFly_ | i have a little patch which will reduce the ticking again |
23:42:11 | Moos | it was your fix, no? |
23:42:14 | Moos | :) |
23:42:34 | _FireFly_ | and with the reduce-ticking fix the ticking is gone (at least on my device) |
23:42:38 | _FireFly_ | Moos: yepp :) |
23:43:40 | Moos | here I noticed since I use rockbox the remote tick is gone without the Slasheri's option |
23:43:42 | _FireFly_ | my new patch uses only one place where the framebuffer gets putted to the lcd |
23:44:40 | _FireFly_ | Moos: sometimes i didn't hear it also but if a play a bit with the remote-buttons the ticking went back |
23:44:48 | * | Moos didn't use his remote, he is use it since TiMiD works and no tick :) |
23:45:02 | _FireFly_ | ?? |
23:45:18 | _FireFly_ | do you use the remote or not ?? |
23:45:37 | Moos | I use Rockbox since few month now, but I use remote just in those cold times |
23:46:04 | _FireFly_ | maybe you are a lucky guy with an device without the problem |
23:46:07 | Moos | but 1 year ago I remenber I heared the tick with remote |
23:46:17 | Moos | yes maybe :) |
23:47:36 | Moos | At start I thought it was one intentionel behaviour from iriver for mimick the beep mode, but... |
23:47:38 | _FireFly_ | LinuxN: btw, have you any success about this ticking through an check of an "infected" device |
23:48:01 | Moos | Linus isn't here |
23:48:05 | _FireFly_ | LinusN: which you got send by someone |
23:48:21 | _FireFly_ | Moos: yes i know but i gess he will read the logs ;) |
23:48:41 | Moos | yes true :) |
23:49:43 | | Quit t0mas (Read error: 104 (Connection reset by peer)) |
23:51:25 | Moos | Bagder: I just checked the Webstatistics, hehe more pages read, Rockbox will become one big "communauty" :) |
23:51:39 | Moos | with a lot of devices |
23:51:58 | Bagder | the more the merrier! |
23:52:14 | Moos | :) |
23:52:36 | * | Bagder discovered that his 'virus' mailbox is now almost 1GB |
23:52:37 | Jungti1234 | ah... |
23:52:47 | Jungti1234 | I'm full. :) |
23:53:05 | Moos | Bagder: ugh :( |
23:53:37 | Moos | Jungti1234: you are fast :) |
23:53:42 | Jungti1234 | hehe.. |
23:53:51 | Bagder | spams and virus like me a lot |
23:53:52 | Jungti1234 | Virus mail is very many. |
23:54:33 | Jungti1234 | Gmail isolates all it. |
23:55:17 | * | Moos is looking in one debate on TV about the colonization |
23:55:18 | Jungti1234 | G-Mail is safe. :) |
23:58:03 | Jungti1234 | hahaha |
23:58:04 | Jungti1234 | http://imgnews.naver.com/image/020/2005/12/13/200512130111.jpg |
23:58:12 | Jungti1234 | Is he master? |
23:58:54 | Moos | look like one animal |